Arvados

Some notes on the investigation:

• Apparently the issue is with any kind of login: When logging in with an inactive local account on qr1hi, the account gets auto-activated.
• Wrote test that exposes the bug, still looking for the cause.
• Testing live clusters I found that:
  • Arvbox: BUG - f7d7147 (8 February)
  • Arvbox: BUG - ee8558ddd (5 December - previous to federated tokens)
  • qr1hi: BUG - 9b7a5de (12 December)
  • c97qk: GOOD - b3e8a48 (1 February)
  • 9tee4: GOOD
  • su92l: BUG
  • 4xphq: BUG

An account can be "inactive" and "setup" (aka "invited"). In that state, a user can self-activate if the "user agreement" requirement is met. Workbench calls "activate" automatically in this situation.

1. New user logs in using Google account → inactive account
2. Admin hits "setup" button (this adds the user to the "all users" group)
3. User is still inactive because user agreements are not signed
4. User signs user agreements (via Workbench)
5. Workbench detects that all user agreements are signed, and calls "activate" API
6. User is active

Otherwise, the admin would need to wait for the user to sign all user agreements before hitting the "setup" button, which would be annoying (even if the admin had an easy way to see whether they are signed, which they currently don't).

So perhaps we can rephrase this: "turning off the "is_active" flag is a tempting but ineffective way to disable an account." The admin "unsetup" button in Workbench is the right way.

As suggested by Tom Clegg on the chat, this issue is related to #10557 (021d36f17fe0329e869324d3764eaaf15c3a0771), we have two options:

• Show a notice to the user that making is_active=false is not the correct way of deactivating an account.
• Modify the API server so that it deactivates the user properly when this flag is set to false.

Personally I would prefer the second option for consistency purposes, but Tom suggested that proper user deactivation is hard to reverse, so I suppose that some kind of confirmation from the user would be needed.