Opened 22 months ago
Last modified 22 months ago
#22605 new defect
No indication of and no option to delete automatically added CS-tag "hashtag"
Reported by: | skyper | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | template_report changeset tag hashtag | Cc: |
Description
What steps will reproduce the problem?
- Upload some data
- In the upload dialog add something like
repair routes #403303 and #2114080
What is the expected result?
An indication that hashtag=#403303;#2114080
is added as additional CS-tag plus an option to delete this tag
What happens instead?
No indication and the tag is always added again despite manually deleting it.
Please provide any additional information below. Attach a screenshot if possible.
See osmwww:changeset/130575508 as example.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2022-12-27 16:51:43 +0100 (Tue, 27 Dec 2022) Revision:18619 Build-Date:2022-12-28 02:30:57 URL:https://josm.openstreetmap.de/svn/trunk Identification: JOSM/1.5 (18619 en) Linux Debian GNU/Linux 11 (bullseye) Memory Usage: 180 MB / 256 MB (57 MB allocated, but free) Java version: 17.0.4+8-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM VM arguments: [-Djosm.home=<josm.pref>] Dataset consistency test: No problems found
Attachments (0)
Change History (2)
follow-up: 2 comment:1 by , 22 months ago
comment:2 by , 22 months ago
Replying to taylor.smock:
It looks like the behavior is controlled by the advanced preference
upload.changeset.hashtags
.
Thanks, this should be documented but wiki:Help/Action/Upload is already huge, partly outdated and messy. E.g. it needs quite some rework.
It looks like the behavior is controlled by the advanced preference
upload.changeset.hashtags
.Anyway, sample patch:
src/org/openstreetmap/josm/gui/io/UploadDialogModel.java
finalboolean hashtags = Config.getPref().getBoolean("upload.changeset.hashtags", true);Really, we should probably update
TagEditorModel
to fire the appropriate deletion/addition events, possibly subclassing the TableModelChanged event so that we can pass a list of the models changed, instead of just a generic table changed event.