[cms] Account deactivation flow

[xaur]

We need to handle when a contractor goes inactive for a few months.

Below are things to consider to design this process.

1. What is the definition of "inactive"?

We can start with "have not submitted an invoice for X months".

2. For how long the user needs to be "inactive" to become deactivated?

Like 6 months of no invoices?

3. Can a deactivated user login? What can he do?

Option 1: You can have your stuff

• Allowed: login, manage account (change password, export identity, edit profile), see all past invoices he submitted, review expenses for owned proposals
• Not allowed: see any invoices of other users, submit invoices

This gives inactive/past contractors convenience to access their stuff.

Option 2: Restricted account

• Allowed: login, manage account
• Not allowed: see any data, not even owned invoices or proposals

This balances between some access and minimizing the surface.

Option 3: Keep them out

• Allowed: authenticate and see "your account has been deactivated" as a login error response
• Not allowed: everything else

This is most secure for CMS because the surface is minimized.

In any case, the user must be informed of (a) current state and (b) what to do next:

Your account has been deactivated. Reason: {reason}. Please contact admins to reactivate {contacts}.

4. How Proposal contractors are handled?

• Does the account auto-deactivate when the proposal duration is over?
• Or handle them same way as DCC contractors? (less rules is simpler)

5. How Temporary contractors are handled?

• Do "one-shot" temporary accounts have a "validity period" after which they are deactivated?
• Or handle them same way as DCC contractors?

6. What data must be recorded upon deactivation?

I suggest to record the "when, who and why": date-time of deactivation, what admin did it, and reason text to show to the user.

[xaur]

Importantly, at the data layer I think deactivation should be stored as a separate flag to not interfere with Domain and ContractorType characteristics. This will allow to deactivate users without losing that information, and not having to recover it from elsewhere when they are reactivated. If we abuse user's ContractorType field for this, we will need to know what to set it back to when reactivating.

I suggest to call the flag is_active or just active to use positive boolean names (because X is simpler than not X).

[xaur]

Consider adding a process where users are deactivated automatically after a period of inactivity. Someone suggested to set this period to 3 months of not submitting an invoice. Should the user need to bill again they will be reactivated manually.