Context
What is the issue that we're seeing that is motivating this decision or change?
When we expire temporary accounts, we do this with a maintenance script, ExpireTemporaryAccounts, which checks if now - account creation date > number of configured days for temp account expiry. Then, the script calls AuthManager::revokeAccessForUser and SessionManager::invalidateSessionsForUser.
What we don't do is store in the database when exactly an account was expired, or an indicator that allows us to know that it is expired.
We have a few tasks, however, where it would be useful to have this information:
- T358030: Denote whether a temporary account is expired for third party tools access
- T358469: Display expired temporary account names differently
- T357935: Show temp user status on Special:CentralAuth/<username>
- T375773: Ensure that Echo does not send notifications to expired temporary accounts
Proposal
What is the change that we're proposing and/or doing?
Option 1
@Dreamy_Jazz and I discussed reusing user_email_token_expires or user_password_expires to store the timestamp of when a temporary account was expired. (Neither of those fields could ever be used by a temporary account.) Coupled with some helper methods, one would then be able to easily see if a temp account is expired, and the time that it expired. The downside is that we would then be storing data that is unrelated to the original purpose of those fields, potentially resulting in confusion and adding technical debt.
Option 2
Use the logging table and record when an account is expired. Downside is that we are adding another row to the DB for every temporary account. Benefit is that this is a much more logical place to record the information, compared to repurposing an existing column on the user table.
Additional notes:
- if a temporary account is created via an edit on a wiki, then it visits all our other projects, we'd potentially be creating a log entry on every wiki where this user has an account
- we could consider only creating a log entry on wikis where the user has made a loggable event (beyond autocreation).
Option 3
Add a new column to the user table to store a timestamp of the actual expiration of a temporary account.
We'd need to do a schema change for this. And we'd also end up adding a column that isn't used by named accounts.
Option 4
Add a column to a CentralAuth global table and use that to denote the expiry of the temp
Option 5
Create a new table specifically for holding data related to temporary accounts (user ID, expiry timestamp).
Consequences
What becomes easier or more difficult to do because of this change?
Option 1
- We introduce some amount of technical debt / confusion by repurposing an unused column (for temp accounts) on the user table to indicate the expiry date of a temporary account
- We make it easy to know if and when a temp account is expired, without any joins
Option 2
- We add a row in the logging table for every temporary account
- We make it easy to know if and when a temp account is expired, requiring a query to the logging table
- The same row is written to all wikis where the temporary account exists
Option 3
- We need to do a schema change
- We add a column for data that is only going to be used by some user accounts
- We make it easy to know if and when a temp account is expired, without any joins
Option 4
- We need to do a schema change
- We add a column for data that is only going to be used by some user accounts
- We make it easy to know if and when a temp account is expired, but will require access to a global, shared database when looking up information for temporary account users
Option 5
- We need to create a new table (globally or local?)
- We'll need to add a row for each temporary account (globally or local?)
- We'll need to join with this table when loading user data to be able to say if/when an account is expired