[ome-devel] IAdminService changeGroup problem
Joshua Moore
josh.moore at gmx.de
Sat May 31 14:15:48 BST 2008
Hi Simon.
> I'm trying to change the ownership of projects, datasets and Images, but
> I'm not completety sucessful:
That's understandable. At the moment, the security system is extremely cautious. We're starting to see ever more collaboration use-cases where things need to be (configurably) more open. It would be great to get a better idea of what you would like to do with OMERO's users/groups.
> I import my images as an admin user and change the ownership later.
Can you explain your workflow? Why are you uploading as an admin? One possibility would be for the admin user to specify the proper user/group on upload (a client-side change), though quite possibly you don't have that information during import.
> I use sf.getAdminService().changeOwner(...) for projects, datasets and
> Images. This works, and OMERO.insight shows me the right ownerships.
>
> But I can't delete my images within OMERO.insight, by doing this I get
> the following exception: DS.OutOfServiceException: Cannot delete the
> object.
>
> I inspected the database and see, that the group ownership is still
> system, so i tried to change this to the group of my user, using
> changeGroup(...).
Right, so far.
> But this doesn't work: I get a SecurityViolation; Object locked! Cannot
> change group for entity:.....
>
> So how do I use changeGroup(..) correctly ?
The short answer for now is you don't. Background information to locking is available at http://trac.openmicroscopy.org.uk/omero/ticket/337 . Briefly, locking is there to prevent objects which were once public, from losing their public status, which breaks things.
For example, assume you've uploaded an image as world or group readable. Another user could have added that image to his or her dataset, and if you come along and make it private, then attempts by the user to load that dataset will fail.
At the moment, that check is done when the image is linked to by another object, since there is significant overhead to check for links on every read. 'til now, that has been sufficient, but we can certainly discuss ways to improve the algorithm.
> Thank you, Simon
More than welcome,
~Josh
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
More information about the ome-devel
mailing list