plugins and different group situation

[pwalczysko]

Several omero CLI plugins are not performing in situations where the object the action is to be performed on is in a different group than the one the user is logged into. There is also no indication in the error report what the problem might be (i.e. it is solved by logging in into the group where the object is in using the -g flag). The output instead is just reporting "not found", see below.

For example

omero duplicate Dataset:79809 --dry-run --report
Using session for pwalczysko@nightshade.openmicroscopy.org:4064. Idle timeout: 10 min. Current group: My Default Group
omero.cmd.Duplicate Dataset:79809 failed: 'graph-fail'
failed: cannot read ome.model.containers.Dataset[79809]
Steps: 3
Elapsed time: 0.03 secs.
Flags: [FAILURE, CANCELLED]

cc @joshmoore

[pwalczysko]

Possibly other than omero duplicate are failing too, but my initial testing on reander and metadata were showing these were able to find the object located in another group...

cc @sbesson

[sbesson]

Looking briefly, I am pretty sure the render and metadata plugins (and potentially others) are making cross-group gateway calls using omero.group: -1 as the context of the query.

In duplicate and generally other graph plugins, the CLI checking logic is more minimal as the commands are send fairly quickly to the server where the checks happen. Is the general expectation that the session group must always match the group of the source object for graphs?

[joshmoore]

Is the general expectation that the session group must always match the group of the source object for graphs?

I don't think so. It should also be possible to send omero.group with chgrp commands, but it may require loading the object. (The alternative would be to update the server code to load with --all)

[pwalczysko]

The other case we might (if it is feasible) to consider here is scripts - for example, scripts like https://github.com/ome/training-scripts/blob/master/practical/groovy/analyse_dataset_and_save_rois.groovy tacitly assume that the object they work on is in the group the user logged into afaik. This was remarked on by users on outreaches too.

[joshmoore]

I could see adding a helper to make this easier:

client.setSecurityContext( anyObject ); // Uses the group of the given object

but ultimately it will remain the responsibility of each script/plugin to call such a method.

[pwalczysko]

but ultimately it will remain the responsibility of each script/plugin to call such a method.

Yes, but it would be a major improvement of the workflow imho : the case I am remembering from the workshop was formulated as "Please do not burden me with the responsibility to know the group id upfront" The solution in https://github.com/ome/omero-py/issues/269#issuecomment-732130604 would give us an easy answer to lift such burden, well within reach of the capabilities of the user in above case.