Open Microscopy Environment

Hi,

this bug is probably very closely related to #8040, but we didn't make any changes using the web interface.

We have LDAP authentication in place (to be more precise, we're authenticating against the ActiveDirectory here) which works very nice in general. Since we're just in the process of evaluating and setting up OMERO, I haven't configured any automatic (LDAP-based) groups yet, but decided to go for manual administration here.

Recently, I added one of our users to a specific group and removed it from the default group where it was added automatically upon the first logon. The same was performed on my personal (non-administrator) user account, but I once logged on with it selecting the new group before the membership of the default group was removed with the administrative account.

Now I still can log on with my personal account ending up in the right group, but the user that hasn't logged on before the membership of the default group was removed can't log on anymore, even though she is member of a valid group. Manually adding her to the default group doesn't solve the problem.

All of this was performed using the latest official OMERO client. I also had a quick look in the database tables, but I didn't change anything for obvious dangers of breaking the whole thing (and I couldn't see what's different for this user account compared to mine).

I tried to attach the relevant excerpt of Blitz-0.log but unfortunately the board didn't let me do so. It was complaining for ".log" or ".txt" not being a valid filename suffix. I can add it as a separate post if desired, otherwise here's the main messages:

Code: Select all

2012-05-18 09:56:16,209 WARN  [ome.services.sessions.SessionManagerImpl] (l.Server-3) Exception while running executeDefaultGroup
ome.conditions.ValidationException: The user 54 has no default group set.
....
....
2012-05-18 09:56:16,214 INFO  [        ome.services.util.ServiceHandler] (l.Server-3)  Excp:    ome.conditions.ApiUsageException: Can't find default group for ferranda


Thanks a lot in advance!

~Niko

One of the groups must be assigned as "default" for the user, that is done with the radio button on the left hand side of the "Edit scientist" dialog in OMERO.webadmin. If something funny has gone on with the user because of the add / remove actions that you've performed it would be helpful to have the output of the following query on your database:

Code: Select all

...
SELECT * FROM groupexperimentermap WHERE child IN (SELECT id FROM experimenter WHERE omename = '<username>');
...


here we are:

Code: Select all

omero=> SELECT * FROM groupexperimentermap WHERE child IN (SELECT id FROM experimenter WHERE omename = 'ferranda');
id | permissions | owner | version | child | external_id | parent | child_index
----+-------------+-------+---------+-------+-------------+--------+-------------
60 |        -103 | f     |       0 |    54 |             |      1 |           0
61 |        -103 | f     |       0 |    54 |             |      3 |           1
70 |          -7 | f     |       0 |    54 |             |     53 |           2
(3 rows)


I'm not sure how it happened, but you lost your primary group (the one with child_index = 0). Before we try to figure out how that happened you can try issuing:

Code: Select all

begin;
update groupexperimentermap set child_index = 1 where id = 60;
update groupexperimentermap set child_index = 0 where id = 61;
commit;


to correct the problem.

~Josh

Thanks Josh,

I'll try this as soon as the Deutsche Bahn releases me from this jail. VPN unfortunately isn't stable enough over the mobile phone

Cheers
Niko

Sorry, forgot to update you on this one... Fixing the group mapping in the DB worked, the users are happy again.

Now for trying to reproduce what happened, iirc this was my workflow:

1) a user logs on for the first time (authentication via LDAP but no group assignment)
2) the user is dropped in the "default" group by OMERO
3) from the root account (or an account with enought privileges), I select the desired group, then "Add existing user" and finally add the user via the dialog that is presented
4) then I open the "default" group and select "cut" on the new user to remove it from there

This hasn't been an issue for some of our users, while it prevented any login for others. Maybe the last step can only be done when the new user has logged in at least once, after it has been assigned to the non-default group?

Thanks,
Niko

Could it be the the difference is whether or not the user is in any other group, or are all the users you're referring to only in the "default" group? If so, the bug in OMERO may be that if a user has been removed from the last group, then on re-adding a group, it should be made the default.

~J.

Sorry, I've been away during the last week...

Unfortunately I'm not 100% sure anymore about the group memberships when the error occurred. My memory goes like this: my own user account (which was alright) was just member of one group (our facility group), but I probably logged on after adding my account to this group AND before removing it from the "default" one (and I probably switched the group then in the client, and disconnected).

The other accounts just once logged on (to make the account show up in the administration section), then I added them to the corresponding group AND removed them from the default one at the same time. After this, logging on didn't work anymore for them.

So, that's what I remember. I'm sorry that I can't be more precise. Maybe I can grep for the corresponding entries in the log files?

Thanks,
~Niko

Hi Niko,

I think I reproduced and fixed the issue you were seeing. Do let us know if it happens again with 4.4.

Cheers,
~josh

Hi Josh,

good to hear. I will keep an eye on this after the upgrade.

Thanks for debugging this!
Cheers
~Niko