Allow user to override MAPSET ownership check

[marisn]

Currently it is not possible to work with MAPSETs that are not owned by current user. There is a good historic reason for such design decision, still it would be nice to provide users an option to override this ownership check. It would not harm anyone on a single user system and, as usual, users enabling this override must blame them self if any harm is done.

Without looking at code, it could be implemented as a startup switch/checkbox in GUI + a GISENV variable to enforce it subsequently. Design must be adopted according to existing code.

​http://lists.osgeo.org/pipermail/grass-user/2012-December/066457.html

[glynn]

Replying to marisn:

Currently it is not possible to work with MAPSETs that are not owned by current user.

r54264 allows the check to be skipped by setting the environment variable GRASS_SKIP_MAPSET_OWNER_CHECK to any non-empty value.

[wenzeslaus]

os.environ['GRASS_SKIP_MAPSET_OWNER_CHECK'] = '1'

This works. I've just tried this in Python. It was very helpful, by the way.

However, I don't know how to support this in GUI.

1) It is env variable not gisenv variable, so it is per-process. GUI cannot set it for command line. Two solutions:

• set the variable on grass start-up (the safe way, but still, I don't know how to transfer the wxGUI settings to start-up script)
• change this to gisenv variable (consequences?)

2) Where to put the check in the GUI?

3) Do we even need to support this in GUI (it is a very special thing)? Can we close this ticket as fixed now?

[martinl]

Replying to wenzeslaus:

However, I don't know how to support this in GUI.

1) It is env variable not gisenv variable, so it is per-process. GUI cannot set it for command line. Two solutions:

• set the variable on grass start-up (the safe way, but still, I don't know how to transfer the wxGUI settings to start-up script)
• change this to gisenv variable (consequences?)

I could comment it in the sense how it's done for GRASS_ADDON_PATH variable (menu: File->Launch script). If the script is not in the path, the GUI updates loaded environmental variable (os.environ['GRASS_ADDON_PATH']=) and updates .grass7/basrc (or GRASS7\env.bat on MS Windows). This file is loaded by the initialization script. Drawback: if you quit GUI and launch it again, the variable is lost - you need to restart GRASS (launch initialization script which loads bashrc or env.bat file).

[hamish]

(a bit off-topic, but for anyone who didn't know these non-obvious points already it's worth repeating)

[

n.b. 1) in GRASS 6 GRASS_ADDON_PATH needs to be set in ~/.bashrc not ~/.grass.bashrc since .grass.bashrc is run last, after the PATH and everything else is already set up. GRASS_HTML_BROWSER is another in the same situation, see grass64 --help for the full list.

n.b. 2) the script needs to be in the path for g.parser to function correctly. Compiled C modules don't need to be in the path though.

]

[martinl]

Replying to hamish:

n.b. 1) in GRASS 6 GRASS_ADDON_PATH needs to be set in ~/.bashrc not ~/.grass.bashrc since .grass.bashrc is run last, after the PATH and everything else is already set up. GRASS_HTML_BROWSER is another in the same situation, see grass64 --help for the full list.

this is not true for G7

[glynn]

Replying to wenzeslaus:

However, I don't know how to support this in GUI.

I'm not sure you should support it in the GUI. It should be set on single-user systems, and unset on multi-user systems. On a given system, there's no reason for the user to change it.

[wenzeslaus]

Replying to glynn:

Replying to wenzeslaus:

However, I don't know how to support this in GUI.

I'm not sure you should support it in the GUI. It should be set on single-user systems, and unset on multi-user systems. On a given system, there's no reason for the user to change it.

OK, because there is no need to set it from GUI and the programmer's way is available, I'm closing the ticked as fixed.