WC2-434 Add support for multi-account users

[bramj]

This PR adds support for multi-account users without breaking the existing user setup. Note: The main issue is the auth_user_user_permissions table, because the permissions are linked to the Django auth_user (which we shouldn't touch) instead of the iaso_profile, we cannot do proper "user has many accounts" relations.

Proposed solution:

1. A user has access to account A. They are a regular Django auth_user with the configuration as we know it:

classDiagram
	direction LR
    auth_user "1" --> "1" iaso_profile
    iaso_profile "*" --> "1" iaso_account

2. User gets an invite for account B. Now the user becomes a multi-account user. The situation changes to: a main "authentication" user that's only used for authentication, 2 "account users" that are used to access account A and B respectively. Switching from account A to B means switching from account_user A to account_user B.

classDiagram
	direction LR
    auth_user "1" --> "1" iaso_profile
    iaso_profile "*" --> "1" iaso_account
    auth_user "1" --> "1" iaso_tenant_user : account_user
    auth_user "1" --> "*" iaso_tenant_user : main_user

This way, a "multi-account user" is actually a "main" auth_user that acts as a composition of auth_users, one for each account.

Caveats

• The column username needs to be unique on the auth_user, this means we need a different username per account. We don't really want this, but we can postfix the main_user's username with the account.name. Currently, I'm not displaying the user's username, first_name, last_name and email, these infos are actually coming from the user.tenant_user.main_user so the user has a more coherent experience. This leads to the question of what about editing these new users? I think we should not allow edition of these 4 fields when a user is a multi-account user.

Unresolved

• Password reset via email?
• What about superusers?
• What about users without iaso_profiles

TODO

• [ ] Improve the invitation flow
• [ ] Add new flow to WFP's Oauth flow
• [ ] Add unit tests for the TenantUser
• [ ] User editing: currently broken because of the username
• [ ] Properly handle all cases, user is invited to a third account etc.
• [ ] Ensure there's no security risks
• [ ] Documentation

Related JIRA tickets : WC2-434, WC2-435

Doc

• TODO

Print screen / video of current status

https://github.com/user-attachments/assets/20a8ce3c-d980-4c02-b394-6f4df5f8ff66

[kemar]

I understand we need some users to be in different accounts with different permissions, e.g user 1:

• in group A with permission x
• in group B with permission y

Even if the implementation you're suggesting introduces complexity, I can't think of a better one…

I had a quick look on some other solutions but none seems to fit our use case.

Some thoughts:

• we'll have some UI headaches (as you mention in your PR description)
• it'll skew the statistics of the number of users
• we should be careful not to put the same user several time in the same account

In my opinion, the simplest solution would be to not implement this feature and let users create several accounts when needed. But I guess that's not possible ;)

[bramj]

In my opinion, the simplest solution would be to not implement this feature and let users create several accounts when needed. But I guess that's not possible ;)

In an ideal world, that would be a great idea :D

[madewulf]

Not implementing the feature is what we've been doing for years and my argument was that only people internal to bluesquare needed that feature, so we could delay, but now, with the CIAM requirement of WFP there is a need for having access to multiple accounts with a single email address, so, we need to provide a solution although I agree that this brings on some complexity.