Hi Chris, Erick,
I think you can achieve everything using standard group permissions except hiding ROIs from other users in a Read-Annotate group (group needs to be Read-Annotate to allow you to add ROIs to someone else’s Image).
Off the top of my head, I am thinking that a partial solution might be possible by overriding the URLs that OMERO.iviewer uses to load and save ROIs.
In OMERO.web 5.6.3 there is an option to set an app as the ‘root’ app under
/. See https://github.com/ome/omero-web/pull/123
This app e.g.
my_app could be used to implement a URL such as
my_app/api/v0/m/rois/ which would override the existing URL
my_app was set as the root app, since Django will take the first URL that matches, see:
This would allow you to customise the behaviour of
/api/v0/m/rois/ (which iviewer uses for loading ROIs) or
/iviewer/persist_rois/ (for saving ROIs).
I imagine you could distinguish from users and ‘Markers’ by making the Markers into group owners.
The simplest option would be to NOT load ROIs from other users, unless current user is a ‘Marker’ (and leave the saving behaviour unchanged). This would only take a few of lines of code and users would allow users to save their ROIs without seeing other users’ ROIs. And ‘Markers’ would see everyone’s ROIs. However, users would still have permission to access the ROIs using other methods (e.g. use the Insight client).
To work around this would need a more elaborate solution. For example, the ROI save behaviour could store the ROIs in a private ‘Answers’ group (different group from the read-annotate group that the Images are in). You’d need some annotation to indicate that the images were created from ‘Image:123’ in the read-annotate group, but this couldn’t be a direct link since you can’t link between objects in different groups.
The, the ROI loading behaviour could be overridden to allow the ‘Markers’ (group owners) to retrieve the ROIs from the private group.
I don’t know how you want to store the results in OMERO? I guess you could use a similar strategy.
This approach would need some testing and validation before I’d say it’s a “solution”. It’s possible there are some blockers that haven’t occurred to me, but if you’re interested in giving this a try, we could certainly give you some pointers. As a first step, the “simple solution” would be quite easy to evaluate.