Giving away ownership on data

Hi,
I would like to know if there is a way for a user to transfer ownership of his own data to someone else, typically one of the owners of the group or some other group member. This would imply, obviously a ‘ratchet’ behavior, the user will not be able to get data back. As I understand from the docs, this is not possible.
There are two situations where something like this would be useful.

1- A short term student leaves the lab and transfers the images to the supervisor. While in theory the student can leave his data as his own, it really makes it too complex to manage groups. In practice, the user must go see the admin and let him transfer data ownership. That is not always happening cause the user does not know about all this.

2- A less common situation where I’m working at the moment. Data has been acquired and annotated with measurements. Those measurements are double checked and validated. That validation is such that the user should not be able to modify them again (quality management thing). What I’m thinking of doing is:

  • changing the namespace to a ‘validated’ state
  • run a recurrent script with administration privileges changing ownership of ‘validated’ data.

In principle, this could be done at the same time by the user owning the data. Is there another way to achieve ‘securing’ data modification?

Would you see any issue with such a functionality?

Cheers, Julio

Hi @juliomateos

Thank you for the post and suggestions.

Short answer, there is no such feature precisely as suggested by yourself. We do have a “chown” command (command line only feature), which I suppose you know about, see https://docs.openmicroscopy.org/omero/5.6.1/users/cli/chown.html please.
Did you know that this “chown” can be performed by the Group Owners as well as Administrators and Restricted Administrators ? This might help your workflow.

For the workflow as suggested by yourself, I have created a new github issue for that https://github.com/ome/omero-blitz/issues/88

Possibly, you did not explicitly specify that the feautre should be present in Graphical clients (because the user types youi are mentioning would hardly use command line), for that, we are having a PR in progress, see below please. The PR would have to be adjusted to accommodate all the users, not just Group Owners and admins.

2- A less common situation where I’m working at the moment. Data has been acquired and annotated with measurements. Those measurements are double checked and validated. That validation is such that the user should not be able to modify them again (quality management thing). What I’m thinking of doing is:

The workflow Ad 2. in your post, I am not sure I can fully follow.
Do I get it right that after acquisition, the data belong to some kind of super-user ? This means not to the target user ? Then, when the quality assurance steps have been taken, this super-user is passing the ownership of the data to the target user ? In such case, I do not see what gives you the protection that the target user will not change the validated data (the data are theirs at the end of the process).
Or maybe you mean the data belong first to the user which I call “target user” above, and then get manipulated by a super-user, quality-checked and disowned, so that the “target user” is not able to change the data anymore ? In that case, I do not see how do the target users work with the data which does not belong to them. Or is only a part of the data owned by somebody else, but the images are owned by the target users ?

In principle, this could be done at the same time by the user owning the data.

I am afraid I am puzzled by this sentence. The same user should do a quality assurance steps on their own data and then pass the ownership on somebody else ?

Would you see any issue with such a functionality?

With a caveat that I do not really get your example Ad 2. as I said, I see one more question for the general issue of change ownership as sugested by you : How would you prevent or cater for cases where the users transferred their data to someone else in errror ? As you mention, there would be no way to get them back… Would a simple warning in the graphical client be sufficient ?

Thanks again

All the best

Petr

Hi @pwalczysko ,
Thanks for your developed answer.

Yes, I knew about this. I think this is what I will use.

Thanks. I will comment further there.

I just looked at that. It looks great and it’s going to be very useful.

For the add2, the scenario is the second option. I will explain myself a bit better.
The application is for something I’m working on. OMERO.metrics. It basically lets a user ‘facility_user’ as it is typically a core facility manager, import into OMERO images of standardised samples. A analyze.py script (run by ‘facility_user’) will then analyse those images and provide metrics on the microscope performance: resolution, field homogeneity, you name it,… Those measurements are stored into OMERO as tables, key-values and tag(links). All the data (dataset, images, Rois, MapAnn, Tables and tagLinks) is at this point owned by ‘facility_user’.
At this point ‘facility_user’ is verifying everything is ok and then he runs a validation.py script that changes the status of the data in such a way that he cannot modify it again. Some kind of quality assurance ‘signature’ and protection agains accidental loss.

The question is what is the way to best achieve this ‘validation’ step. What I’m doing at this point is:

  • Everything happens in a ‘metrics_group’ read-annotate group where ‘facility user’ is member (together with all other facility staff) and there is a user ‘metrics_master’ that is owner (this user is not a real user but just a user account to manage all of this).
  • validation.py changes the namespace of everything (at least everything using namespace) from ‘analysed’ to ‘validated’. Maybe a ‘validated’ tag too to be on the save side.
  • a ‘secure.py’ script periodically run by ‘metrics_master’ takes everything that is validated and changes ownership to be his.

Does this sound as a sensible thing to do? Probably all of this can happen better in a read-only group. I didn’t try that yet.
What was rising my question originally is the idea that all of this could be achieved in one step if ‘facility_user’ could change ownership of his own data and give that to the group owner.

You’re right about that. I guess you might restrict this ownership changes to the group owner or someone else in the same group. Also, that ‘accident’ can take place when the group owner claims data that is not ‘his’, though that is probably less harmful. I will comment on this in https://github.com/ome/omero-blitz/issues/88

Cheers, Julio

Hi @juliomateos

Thanks again for your explanations and workflow.
Yes, I understand now your scenario ad 2. about the OMERO.metrics.
Indeed, thinking about it, the approach you are taking there with changing the ownership is probably the easiest one with the options at hand.

Probably all of this can happen better in a read-only group. I didn’t try that yet.

Maybe in this respect, I would suggest that you stick to the read-annotate group, but instead, when changing ownership of the , change also the ownership of the links as well. Thus, the facility_user will not be even able to unlink the attachments, which I understand will not belong to him anymore after the metrics_master has run the secure.py script. In this manner, you will also prevent loss of linkage, and there is no reason to change the group level to read-only then.
Principally, the workflow should work as well in read-only group, assuming that the metrics_master is owner of that read-only group. But if the metrics_master runs the secure.py in the read-only environment, make sure that the linkage is intact after that, especially if you end up with mixed graphs (such as image belong to facility_user, a key-value pair on it belongs to metrics_master or similar).
For that reason I suggested to stick to read-annotate group.

you might restrict this ownership changes to the group owner

Thank you for that idea.

Thank you again

All the best

Petr

Hi,

Thanks for the advices. Some more questions.

This is the case. metrics_master is group owner
So I guess, ultimately I also want to ‘secure’ the raw data and make the images owned by metrics_master…

In what I did so far one project is one particular microscope and a dataset is one maintenance session, one point in time. Inside the dataset there are the images to use. In principle, there are all kind of measurements linked to images and dataset (apart from rois to the dataset). If the project owner is metrics_master and we are in a read-only group, can a user create a dataset into that project and import data into it? I guess I could just test this, but I’m sure there are details I will miss.

Best Julio

Hi @juliomateos

If the project owner is metrics_master and we are in a read-only group, can a user create a dataset into that project and import data into it? I guess I could just test this, but I’m sure there are details I will miss.

No, a user cannot create a dataset and link it to a Project belonging to metrics_master. The user cannot do it neither in read-only group nor in read-annotate group. The creation of the dataset itself will succeed, and import into it will succeed, but the linking of that Dataset to somebody else’s Project will fail in both group types (unless the linking user is owner of the group). The only group type where a simple group member can link his/her datasets to somebody else’s Projects is read-write. Nevertheless I am not suggesting you change the permissions of the group to read-write because you have to think about other implications of a read-write environment, such as “everybody can edit and delete everything of anybody else in read-write group”.
.

All the best

Petr