Free up Usernames after deny/decline
What does this PR do?
Adds a new mod log type for decline, new Endpoint for declining which frees up the username from the used username table followed by it deleting the user.
This is essentially just a copied approve-user endpoint with the email text changed out and instead of marking the user approved it deletes the user and also frees up the username
Closes #752 (closed), #759 (closed)
Contribution Guidelines By submitting this merge request, you agree to follow our Contribution Guidelines
-
I agree to follow this project's Contribution Guidelines -
I have made sure to test this pull request
Merge request reports
Activity
added 1 commit
- 42530b5a - upd: add additional check from delete endpoint
- Resolved by Marie
the
user
table has aunique (usernameLower,host)
so deleting the user and freeing the name is not enough: trying to create another user with the same name will fail.
which is why I wrote #459 (comment 2128)
- Resolved by Marie
- Resolved by Marie
requested review from @fEmber
added enhancement label
mentioned in issue #759 (closed)
reset approvals from @fEmber by pushing to the branch
enabled an automatic merge when all merge checks for ed064b21 pass
- Resolved by dakkar
I am still uneasy about this.
If user
foo
signs up, then is rejected, then another userfoo
signs up and is accepted, we'll have two rows in theuser
table with the sameusernameLower
and nullhost
.I suspect that this will confuse every user lookup: I can't find any place that passes
isDeleted:false
to the various query methods onUserRepository
, so things like fetching a user's profile, or even logging in, may randomly pick up the deleted row instead of the "real" one.I would feel much better if, in addition to setting
isDeleted=true
, we mangled the username (my proposal was something like${username}\x01deleted\x01${Date.now()}
), using characters that are not normally allowed in usernames (but not the dot) so there's no chance of collisions.Also:
DeleteAccountService
will send out a bunch of AP activities that are completely useless, since no remote instance could have known about a non-approved account. Should be sufficient to do:await this.usersRepository.update(user.id, { isDeleted: true, username: mangledName, usernameLower: mangledName.toLowerCase(), }); this.globalEventService.publishInternalEvent('userChangeDeletedState', { id: user.id, isDeleted: true });