Chgrp permissioning doesn't change to reflect new group

[Manz]

Hey Guys,

When using the CLI chgrp function, the permissions of the dataset transferred do not reflect the new group.

bin/omero -s localhost -u 'user' -w password' chgrp 154 /Dataset:2953
Created session #####. Idle timeout: 10.0 min. Current group: Projects_public
omero.cmd.Chgrp /Dataset 2953... ok

[cxallan]

Hi Manz,

Could I ask you to be a bit more specific, what do you mean the permissions do not reflect the new group? Does the Dataset just not move groups?

[Manz]

I transferred from group 153 to 154


Experimentergroup
153;"";-120;"private";0;
154;"";-56;"public";0;

bin/omero -s localhost -u -w chgrp 154 /Dataset:3051

After transfer:

dataset
3051;"";-120;"test";;132618;;154;102;132618

The transfer does go through successfully.

[cxallan]

That's exactly as I would expect it. The permissions value on the actual object in the database is not synchronized with the group. When the object passes through the API it receives the correct permissions.

[Manz]

Which API?

Manda

[cxallan]

The OMERO API. It is not possible to receive objects from the server without the correct permissions being associated.

[Manz]

Hey guys

Looking at the permissions for the dataset and images, how could I get the datasets and images to reflect the permissions of the group that they are situated in? I couldn't work out how the OMERO API corrects the permissions. Would you have any additional documentation on this?

[cxallan]

As the objects pass through the API and before they are given to the client they are assigned the permissions of their associated group. If you want to know what the permissions on an object are purely by looking at the database you must look at the permissions of its associated group.

[Manz]

So the permissions in the tables dataset and images are completely disregarded?

[cxallan]

They are not disregarded but they are not guaranteed to be current with the group's permissions. Furthermore the group's permissions are currently, as I've already mentioned, authoritative for all objects belonging that group. Keeping permissions in sync would at present require the update of potentially millions of rows upon a group permission change. We have not removed the columns (http://trac.openmicroscopy.org.uk/ome/ticket/2580) due to their potential to be used in the future or even kept in sync with the group in the future.

Fundamentally the database schema is not a public API. Performing operations directly (ie. in SQL) on the database is completely unsupported by the OME team except in very specific cases.