This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow admins to require a manual approval process before new accounts can be used (using MSC3866) #13556
Allow admins to require a manual approval process before new accounts can be used (using MSC3866) #13556
Changes from 1 commit
f7c9743
1eaff08
685f76f
5d08fe2
7b532a9
eedaed1
ffaea1e
0230200
562aa7a
868ab64
836aa32
8d091b4
116fc53
a87d2f7
08d85f5
7585098
75cf999
f4a7f16
df0c887
3f93dda
577967c
7a5425a
560e160
7d71712
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense to have a background job to rewrite when we could set it as a database default, either because
NULL
means approved (and new users are inserted withapproved = false
)or because there's a default value for the column*?
It feels like it would be less complicated. Note that any new users will already need
approved = false
upon registration because otherwise there's a race where a user can register before your migration is finished and then slip through as approved. Your background job might even be substantially delayed in starting because an earlier one is blocking it.*This involves rewriting the rows in table, except in Postgres 11+. Postgres 10 has an EOL in 2 months so we're close to being able to require it!
We probably don't need to worry about SQLite's behaviour even if it is rewriting rows (which it may not be actually), because those will be small databases.
that said ... Even on matrix.org-size servers, rewriting the rows in one go is probably not so bad, because:
That said I would still be tempted to just leave NULL meaning no approval required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using
NULL
as approved is an interesting idea, though I'm a bit on the fence with this because imo it's very easy to readNULL
on a boolean column as a false value, and it also means it needs a bit of special casing when handling it (because then we need to explicitly make ittrue
) which can end up a bit fiddly. I'd rather not use a default value since, as you point out, it involves rewriting the table in Postgres 10. That version reaching EOL in a couple of months is good news but I'd rather not block this PR on that.It's also worth noting that this background update is basically a copy of the one we already have for setting the deactivation flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually since writing this PR a similar question came up in #13799, to which the decision was to treat
NULL
astrue
, which isn't that much of a faff in the end. So let's go with that.