[ome-devel] Issue after upgrading from 4.4.5 to 4.4.9

[Josh Moore]

Hey Niko,

On Nov 14, 2013, at 10:59 AM, Niko Ehrenfeuchter wrote:

> Hi Will,
> 
> On 13.11.2013 15:22, Will Moore wrote:
>> 
>> $ psql omero
>> omero=# select * from image where name='Test.tiff';
> 
> the database reveals a total of 38 images for this user, here's four of them:
> ...
> so here everything looks fine to me

Agreed.


>> Then use the image ID to search for the image in web by going to the /webclient/ query url like:
>> 
>> your-server-name/webclient/?show=image-123
> 
> using e.g. ID 40244 as admin shows the image correctly, and it even displays the whole tree of this user, including all his other images. Still, logging on as myself does not show anything - the user's tree is still empty and using the above webclient query results in the same, empty view.
> 
> Indeed, very confusing. Any ideas?

The most likely cause I can think of would be mis-linked data. Were these images (or the dataset they're in) moved between groups recently? Just before the upgrade? You might try running the following SQL query:

  select distinct p.group_id, pdl.group_id, d.group_id, dil.group_id, i.group_id
    from project p, projectdatasetlink pdl, dataset d, datasetimagelink dil, image i
   where p.id = pdl.parent and pdl.child = d.id and d.id = dil.parent and dil.child = i.id and i.owner_id = YOURUSERID;

Output looks something like:

 group_id | group_id | group_id | group_id | group_id 
----------+----------+----------+----------+----------
        9 |        9 |        9 |        9 |        9
        8 |        8 |        8 |        8 |        8
      153 |      153 |      153 |      153 |      153
        3 |        3 |        3 |        3 |        3
      303 |      303 |      303 |      303 |      303
(5 rows)

where any row that doesn't have equal values would be a "Bad Thing".

Cheers,
~Josh

P.S. regarding your LDAP question:

> It is really important for us to have this working again, how can we 
> debug this? Unfortunately (at least in this case) we are using LDAP/AD 
> authentication, I can't even temporarily set a password for debugging 
> purposes, so I won't be able to test by impersonating as this user. At 
> least unless there is a safe way to temporarily disable LDAP for *this* 
> user and re-enable it later on...

See bin/omero ldap setdn -h

  Set DN for user (admins only)

  Once the DN is set for a user, the password set via OMERO is
  ignored, and any attempt to change it will result in an error. When
  you remove the DN, the previous password will be in effect, but if the
  user never had a password, one will need to be set!

You can get the DN with bin/omero ldap getdn. ~J