Users want to be able to set umasks on a per-session basis.

[jmoore]

Really advanced users...

This would be the first use case for an ExperimenterProfile? (similar to the bash .profile or .bashrc). It's not currently needed, but would allow for a good deal of variability.

In the case of umasks, the class-umask could either overwrite or be OR'd with the system umask and then XOR'd against FFFF (we currently use four bits -- see #180).

[jmoore]

This has been written up to some extent under Omero+Security on the tiki. Probably will start without the per-class basis style but rather per-session basis.

[jmoore]

#307 details the need for a workaround.

[jmoore]

r895 fulfills this requirement by no longer having Permissions instantiated in all Details instances. (Null Permissions, however, produced the Hibernate bug described in #307) This allows users to either (a) leave them null and take the umask default or (b) set the permissions and have them used on the backend (overrides umask).

Umasks are set on ServiceFactory and are resent on each call (as outlined in Omero+Security.

Once #307 is resolved, the fixing of nulls should move from UpdateFilter to BasicSecuritySystem.transientDetails and the reference to Permissions.Flag.SOFT in BasicSecuritySystem.managedDetails should be removed.

The nulling of Permissions required some reworking of existing tests. There are also new tests in the ome.client.itests.sec package for testing umasks.

[jmoore]

r896 extends the tests. (Also adds a un-related testng suite, that's generally useful, though)

[jmoore]

r900 filters the SOFT flag off of all permissions. This may or may not be the best long-term usage (i.e. there may be a reason to allow permissions to remain "SOFT" in the DB), but in the short-term, it makes things a bit cleaner.

[jmoore]

r901 fixes my whoops.

[jmoore]

Seems to be stable. Changing per-class to per-session. The per-class requirement can be written up (much) later.