Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When the "Notification User Before Deletion" option is enabled, I expect all users to be notified before being deleted.
However, this is not happening. Users who have already exceeded the configured threshold (e.g., inactivity period)
are being deleted immediately without receiving any prior notification.
This defeats the purpose of the functionality, which is to give users a chance to take action after being notified.
This issue is especially problematic on live/production sites, where users may already exceed the inactivity threshold
at the time the feature is enabled, resulting in their immediate deletion without a chance to respond.
Steps to reproduce
- Enable the "Notification User Before Deletion" setting.
- Set a low threshold for inactivity before deletion.
- Ensure there are users who have already exceeded this threshold when cron runs.
- Run cron.
- Observe that users are deleted without being notified.
Proposed resolution
Add an extra validation step using the purge_users_notifications table.
Check if the user has already been notified and if the notification date has passed the configured waiting period.
Only allow the user to be deleted after this condition is met.
Remaining tasks
- Add the new validation to the purge logic.
- Ensure only users who were notified and have passed the notification wait time are deleted.
- Write automated tests to cover this behavior.
- Update documentation if needed.
User interface changes
No changes to the user interface are required.
API changes
No API changes are required.
Data model changes
No data model changes are needed, assuming the purge_users_notifications table is already used to store notifications.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Capture d’écran 2025-04-26 à 11.49.47.png | 134.36 KB | mably |
Issue fork purge_users-3521201
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
saidatomComment #3
mably commentedI think that it could easily be done using the new policy mechanism.
We could simply create a new "Notification required before purge" policy.
Will see what I can do.
Comment #5
saidatom@mably we have
send_email_user_before_notificationthat is the variable we need, why add one more option?Comment #6
mably commentedHas been implemented as a new condition in the following issue #3427680: Use plugins and condition to create advanced policies.
Comment #7
mably commented@saidatom could you give a try to the new 5.0.0-alpha1 version with the "Notification required" condition and tell me if it solves your problem?
Comment #8
mably commentedComment #9
saidatom@mably for me not working and the module in version 5 has a lot of duplicated configuration. I think we should have policy rules and remove the old form config.
Comment #10
mably commented@saidatom could you describe in detail what is not working exactly?
I do not plan to remove the existing configuration for now.
Seems a bit risky to me and both can be used simultaneously without any problem.
The old config allows to combine connection status rules with OR logic.
On the other hand, the policy conditions use AND logic.
Comment #13
claudiu.cristeaComment #14
claudiu.cristeaI guess we need a test to prove the bug
Comment #15
mably commentedOne edge case to consider with the notification-before-purge mechanism (both checkNotification() in the global config path and NotificationRequiredCondition in the policy path): users without a valid email address.
If the notification email fails to send (invalid or empty email), no record is written to purge_users_notifications. Then neither checkNotification() nor the NotificationRequiredCondition will ever allow those users to be purged. They would be permanently stuck — matching purge criteria but never purgeable.
Possible approaches:
1. Filter out users with empty or invalid emails from the notification candidates entirely and purge them directly — they cannot be notified, so requiring notification is pointless.
2. Insert the notification record regardless of email delivery success (treat "attempted to notify" as sufficient).
3. Log the failure prominently so administrators can manually delete the account. The module already logs a message, but it could be surfaced more visibly (e.g. via a watchdog warning or a status report entry).
Comment #17
mably commented