Propose new features
Designing Decidim together
Is your feature request related to a problem? Please describe.
Lille European Metropolis, our client, has observed the need to delete/block/suspend inactive accounts after a certain period of inactivity. Other clients have also expressed similar needs. This need is based on a few motivating factors listed below:
- as an extra step in GDPR compliance;
- opportunity to regain users by warning them that if they will not their account will be deleted/blocked/suspended;
- security concerns - keeping less personal data also means limiting the negative impact of a potential data leak.
Describe the solution you'd like
- As an administrator I want to choose whether users are deleted/blocked/suspended after a period of inactivity or not.
- As an administrator I want to define time criteria for the period of inactivity leading to deletion (as well as the timing of the warning email) so that I don’t have to delete/block/suspend inactive users manually.
- As an administrator I want to configure the email warning users that their account will be deleted/blocked/suspended if they do not log in so that some of them return to the platform.
Suggested implementation
A checkbox in the administrator panel allowing administrators to choose whether users are deleted/blocked/suspended automatically after a period of inactivity and if so chosen to enter the period of inactivity after which users are to be considered inactive.
&
A newsletter template automatically existing in the newsletter tab of the administrator panel allowing to configure the warning email.
Measuring the performance of this change:
- complaints received of users unsatisfied with the automatic deletion of their account as a percentage of the total number of inactive accounts deleted;
- warning email opening rate and conversion (the user logs into the platform again);
Describe alternatives you've considered
The main discussion on alternatives has been whether to block, delete or in other ways "suspend" the inactive user if the administrator chooses to automatically do so.
Would like to open this discussion to your opinions ;)
Additional context
-
Does this issue could impact on users private data?
This feature could have a positive impact on users' private data.
Funded by
Open Source Politics and our clients
Report inappropriate content
Is this content inappropriate?
Comment details
You are seeing a single comment
View all comments
Conversation with Pauline Bessoles
I totally agree! Actually I don't understand why we keep the authorization data for deleted users, do you have any idea?
@Pops The reason why we store the authorization data for deleted users is that there may be situations where users are trying to exploit the system by deleting their account over and over again, such as trying to cast multiple votes. I was actually really glad to see this feature when I found Decidim in the first place, it was well thought out.
Preserving the authorization data at least until the end of the voting ensures that participants cannot cast multiple votes even if they try to do that (or other use cases where you need to prevent double entry). There may be also some legal reasons why that data might need to be stored after the voting, such as being able to verify the validity of the voting result.
For the original concern by @Ariadna_VA, the next version will include a feature for automatic conflict resolutions through the GDPR improvements:
https://github.com/decidim/decidim/issues/9179
This will handle the situation described above automatically that the user first deleted their account and then re-registered with the same verification details. In that situation, the previous verification is automatically transferred over to the new user account along with all the data bound to that particular verification.
There are still other edge cases that need to be manually handled through the conflicts resolution but this should at least take care of the most common case when this kind of a conflict would happen.
would it be possible to keep a hash of the metadata in order not to keep confidential data?
@Armand-OSP There are actual cases (such as the described one) where the actual metadata needs to be preserved even when the account is deleted.
The authorization itself already stores a "hash of the metadata" (i.e. the "unique ID" of the authorization). The admin decides when the metadata is cleared, i.e. when to revoke the authorization (through the admin panel).
Maybe as an extra feature, there could be automatic revocation for authorizations that have expired N months ago (configurable)? Similar feature already exists for deleting meeting registration form answers for past meetings (meeting ended more than N months ago).
Loading comments ...