Moving data left by "old" users.

[i.munro]

Hello
I wonder if you can suggest a solution. We have substantial amounts of data owned by users who have now left our institute. so the passwords are no longer available. Mostly this is in read-annotate groups.
Is there any way this can be handled at the group-owner level?

Looking at http://help.openmicroscopy.org/group-owner.html#move suggested that removing the user from the group would thwn allow the group-owner to move the data to another group but this didn't seem to be possible (at least via insight)

I note that this has probably been addressed in 5.4 but we are currently running 5.3.

Best Wishes

Ian

[pwalczysko]

Hello Ian,

Sorry about the help doc, it is misleading and we will reformulate it.

Do I understand it right that your goal is to move the data of the users who have left the institution into another group, so that these data are "out of the way" ? If yes, then on OMERO 5.3, you either need to get an admin to move the data OR the group owner will need to take ownership of the data before they can move it. If moving the data as admin, make sure you add the owners of the data to the target group too.


If you refer to the permissions documentation [1] you will see that **Group Owners cannot move data**. By moving the data I mean moving the data into another group (chgrp).
In the same table, there is information missing (again, we will add it) regarding the possibility to change ownership (chown) for Group Owners. **Group Owners can change ownership of any data within their group**.

I recommend using OMERO.web for the Move actions, not Insight, there are several advantages in Web as explained in [2]. However, Changing ownership is only possible (even in 5.4.0) on CLI. You can take the workflows in [2] and apply them in OMERO 5.3 where the agent of the action is Group Owner, if you bear in mind the possibilities and restrictions of the Group Owner as described in my previous paragraph here. Further, you need the Group Owners in question to be members of some "dump group" which you create for the purpose of cleaning off the data (adding them to that "dump group" will have to be done by a full admin in OMERO 5.3). Then, the workflow for these Group Owners could be:

1. change the ownership of the data to themselves
2. move the (now theirs) data to "dump group"

Please do not hesitate to ask further, this is obviously a complex topic.

All the best

Petr Walczysko

OME Team

[1] https://docs.openmicroscopy.org/omero/5 ... sions.html
[2] https://docs.openmicroscopy.org/omero/5 ... -organizer

[hflynn]

Hi Ian,

Thanks for bringing that issue with the help doc to our attention - I've opened https://github.com/openmicroscopy/ome-help/pull/274 and will get the live page updated asap.

I've also opened https://github.com/openmicroscopy/ome-documentation/pull/1794 to add change ownership to the permissions tables. This page will be updated for OMERO 5.4.1.

The documentation for using the CLI to change ownership is at https://docs.openmicroscopy.org/omero/5.4.0/users/cli/chown.html

Thanks,

Helen

[i.munro]

Thanks both for your comprehensive response. That all seems clear now.

However as Petr asked the question - the immediate issue is to move some of this data into a public group in order to support a publication - but longer term I also foresee a need to be able to delete some of it to free up storage space.

Unfortunately our Group doesn't have admin access to the University-wide OMERO server - presumably exactly the sort of situation that the new role in 5.4. is intended to address.

[hflynn]

Hi again Ian,

Provided the group owner is in the public group, you will be fine with the suggested workflow of taking ownership and then moving the data without needing to involve the system administrator. And yes, group owners can also delete data in their groups.

The Group and Data Organizer role in 5.4.0 is indeed designed for exactly this sort of situation. When the server is upgraded to 5.4, we'd recommend you ask the system admin to make someone in your department this type of restricted admin so they can handle these tasks more easily in future.

[i.munro]

Thanks again.

Ian