wxGUI: An action should be required before modifying other mapsets #848
Conversation
…nctions adjusted to 'Allow renaming and deleting other mapsets or locations only when the allow editing mode is on.
|
There is a problem after renaming location/mapset, the tree is not updated (only renamed but not highlighted in bold). It should be renamed and refreshed in the function _renameNode but it is not happening. Not sure how to correct it. |
petrasovaa
added
gsoc
Could you be more specific, I don't seem to have the issue you describe, so maybe I don't test the exact thing you mention. |
…ed to be able to handle conditions: current mapset and location cannot be renamed or deleted even if the self._restricted mode is False.
This sounds counterintuitive to me: if allow editing is "ON", it should be possible to rename and delete mapsets and locations, when it is "OFF" it shouldn't be. De facto, this is what I see currently: when the lock is closed I cannot edit, when it is open I can. So probably just a question of formulation ? |
It seems to me from just trying, that this is due to the fact that the highlighted node is defined by number, but that after renaming, the order to nodes can change because of alphabetical ordering. If you rename the node to something that doesn't change its position it remains the highlighted one, but otherwise it is the node that now has the same position number that is highlighted. So you would probably need a mechanism to find out which position the node is in after renaming and change the highlighting if needed. |
|
Currently, I still can rename a mapset that I do not own. I cannot remember what we decided at the meeting. Should this be allowed ? Obviously, this works because I can also rename on disk, so GRASS GIS just reflects this... |
Yes, it should not be allowed, but this issue was not addressed so far because it is related to #801. And before that PR I need to complete #849. |
Oops.. true. Corrected. :-) |
Moritz, I think it works fine. I had this problem while renaming or deleting current mapset or location but eventually we did not allow to do that. I think when renaming or deleting other mapsets or locations it works fine. |
|
Within this PR I made controls whether mapset/location is current or not (and it is prepared for gislock and ownership controls which will be implemented in the future). And I have one idea which could be also made within this PR => "Deleting multiple locations" paradigm. |
I could see the issue with nodes other than the currently used. E.g. renaming mapsets in a different location. |
I think it is always better to follow the KISS principle and make each pull request do one thing only. So I can think it would be better to finish this one and merge And to create another PR with the multiple locations actions. What still needs to be done on this PR ? The issue with the highlighting is a nuisance but not a blocker. So, one option would be to merge this PR soon, but to file an issue about the highlight (unless it is only a local problem for me). |
|
The highlighting behavior seems to be independent from this PR anyway, so let's consider this as a different issue. See an example here:
|
Moritz, |
Oh. Sorry I get it. You meant the blue highlighting. :-) That is true. It does not work. But I share the same opinion that it belongs to another issue. |
I think this PR is OK now. Ready to merge. |
Yes, that is why I said that this issue is independent of this PR: my example was done without this PR to show that the issue was already there. Without this PR, the lock icon didn't have any effect. |
Ok, I will merge. We can always open issues if they come up. |
While "allow editing" is OFF, no mapsets or location can be renamed or deleted. When ON we are allowed to rename and delete all mapsets and locations besides current ones.