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
I'd expect to be able to have archives deleted automatically when they reach a certain age to comply with deletion deadlines for data protection reasons.
Current Behavior
max_month exists as a configuration option for archives but that only limits the number of archive months and only deletes old months when new mails are processed for the list. So for lists that receive mail every day this works as I would like, but for lists with gaps in usage this means archives can be arbitrarily old.
Possible Solution
Changing max_month to act like this would probably interfere with some user's expectations, so adding a new configuration like max_age would be preferred. The new functionality would need a task running regularly (at least monthly, possible daily) that checks the archives of all lists with the new configuration to purge the archives. Depending on the number of affected archives (and mails therein) this could lead to a lot of I/O-load, max_month automatically balances the I/O-load by only acting when mail for a specific list is being processed and thus spreads the archive deletions around.
Context
As a constructed example: HR using a list to communicate with specific departments about recruitment processes. The personal data of rejected candidates must be deleted after a specific time-frame (under GDPR when it's not needed anymore, meaning something like when deadlines for lawsuits have elapsed in this case). But if a specific department only has recruitment processes every couple of years and thus no mail is sent to the list, the data in the archives remains for too long.
The text was updated successfully, but these errors were encountered:
One workaround: The archives in the past months may be removed safely without stopping Sympa, so you can set up a periodical job (cron job, timer unit etc.) to remove them.
One workaround: The archives in the past months may be removed safely without stopping Sympa, so you can set up a periodical job (cron job, timer unit etc.) to remove them.
Good to know, thank you; but I'd probably prefer a solution inside of Sympa if possible. Would you accept a PR with this feature if I manage to find the time to implement this?
Expected Behavior
I'd expect to be able to have archives deleted automatically when they reach a certain age to comply with deletion deadlines for data protection reasons.
Current Behavior
max_month
exists as a configuration option for archives but that only limits the number of archive months and only deletes old months when new mails are processed for the list. So for lists that receive mail every day this works as I would like, but for lists with gaps in usage this means archives can be arbitrarily old.Possible Solution
Changing
max_month
to act like this would probably interfere with some user's expectations, so adding a new configuration likemax_age
would be preferred. The new functionality would need a task running regularly (at least monthly, possible daily) that checks the archives of all lists with the new configuration to purge the archives. Depending on the number of affected archives (and mails therein) this could lead to a lot of I/O-load,max_month
automatically balances the I/O-load by only acting when mail for a specific list is being processed and thus spreads the archive deletions around.Context
As a constructed example: HR using a list to communicate with specific departments about recruitment processes. The personal data of rejected candidates must be deleted after a specific time-frame (under GDPR when it's not needed anymore, meaning something like when deadlines for lawsuits have elapsed in this case). But if a specific department only has recruitment processes every couple of years and thus no mail is sent to the list, the data in the archives remains for too long.
The text was updated successfully, but these errors were encountered: