Bug: getThumbnailByLongestSide in read-only / private groups

[wmoore]

tb.getThumbnailByLongestSide() fails for non-owners in private or read-only groups.

I believe this bug exists for dev_4_4 and develop.

E.g. Import SPW data as a regular member of a private group:

$ omero import ~/Documents/biology-data/SPW/mias-frans/siRNA_PRIM1_03102008/
Using session eed7e559-ddb7-48aa-924a-3b3428765707 (will@localhost:4064). Idle timeout: 10.0 min. Current group: private
2013-03-27 14:27:25,730 0          [      main] INFO          ome.formats.importer.ImportConfig  - OMERO Version: 5.0.0-alpha1-DEV-ice34
...

Then try to get the thumbnail as 'root'

...
conn.SERVICE_OPTS.setOmeroGroup(-1)
i = conn.getObject("Image", 24)
jpeg = i.renderImage(None, None)
jpeg.show()    # PIL Image shown
tb = i.getThumbnail()


WARNING:omero.gateway:ReadOnlyGroupSecurityViolation on <class 'omero.gateway.OmeroGatewaySafeCallWrapper'> to <83c7cf1a-faa7-4975-89c8-e4328bbe1543omero.api.ThumbnailStore> getThumbnail((object #0 (::omero::RInt)
{
    _val = 64
}, object #0 (::omero::RInt)
{
    _val = 64
}, <ServiceOptsDict: {'omero.session.uuid': '43ad1d91-0f0d-43dc-8bad-1b2695cb6702', 'omero.group': '5', 'omero.client.uuid': '17c468ea-b24d-44a0-92e7-3474ce6cc066'}>), {})
Traceback (most recent call last):
  File "/Users/will/Desktop/OMERO/dist/lib/python/omero/gateway/__init__.py", line 3455, in __call__
    return self.f(*args, **kwargs)
  File "/Users/will/Desktop/OMERO/dist/lib/python/omero_api_ThumbnailStore_ice.py", line 179, in getThumbnail
    return _M_omero.api.ThumbnailStore._op_getThumbnail.invoke(self, ((sizeX, sizeY), _ctx))
ReadOnlyGroupSecurityViolation: exception ::omero::ReadOnlyGroupSecurityViolation
{
    serverStackTrace = ome.conditions.ReadOnlyGroupSecurityViolation: Cannot link to ome.model.core.Pixels:Id_23
Current user (root) is an admin or the owner of
the private group (private=rw----). It is not allowed to
link to users' data.
	at ome.security.basic.OmeroInterceptor.evaluateLinkages(OmeroInterceptor.java:464)
	at ome.security.basic.OmeroInterceptor.onSave(OmeroInterceptor.java:154)
......
	at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:643)
	at java.lang.Thread.run(Thread.java:680)

    serverExceptionClass = ome.conditions.ReadOnlyGroupSecurityViolation
    message = Cannot link to ome.model.core.Pixels:Id_23
Current user (root) is an admin or the owner of
the private group (private=rw----). It is not allowed to
link to users' data.
}

[wmoore]

Update: On import with the command line (and Insight too?) we generate thumbnails of 96 x 96 for SPW as well as single images.

If we try to render a different-sized thumbnail using thumbnailStore.getThumbnailByLongestSide() we get errors. E.g. regular user in a read-only group (see below) or Admin in a private group (above).

Recent changes to the Blitz Gateway image.getThumbnail() didn't change the API (we still use direct=True by default) but the webgateway was changed to use direct=False
​https://github.com/openmicroscopy/openmicroscopy/pull/746

Webclient renders thumbs of size 96 in a Dataset (which works), but size 64 in SPW (which fails - IN a READ-ONLY / private group).

If I import an image (E.g. DV) via the command line in a read-only group, then try to getThumbnail(direct=False) as another user in that group it fails, unless we use size=96 (to match the existing cached thumbnail).

This means that the webgateway/render_thumbnail/<iid> fails.

# i is an image belonging to another user in a READ-ONLY group...
>>> tb = i.getThumbnail()                                         # OK (since direct=True)
>>> tb = i.getThumbnail(size=96, direct=False)                    # OK (since we have cached thumbs at 96x96)
>>> tb = i.getThumbnail(direct=False)                                   # Fails (uses size 64 by default)...
>>> tb = i.getThumbnail(size=100, direct=False)                  # Fails...

WARNING:omero.gateway:InternalException on <class 'omero.gateway.OmeroGatewaySafeCallWrapper'> to <06012f33-0aeb-4a3c-8df1-0bbecb973b25omero.api.ThumbnailStore> getThumbnailByLongestSide((object #0 (::omero::RInt)
{
    _val = 100
}, <ServiceOptsDict: {'omero.session.uuid': '63ffc9f2-d30c-452c-afa5-a6f807d0a37c', 'omero.group': '6', 'omero.client.uuid': 'ff1cfd32-24d1-4f6b-8473-5dad07fd116a'}>), {})
Traceback (most recent call last):
  File "/Users/will/Desktop/OMERO/dist/lib/python/omero/gateway/__init__.py", line 3428, in __call__
    return self.f(*args, **kwargs)
  File "/Users/will/Desktop/OMERO/dist/lib/python/omero_api_ThumbnailStore_ice.py", line 215, in getThumbnailByLongestSide
    return _M_omero.api.ThumbnailStore._op_getThumbnailByLongestSide.invoke(self, ((size, ), _ctx))
