You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: The user who has not been approved should be automatically deleted from the system #4434
Did you check to see if this issue already exists?
Is this only a single bug? Do not put multiple bugs in one issue.
Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
Summary
Users who have requested registration, but who have not been approved by the administrators, are still present.
This appears to be a violation of the GPDR, as it does not allow users to delete their nickname (which in some cases could be a nickname containing a first and last name).
It may also constitute an anomaly in the instance's overall user count.
Steps to Reproduce
(If you are an administrator) you can access the link https://[INSTANCE]/registration_applications and go back to the first page to locate the first rejected users
Not exactly sure how to go about solving this one. The only thing I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month.
I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month
I am convinced that it would be appropriate to implement a function of this type within the system, because it would allow all administrators the possibility of cleaning: In fact, not all administrators are able to intervene on the database tables without causing damage.
Clearly it is not yet completely in line with the "privacy by design" principle, but if it were not possible to create automatic deletion mechanisms, then periodic alerts could be created for administrators or this cleaning procedure could be integrated with each new update of the instance to Lemmy's latest release.
FWIW, it should already be possible to have automatic cleanup by querying applications via API and issuing a purge via API, without resorting to DB editing.
changed the title [-][Bug]: The user who has not been approved should be automatically deleted from the system (GDPR right to erasure violation)[/-][+][Bug]: The user who has not been approved should be automatically deleted from the system[/+]on Feb 8, 2024
Not exactly sure how to go about solving this one. The only thing I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month.
When the instance admin clicks deny on the user application. Yeet the user DB entry. Due to the way the relation is setup between the local_user and application tables though, that would delete the application as well. If you want to keep the denied application around even after the user is deleted, then you'll need to rework the application process. Don't create a new user when the user applies, but store the requested username as part of the application directly. When the user is approved by the admin, then create the backing DB user.
Yep it would delete their application as well, but that's not too big a problem IMO. I'd really like this process to be pretty hands-off tho, otherwise we're just adding pointless work for admins.
So probably something like:
Delete all users that have been denied > week ago, on startup and in a scheduled daily job.
Delete all users that have been denied > week ago, on startup and in a scheduled daily job
Seems like a good trick to me. At the moment, however, this is an improvement compared to the current state.
Out of curiosity, could you tell me if in your opinion the users who tried to register and who were not approved are included in the total user count of the system?
Yes I agree. However, I was thinking about the fact that, for many instance administrators, the total number of users is a status symbol, a bit like the old Porsche parked in the yard. It no longer has the engine, but it serves to remind the whole neighborhood of how rich we were... 😁 😄 🤣
So a user applies, is denied, and can't reapply with the same username until at least a week later.
And the user in that case is not informed about the issue or timeline.
Still seems to be a problem.
----------------------------------------
Feb 12, 2024 09:30:37 Dessalines ***@***.***>:
And the user in that case is not informed about the issue or timeline. Still seems to be a problem.
This is a different type of problem, which concerns the transparency of immediate feedback to the rejected user. the current problem instead concerns exclusively the public exposure (and counting) of a created nickname.
A specific issue has been presented for your problem, which is still serious but much less urgent
So a user applies, is denied, and can't reapply with the same username until at least a week later
Still seems to be a problem
Nah... If the "cryptospam_nft" user gets bounced and can't re-subscribe for a week, that's not a problem at all.
The userid has particular importance in the fediverse and the problem does not lie in the impossibility of reusing it, but EXCLUSIVELY in the fact that it remains public even after its rejection and that it remains public in the impossibility of deleting it by the user
Activity
dessalines commentedon Feb 8, 2024
Not exactly sure how to go about solving this one. The only thing I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month.
informapirata commentedon Feb 8, 2024
I am convinced that it would be appropriate to implement a function of this type within the system, because it would allow all administrators the possibility of cleaning: In fact, not all administrators are able to intervene on the database tables without causing damage.
Clearly it is not yet completely in line with the "privacy by design" principle, but if it were not possible to create automatic deletion mechanisms, then periodic alerts could be created for administrators or this cleaning procedure could be integrated with each new update of the instance to Lemmy's latest release.
Nothing4You commentedon Feb 8, 2024
FWIW, it should already be possible to have automatic cleanup by querying applications via API and issuing a purge via API, without resorting to DB editing.
[-][Bug]: The user who has not been approved should be automatically deleted from the system (GDPR right to erasure violation)[/-][+][Bug]: The user who has not been approved should be automatically deleted from the system[/+]Security-Chief-Odo commentedon Feb 8, 2024
When the instance admin clicks
denyon the user application. Yeet the user DB entry. Due to the way the relation is setup between the local_user and application tables though, that would delete the application as well. If you want to keep the denied application around even after the user is deleted, then you'll need to rework the application process. Don't create a new user when the user applies, but store the requested username as part of the application directly. When the user is approved by the admin, then create the backing DB user.dessalines commentedon Feb 12, 2024
Yep it would delete their application as well, but that's not too big a problem IMO. I'd really like this process to be pretty hands-off tho, otherwise we're just adding pointless work for admins.
So probably something like:
informapirata commentedon Feb 12, 2024
Seems like a good trick to me. At the moment, however, this is an improvement compared to the current state.
Out of curiosity, could you tell me if in your opinion the users who tried to register and who were not approved are included in the total user count of the system?
dessalines commentedon Feb 12, 2024
I believe they are unfortunately, but total user counts are pretty much useless. Active user counts are far preferred.
informapirata commentedon Feb 12, 2024
Yes I agree. However, I was thinking about the fact that, for many instance administrators, the total number of users is a status symbol, a bit like the old Porsche parked in the yard. It no longer has the engine, but it serves to remind the whole neighborhood of how rich we were... 😁 😄 🤣
Deleting denied local_users older than a week. Fixes #4434
Security-Chief-Odo commentedon Feb 13, 2024
informapirata commentedon Feb 13, 2024
This is a different type of problem, which concerns the transparency of immediate feedback to the rejected user. the current problem instead concerns exclusively the public exposure (and counting) of a created nickname.
A specific issue has been presented for your problem, which is still serious but much less urgent
LemmyNet/lemmy-ui#1096
Nah... If the "cryptospam_nft" user gets bounced and can't re-subscribe for a week, that's not a problem at all.
The userid has particular importance in the fediverse and the problem does not lie in the impossibility of reusing it, but EXCLUSIVELY in the fact that it remains public even after its rejection and that it remains public in the impossibility of deleting it by the user
Deleting denied local_users older than a week. Fixes LemmyNet#4434 (L…