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

[Petr Walczysko (Staff)]

Hi Sascha

As a follow-up to Josh’s email, to answer your question

>> 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.

Please never take a user out of any group and leave his/her data in that group. You would get undesirable effects in case you try to work with such data in OMERO.clients.
The recommended course of action is: Move the data to the group where the owner of the data is a member. Or, change the ownership of the data to somebody
who is member of the group where the data are.  See second paragraph in https://docs.openmicroscopy.org/omero/5.4.0/sysadmins/restricted-admins.html#workflow-4-group-and-data-organizer
You can organize your workflow as fast or slow as you wish (no need to do all at once or in any particular order), and you can move users and data in any order,
but be careful to end with the owners of data being in the same group as the data.

A user in OMERO can be a member of as many groups as you wish.

If you follow https://docs.openmicroscopy.org/omero/5.4.0/sysadmins/restricted-admins.html#workflow-4-group-and-data-organizer
you can find that your workflow does not need to be done by full administrators, instead, you might create some Admins with restricted privileges
as “Group and Data Organizers” and delegate such tasks to them.

Also, a Group Owner can add new members to his/her group without needing an intervention of an admin. Nevertheless, Group Owner will
not be able to remove a user from any group which they do not own.

Hope this helps

All the best

Petr



On 16/11/2017, 20:41, "ome-users on behalf of Josh Moore" <ome-users-bounces at lists.openmicroscopy.org.uk on behalf of josh at glencoesoftware.com> wrote:

    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
    _______________________________________________
    ome-users mailing list
    ome-users at lists.openmicroscopy.org.uk
    http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users



The University of Dundee is a registered Scottish Charity, No: SC015096