Opened 5 years ago
Last modified 5 years ago
#19308 new defect
Download as new layer not respected if new_layer=false is present
Reported by: | skyper | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core remotecontrol | Version: | latest |
Keywords: | template_report download new layer | Cc: | ToniE |
Description (last modified by )
What steps will reproduce the problem?
- In preferences enable "Download as new layer"
- Click on a "remote control link" in web browser
Edit: link includingnew_layer=false
, likeGET /load_object?new_layer=false&relation_members=true&objects=r7367864 HTTP/1.1
What is the expected result?
It is downloaded to a new layer
What happens instead?
It is downloaded to active layer
Please provide any additional information below. Attach a screenshot if possible.
Edit: So, the local setting should overwrite/change the command.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2020-05-27 21:23:59 +0200 (Wed, 27 May 2020) Revision:16511 Build-Date:2020-05-28 01:30:47 URL:https://josm.openstreetmap.de/svn/trunk
Attachments (0)
Change History (13)
comment:1 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → needinfo |
comment:2 by , 5 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Status: | needinfo → new |
Summary: | Download as new layer not respected. → Download as new layer not respected if new_layer=false is present |
Oh, sorry, the problem is the presence of new_layer=false
like in GET /load_object?new_layer=false&relation_members=true&objects=r7367864 HTTP/1.1
. Should probably, be overwritten by local settings to GET /load_object?new_layer=true&relation_members=true&objects=r7367864 HTTP/1.1
.
I've adjusted the description.
comment:3 by , 5 years ago
Description: | modified (diff) |
---|
comment:4 by , 5 years ago
Actually, this is what I'd expect and consider as correct: The preference defines the default behaviour which can be overridden by the request parameter.
comment:5 by , 5 years ago
From the user's point of few, I have not much influence on the request parameter on a website, but the preferences are the user's choice.
I can ask each admin of the websites, individually, to drop the parameter, or the user's preferences are dominant and overwrite the parameters. See also #19307 which would make it even more user friendly.
comment:7 by , 5 years ago
new_layer=false
→ no new layernew_layer=true
→ new layernew_layer
absent → take "Download as new layer" preference
comment:8 by , 5 years ago
Cc: | added |
---|
Ok, thanks. So there is not much reason to add new_layer=false
but to overwrite the users settings.
comment:9 by , 5 years ago
I can ask each admin of the websites, ...
I'm one of the admins: I did not want to override any user settings by using new_layer=false
new_layer absent → take "Download as new layer" preference
Fine for me.
comment:10 by , 5 years ago
I added the information to the wiki, wiki:/Help/RemoteControlCommands?&action=diff&version=14&old_version=13.
Still, I would prefer to have it upside down and always respect the user's preference.
follow-up: 13 comment:12 by , 5 years ago
Basically, you're asking for a setting "Download as new layer"
- default yes (used when
new_layer
absent) - default no (used when
new_layer
absent) - always yes (overrides
new_layer
) - always no (overrides
new_layer
) - ask me every time?
comment:13 by , 5 years ago
Replying to simon04:
Basically, you're asking for a setting "Download as new layer"
yes.
- default yes (used when
new_layer
absent)- default no (used when
new_layer
absent)
These two cases are the status quo but are they really needed if the following three work?
- always yes (overrides
new_layer
)
That's what I'd expected to get with the user preference setting.
- always no (overrides
new_layer
)
Did not think about this case but it makes sense.
- ask me every time?
Can be handled together with confirmation dialog.
I cannot reproduce.
GET /load_and_zoom?left=-59.89047185907365&top=-36.75424350001947&right=-59.885985689067844&bottom=-36.75801721796789