Arvados

Test with both wb1 and wb2, failure to activate should land them at the inactive user page, no error.

This is weird because workbench is getting is_invited true (which should allow the user to self-activate) but when the user tries to activate, they get "cannot activate because not invited".

I don't know where "is_invited: true" is coming from. When I use "arv", the same field is "false" as I would expect.

A few notes.

The "is_invited" flag is returned for the local cluster, not the LoginCluster. That's because it isn't a real field, it is a virtual field defined as:

self.is_active ||
Rails.configuration.Users.NewUsersAreActive ||
self.groups_i_can(:read).select { |x| x.match(/-f+$/) }.first

User is "invited" if they are active, or NewUsersAreActive is set, or they have been granted permission to read things shared with the "all users" group. An "invited" user can self-activate.

When a user is "set up", it sets that last permission.

AutoSetupUser is "true" on tordo but "false" on ce8i5.

This creates a situation where users on tordo are "set up" and invited (but not active), but not invited on ce8i5. Since ce8i5 is the login cluster which calls the shots, the user shouldn't be "set up" or invited on tordo at all.

If the user tries to activate themselves on tordo, this fails because they are not invited on ce8i5. But the "is_invited" flag is how workbench decides when to try to self activate, so it gets stuck in a loop.

On one hand this is "just" a configuration error. However, we should handle it better because it is very hard to debug.

It checks if the user should be unsetup before user.save! in ApiClientAuthorization#validate. But if the user is a new user, they will be set up in an after_create hook, which doesn't happen until user.save!. For the case where we need to unsetup the user, it probably needs to happen after user.save!.

The config check should probably also issue a warning that AutoSetupNewUsers will be ignored on satellite cluster.

16914-inactive-user @ arvados|b096358dfbd438e89d77b6d4899817b82aca3ca3

developer-run-tests: #2124

This LGTM, please merge.

16914-inactive-user @ arvados|1a343a507d7e4bdf56bc5e6108996f0894b11a9c

Fix bug introduced by previous merge, the UserGet method didn't pass along which fields were selected, as a result if is_active had not been selected, it would send the default value of is_active (false).

Includes a couple of other cleanups and additional testing.

developer-run-tests: #2125

Updates at 1a343a5 LGTM, thanks for the detailed testing!