[ome-users] Having a user that (initially) cannot upload data possible? + omero admin sessionlist not working anymore

[Josh Moore]

Hi Julio & Sascha,

>> On 16 Nov 2017, at 16:24, Sascha Neinert <sascha.neinert at uni-koeln.de> wrote:
>>
>>> Am 15.11.2017 um 16:27 schrieb Josh Moore <josh at glencoesoftware.com>:
>>>
>>> On Wed, Nov 15, 2017 at 11:18 AM, Sascha Neinert wrote:
...
>>>
>>> If that doesn't work for your situation, perhaps you could explain
>>> more about what else the non-upload users should be able to do?
>>
>> We use LDAP for authentication, so we do not add yet another account/password for the users. But we do not have groups in our LDAP, so currently omero.ldap.new_user_group is just „default“.

Interestingly, this is a situation we have with the production server
at the University of Dundee, as well. (It would be interesting to know
who else is in the same boat.) One of the recent changes we made to
clarify the situation was to rename the group to "My Data". Other
suggestions include "Private space", "Temporary Data", etc. Other
ideas?. The winner of the name raffle will go down in the OME annals.


>> Even if we would get to have groups in our organisational LDAP at some point in the future, we would have quite some users from neighbouring institutions that would have no groups, or maybe just one very big group that would not be very useful. So our users should login for the first time, notify us to be moved into their lab groups, and then start using OMERO. But they also can login for the first time and directly start to upload data, which would then end up in „default“.

There's certainly a window here where someone could do upload to
"default". A No-Uploads setting on the group would prevent this, but
it would also leave the newbie in a quite useless private, read-only
group until an administrator comes along:

 * In a non-LDAP setting, the system administrator must actively
create new users and place them in specific groups. No problems.

 * In an LDAP-with-groups setting, everything is automated. Again, no problems.

 * In this LDAP-without-groups setting, the assignment is delayed,
which is leading to confusion. But I've not been able to see a way
that the software can help with this. I'm certainly biased, but it
seems like a system administration problem.


>> If an admin takes the new user and puts him/her into the correct groups, and takes him/her out of „default“ - hm, i do not yet fully understand what happens to any remaining data in „default“ yet. Anyhow, we would like to avoid a situation where data ends up somewhere and nobody feels responsible for it anymore, so we thought if we could maybe set „default“ to „nobody can store anything inside“-mode. We could treat „default“ as some kind of „temp“ or „scratch“ maybe.

We can certainly help with tools/scripts for getting all the data out.
And we'll look into making it read only, but the user experience will
be less than stellar. Other suggestions / code changes I can think of
include:

 * use LDAP but require an admin to activate users

 * put your groups into LDAP (this can be achieved by layering one
LDAP on top of another)

 * send an email on new user creation so sysadmins can assign the user ASAP

(More ideas welcome)


On Thu, Nov 16, 2017 at 4:37 PM, Julio MATEOS_LANGERAK
<julio.mateos-langerak at igh.cnrs.fr> wrote:
>
> That is quite the same situation as ours at MRI. We do not manage groups on the LDAP and we would not like default to be data repository where nobody feels responsible for when the PhD/Postdoc leaves…
>
> We could informe an internal rule saying that every dataset imported more than x months ago will be deleted. Drastic but likely to work.

A cron job at N months to warn and at N+1 months to delete would be doable.


> Julio


Cheers,
~Josh