losing MapAnnotations when chgrp/chown

[DaveMellert]

Hello everyone,

I ran across an issue that caused me a little bit of a headache and I am not sure whether I ran into a bug or intended behavior.

I have been using the python api to add map annotations to user's images. I am using an admin account to do that, so the map annotations are 'owned' and linked by the service account. This seems okay, as the annotations are visible to the user even if the service account is not in their group. You can see how this looks for the public data at https://images.jax.org.

My problem is this--if I have map annotations linked to images, and these images are owned by a given user and one of their groups, when I then move those images (by moving their parent datasets and projects) to a different user and group, the map annotations become unlinked to the images. The map annotations themselves still appear in an hql query and show they are owned by the original, not the target, group.

For example, I had a project with several datasets that I moved to the Public user in the Public group by the CLI chown/chgrp. I just gave the Project ID and no additional options. Everything moved as I intended, the image descriptions and everything were unchanged, but the map annotations all disappeared (seemingly orphaned in the DB, so I just deleted them and re-annotated).

Is there a problem with my workflow? Are map annotations supposed to move along with Images when you move them to another user/group?

[mtbc]

Dear Dave,

Thanks for the report, we'll investigate and at least figure out what's going on. To confirm one of the examples where you moved just the project, what were the permissions of both the "from" group and the "to" group? (E.g., read-only, read-annotate, etc.)

When you say "to a different user and group" does it suffice to just do it to a different group, you don't have to be changing user too?

And, your admin account is a full administrator?

Cheers,
Mark

[DaveMellert]

Admin account is full admin.

chgrp was from read-only to public.

Exact order of events was:
1) added map annotations
2) chgrp (user in both read-only and public group)
3) chown (from original user to Public user)

I did not check whether the group change was sufficient. I would assume so because the map annotation ownership itself didn't change (appeared to be owned by service account before, and I would assume after?). Would it be helpful for me to try this?

[mtbc]

Dear Dave,

Is the public group also read-only?

Cheers,
Mark

[mtbc]

Dear Dave,

I've done some experimenting and so far everything seems to be working as one might expect: I end up with key-value pairs on my images in the public group. I made my public group read-only. A couple of points though:

• If the data owner, not the administrator, tries to move the images to another group then the key-value pairs will not be transferred because the user does not have the power to move the administrator's annotations. In this case OMERO.web warns of not including some "Other" and OMERO.cli with --report reports deletion of ImageAnnotationLink. So, the administrator should either do the moving or they should first chown the map annotations to be owned by the image owner before they do the moving.
• You probably don't want the data to be owned by the public user if they should have only read access to it. (A normal OMERO "read-only" group gives write access to data owners.)

Cheers,
Mark

[DaveMellert]

Mark,

Thanks for the explanation. I'll adjust my workflow and see if I can avoid that problem in the future. I suspect the issue had to do with the admin owning the annotations as you pointed out.

You probably don't want the data to be owned by the public user if they should have only read access to it. (A normal OMERO "read-only" group gives write access to data owners.)

This seemed to be the most straightforward way to have all of the public data visible in one place. My understanding was that anyone accessing that data without credentials would still not be able to delete/annotate/write. My attempts to do so silently fail. Am I missing something?

[pwalczysko]

Dear Dave

This seemed to be the most straightforward way to have all of the public data visible in one place. My understanding was that anyone accessing that data without credentials would still not be able to delete/annotate/write. My attempts to do so silently fail. Am I missing something?

Please consult our docs https://docs.openmicroscopy.org/omero/5.4.10/sysadmins/public.html#publishing-data-using-omero-web . There we do not recommend public data to be owned by the public user. Instead, a workflow is suggested where the data are owned by somebody else and accessed by the public user via their permissions of viewing other people’s data in a read-only group.
In this way, there are two security barriers to protect your public data. First one is the fact that the data are not owned by the public user (OMERO permissions system is protecting your data). Second, (this is the one you are seeing in action on your system), there is a block on POST actions for public user in OMERO web, which prevents any writing of any data by that user. Now, in having public user owning the data, you cancelled the first security barrier for no apparent win.

The setup you require seems to be easily achieved by having a specific second user in a read-only public group, together with the public user. In order to redirect the public user to the data of this second user (let us call them Second User), you might issue a link to a first Project such as described in the doc https://docs.openmicroscopy.org/omero/5.4.10/sysadmins/public.html#configuring-urls . Please ignore for the moment the minting of DOI part in the paragraph I am pointing you to, instead, just note the construction of the link to the Project described there please. You can issue this link to anyone interested to see your public data. This link will redirect directly to the data of Second User when clicked. You can get the link easily by clicking on the Project, Dataset, Screen or Plate in question in the left-hand tree and then clicking on the “chain” icon in the right-hand pane and copy the link from there.

Also, you might consider that, with time, the structure of the data published on your OMERO server might get richer and more complex, and you might not want to lose track of whose data are belonging to which original owner after publication. The system (or a variation of it) described in the doc gives you more flexibility for such cases.

Hope this helps

Please do not hesitate to ask further questions.

All the best

Petr

OME Team

[DaveMellert]

Petr,

Thanks for the feedback and explanation. I guess most of those data are going to be discovered by alternative means (such as MGI; http://www.informatics.jax.org/), so having everything belong to the Public User wasn't really buying me much. In the future I will use a service account.

Regarding tracking data with regard to 'original owner', a lot of the data that will go into OMERO can not be said to have a single owner. But having a service account maintain ownership should be fine for our purposes.

Thanks again!

-Dave