Open Rdornier opened 1 year ago
In the end, it could be nice to integrate this script directly during the ownership changing process (i.e. when clicking on "change ownership") rather than running the script first to add the owner as KVP and then changing the ownership. But this is the next step.
Hey @Rdornier! Thanks for this, and very sorry for having missed it originally. We're now in a bit of a summer gap, but we'll get this in front of some folks for a review ASAP.
Hi @Rdornier - Apologies for not looking at this sooner...
The script works well, ran as a regular user...
Then I logged-in as an Admin, and changed the owner of an Image to another member of the group (Admin wasn't a member of this group) and I tried running the script again as an Admin.
This attempted to remove the previous annotation, which failed (see error below), so the annotations didn't get updated at-all. I'm not sure why the Admin didn't have permission to remove the annotation, but probably the new owner also wouldn't have permission to remove the old annotation (unless in a read-write group).
If I commented-out the # remove_map_annotations(conn, obj, namespace)
line and ran the script again (as Admin) it combines the ownership history nicely, but we are still left with the previous annotation:
I don't know how the permissions will work in your typical use case, but at the very least you should try/catch
the removal of annotation (or test if you can delete) so that the script doesn't fail in this case.
Maybe safer to assume that you can never remove previous annotations and always just add a single annotation.
Hello @will-moore
Thanks for having a look to my code and to figure this issue. I actually struggled a bit with this deletion issue and I thought it was fixed.
Anyway, I pushed some modifications and key-values are not deleted anymore. I only add them in the namespace. So this issue should be corrected now.
I don't know how the permissions will work in your typical use case, but at the very least you should try/catch the removal of annotation (or test if you can delete) so that the script doesn't fail in this case.
Yes, I did it only on SecurityViolation
, not on CmdError
. I should had done it on Exception
Maybe safer to assume that you can never remove previous annotations and always just add a single annotation.
Done
but we are still left with the previous annotation:
This is corrected now. I only link the MapAnnotationWrapper
if it does not exist yet (i.e. link it once to the object)
Hello,
As suggested, here is a python script implementing ownership tracability as a key-value pair.
The script accepts as input arguments either image ids, container ids (dataset, project, well, plate, screen) or usernames. For images and containers, their ID is required and the script adds the owner-keyVal to the specified images/containers and all their children. For users, their omero-username is required and the script adds the owner-keyVal to all data owned by the users, in all groups they are member of.
If the logged-in user is admin, a sudo connection is established.
I created an excel sheet where I consigned the results of different tests I have done but, as you'll see, there is a scenario I do not really understand. I thought it was possible to add the key-value on data owned by someone in a private group with a sudo connection but, apparently, it is not the case.
Happy to answer any questions and to improve the script. Thanks and all the best,
Rémy.