binary_access `+plate` config throws UnloadedCollectionException for wellSamples

[Rdornier]

Hello,

Jumping from this issue, it seems that the omero.policy.binary_access configuration, if set to +read +write +image +plate, prevents the loading of wellSamples from the API (UnloadedCollectionException) at the ImageData level.

If this config is set to default, the wellSamples are loaded correctly. A minimal script is available in the above mentioned issue to test.

It seems to be a side effect of this config which, according to what I understand from the doc, should give the access to the binary files and allow the download of the plates from the webclient

Rémy
cc @gaelrayot-epfl

[dominikl]

This is an odd error, binary_access should only affect download of images, plates, etc. But indeed, I can replicate the problem:

Plain, clean OMERO.server installation, no config changes, only one plate imported. Running:

...
BrowseFacility bf = gw.getFacility(BrowseFacility.class);
List<WellSample> samples = bf.getImage(ctx, 1).asImage().copyWellSamples();
System.out.println(samples.size());

gives:

1

Then changing server setting:

omero config set omero.policy.binary_access "+read,+write,+image,+plate"

Run above code again, now gives:

Exception in thread "main" omero.UnloadedCollectionException: Error updating collection:wellSamplesSeq
Collection is currently null. This can be seen
by testing "wellSamplesSeqLoaded". This implies
that this collection was unloaded. Please refresh this object
in order to update this collection.
	at omero.model.ImageI.throwNullCollectionException(ImageI.java:40)
	at omero.model.ImageI.copyWellSamples(ImageI.java:698)

[dominikl]

Same with Python API.

Default binary_access:

> python test.py
1

With +plate:

> python test.py
Traceback (most recent call last):
...
  File "/Users/dom/micromamba/envs/idr/lib/python3.10/site-packages/omero_model_ImageI.py", line 98, in throwNullCollectionException
    raise _omero.UnloadedEntityException(""+
omero.UnloadedEntityException: Error updating collection:wellSamplesSeq
Collection is currently null. This can be seen
by testing "wellSamplesSeqLoaded". This implies
that this collection was unloaded. Please refresh this object
in order to update this collection.

Script:

with omero.cli.cli_login() as c:
     conn = BlitzGateway(client_obj=c.get_client())
     img = conn.getObject("Image", 1)
     print(len(img._obj.copyWellSamples()))

[sbesson]

I finally found some time to investigate this issue and I believe the current behavior is expected although I understand it is confusing.

I was able to reproduce the issue by importing a simple test&plates=1.fake file into a blank OMERO.server and running the following minimal code in Python

i = s.getQueryService().findByQuery("select i from Image i where i.id=1", None)
i.copyWellSamples()

With the default configuration, the code above works as expected. If the policy is set to allowing plate download, either by setting omero.policy.binary_access and restarting the server or more by setting omero obj map-set ExperimenterGroup:<id> config -- omero.policy.binary_access +plate, i.copyWellSamples() throws an omero.UnloadedEntityException as described above.

Importantly, the HQL query as written above does not fetch the wellSamples associated with the Image object. When hydrating the object, the server also returns its permissions which include the extended restrictions associated with the binary access policy introduced in OMERO 5.1.0 via ome/openmicroscopy#3593 and ome/openmicroscopy#3625.

In the most permissive binary access policy i.e. +read,+write,+image,+plate, these extended restrictions return with no additional loading and the state of the Image object is consistent with the HQL query. When plate download is restricted as in the default binary policy, the following lines of code will load the wellSamples collection associated with an image in order to establish whether it is part of a plate, effectively populating wellSamplesSeq and allowing copyWellSamples() to work out of the box:

omero-server/src/main/java/ome/security/policy/BinaryAccessPolicy.java

Lines 140 to 144 in 3e229ed

	if (noPlate) {
	Image img = (Image) obj;
	if (has(img, Image.WELLSAMPLES)) {
	return true;
	}

omero-server/src/main/java/ome/security/policy/BinaryAccessPolicy.java

Lines 202 to 213 in 3e229ed

	private boolean has(IObject obj, String field) {
	try {
	Collection<?> c = (Collection<?>) obj.retrieve(field);
	Hibernate.initialize(c);
	if (c != null && !c.isEmpty()) {
	return true;
	}
	} catch (AssertionFailure ae) {
	// pass
	}
	return false;
	}

Although it might be possible to enforce consistency between both scenarios by unloading collections that were loaded only for the restrictions checks server-side, this would need additional thoughts and I am concerned by the implications of such unloading operations both in terms of performance and possible regressions.

Instead I would suggest the proper workaround is to update the client-side application to fetch the wellsamples as part of the query. The following query should always load well samples associated with an image independently of the binary policy

i = s.getQueryService().findByQuery("select i from Image i join fetch i.wellSamples where i.id=1", None)
i.copyWellSamples()