InternalException: exception ::omero::InternalException
{
    serverStackTrace = ome.conditions.InternalException: Fatal error retrieving thumbnail metadata for Pixels set id:152
	at ome.services.ThumbnailCtx.getMetadata(ThumbnailCtx.java:442)

[wmoore]

Seems like this issue has been around for a while.

In OmeroPy/test/integration/thumbnailPerms.py if I comment out this line:

self.getThumbnail(client_share1.sf, privateImageId)    # if we don't get thumbnail, test fails when another user does

I get this:

jrs-macbookpro-25107:test will$ python integration/thumbnailPerms.py
======================================================================
ERROR: testThumbs (__main__.TestThumbnailPerms)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "integration/thumbnailPerms.py", line 156, in testThumbs
    self.getThumbnail(owner_client.sf, privateImageId)
  File "integration/thumbnailPerms.py", line 246, in getThumbnail
    t = thumbnailStore.getThumbnail(rint(16),rint(16))
  File "/Users/will/Desktop/OMERO/dist/lib/python/omero_api_ThumbnailStore_ice.py", line 179, in getThumbnail
    return _M_omero.api.ThumbnailStore._op_getThumbnail.invoke(self, ((sizeX, sizeY), _ctx))
ResourceError: exception ::omero::ResourceError
{
    serverStackTrace = ome.conditions.ResourceError: The user id:120 may not be the owner id:121. The owner has not viewed the Pixels set id:184 and thumbnail metadata is missing.
	at ome.services.ThumbnailCtx.getMetadata(ThumbnailCtx.java:435)
	at ome.services.ThumbnailBean.getThumbnail(ThumbnailBean.java:995)

.....
	at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:643)
	at java.lang.Thread.run(Thread.java:680)

    serverExceptionClass = ome.conditions.ResourceError
    message = The user id:120 may not be the owner id:121. The owner has not viewed the Pixels set id:184 and thumbnail metadata is missing.
}

----------------------------------------------------------------------
Ran 2 tests in 6.574s

FAILED (errors=1)

[wmoore]

Similar issues with thumbnail creation may be related - see #10665.

[jamoore]

cF #10827

Would it violate the API/expectation if the server returned the results from getThumbnailDirect() in all such cases?

[jamoore]

Escalating to blocker in 4.4.9 so this doesn't slip through again.

[jamoore]

PR opened which describes the behavior of thumbnail store: ​https://github.com/openmicroscopy/openmicroscopy/pull/1500 Closing.

Note: in discussion with Will, it was pointed out that this may come down strictly to the proper use of the "omero.group" (i.e. SERVICE_OPTS) setting in the gateway. #11427 recently made related changes and the two should be evaluated together on this PR and it's rebased partner.

[jmoore <josh@…>]

(In [0021ec0e7495875addc835515467944d5b36d638/ome.git] on branch develop) Various tests for thumbnails (See #10618)

[jmoore <josh@…>]

(In [1f2d287b857424067e458f3071ada56fca23ff85/ome.git] on branch develop) Test ImageWrapper?.getThumbnail (See #10618)

This gatewaytest goes through various combinations
of the uses of getThumbnail(). They are all currently
passing which points to 10618 actually being an API
usage issue.

[jmoore <josh@…>]

(In [39d6227b233c7b17f4aae9a2473b8fd800af8c9d/ome.git] on branch develop) Set direct=True on missing metadata (See #10618)

Rather than throw an InternalException?, ThumbnailCtx?
now throws a NoThumbnail? (caught) exception. Either
this is turned into a ValidationException? or another
method is used to synthesize a Thumbnail (at the cost
of more overhead)

[jmoore <josh@…>]

(In [a50cfed0db2f33dbd5db9cd773d6d4e97ed67482/ome.git] on branch develop) Refactor into handleNoThumbnail for read-only issues (Fix #10618)

After the last fix, 2 tests were still failing when root tried to
access thumbnails. Now all 24 tests are passing.

[jmoore <josh@…>]

(In [60d9d003538c49c4eda1c75749805ee52a3abfa7/ome.git]on branches master, dev_4_4) Various tests for thumbnails (See #10618)

[jmoore <josh@…>]

(In [d85a0166b93b5c9ab27c2cc09f5b06a7e0b8c55c/ome.git]on branches master, dev_4_4) Test ImageWrapper?.getThumbnail (See #10618)

This gatewaytest goes through various combinations
of the uses of getThumbnail(). They are all currently
passing which points to 10618 actually being an API
usage issue.

[jmoore <josh@…>]

(In [b5734429e8669497676bb74403f5cf09076760c2/ome.git]on branches master, dev_4_4) Set direct=True on missing metadata (See #10618)

Rather than throw an InternalException?, ThumbnailCtx?
now throws a NoThumbnail? (caught) exception. Either
this is turned into a ValidationException? or another
method is used to synthesize a Thumbnail (at the cost
of more overhead)

[jmoore <josh@…>]

(In [b3fd40cd3de6fe5f43ad8e317e6faee0fd2ad7e7/ome.git]on branches master, dev_4_4) Refactor into handleNoThumbnail for read-only issues (Fix #10618)

After the last fix, 2 tests were still failing when root tried to
access thumbnails. Now all 24 tests are passing.