What this plugin does
User Cleanup removes accounts that nobody uses any more. It checks how long a person has been inactive, sends them a warning e-mail, and deletes the account if they still do not come back within a second grace period. Deletion is a full Moodle account deletion, including the learning history.
Nothing happens until an administrator switches it on. On new installations the scheduled task User cleanup is disabled, and Moodle runs it only while the block is enabled under Site administration → Plugins → Blocks → Manage blocks (it is disabled after installation). An account is deleted only after a warning e-mail was actually sent to it and the grace period has passed.
Who this is for
| Role | What they do here |
|---|---|
| Site administrator (eLeDia) | Configures deadlines and exclusions, schedules the task, watches the task log |
| Learner | Receives the warning e-mail and can prevent the deletion by logging in |
Managers, Trainers and Platform administration have no surface in this plugin.
Core concepts
- Inactivity — in the current release this is derived from the user's last access. A user who has never logged in is measured by their first-access or account-modification date instead.
- Warning phase — the period between the warning mail and the deletion. It is configured separately from the inactivity period.
- Cleanup ledger — an internal list of everyone who has been warned. Logging back in removes the entry, and the account is safe again.
Journeys by role
Site administrator: Configure the cleanup
- Go to Site administration → Plugins → Blocks → User Cleanup.
- Set Day to inform — the number of inactive days after which a user is warned. Default is 120.
- Set Days to delete — the number of days between the warning mail and the deletion. Default is 120.
- Ignore users with course enrolments protects everyone who is enrolled in at least one active course. It is ticked on new installations; untick it only if enrolled users are to be cleaned up as well.
- Optionally tick Send no warning but delete immediately to skip the warning phase. The Days to delete value is then used as the inactivity period.
- Under Exclude roles, select every system-wide role whose holders must never be deleted.
- Save.
Both intervals must be longer than the interval of the scheduled task, otherwise a user can be warned and deleted in the same window.
Site administrator: Switch on and schedule the sweep
- Go to Site administration → Server → Scheduled tasks.
- Find User cleanup and edit it.
- Untick Disabled to switch the cleanup on. The task ships disabled, and the update to 0.2.1 switches it off on existing sites as well and discards all earlier warnings. After re-enabling it, every inactive account is warned anew and deleted at the earliest when the grace period after that warning has passed.
- The shipped default runs weekly on Sunday at 02:00. Change it to daily if the deadlines are short.
- Make sure the block is enabled under Site administration → Plugins → Blocks → Manage blocks. While it is disabled, Moodle skips the task and the scheduled task list shows Plugin disabled.
- To watch a run, use the task log or run the task from the command line. The command line run starts the cleanup immediately, even while the task or the block is disabled:
php admin/cli/scheduled_task.php --execute='\block_eledia_usercleanup\task\cron_task'The log lists how many inactive users were found, whom the plugin mailed, whose warning could not be sent, and whom it deleted.
Site administrator: Add the settings shortcut block
- Open the site front page and turn editing on.
- Add the User Cleanup block.
- The block shows one Configuration User Cleanup link for administrators.
The block on the front page is only a shortcut; the cleanup does not need it. It does need the block to be enabled under Manage blocks.
Learner: Keep an account that was flagged
- Read the warning e-mail — it names the site and the number of days left.
- Log in to the platform before the deadline in the mail.
- The next cleanup run removes the flag automatically. No further action is needed and there is no confirmation mail.
Settings that matter
| Setting | Meaning |
|---|---|
| Day to inform | Inactive days before the warning mail |
| Days to delete | Days between warning mail and deletion |
| Ignore users with course enrolments | Protects everyone with an active enrolment; ticked on new installations |
| Send no warning but delete immediately | Skips the warning phase |
| Exclude roles | Protects holders of the selected system roles |
Site administrators and the guest user are always protected and cannot be configured away.
Limitations
- Deletion is permanent. There is no undo and no restore in this plugin.
- Inactivity is measured by login dates only, not by learning progress. Progress-based inactivity, a dry-run mode and deadlines per organisation are planned, not in the current release.
- With LernHive Certification installed, accounts with a valid certification or an open recertification window are kept, both before the warning and before the deletion. Without that plugin this protection does not apply.
- A maximum of 400 warning mails is sent per run; the rest follow in the next run.
- An account whose warning e-mail cannot be sent is not deleted: mail switched off or diverted for the whole site, a missing, invalid or bouncing address, or a suspended account. The task log names the user ID, and the warning is tried again in every run.
- The plugin has no candidate report. The scheduled-task log is the only place where a run can be reviewed.
Troubleshooting
| Symptom | Check | Resolution |
|---|---|---|
| No user is ever deleted | Are the scheduled task and the block enabled, and were the warnings sent? | Enable User cleanup under Scheduled tasks and the block under Manage blocks; look for "not warning user" or "warning mail … failed" in the task log |
| Users are deleted without a warning mail | Is Send no warning but delete immediately ticked? | Untick it; the warning phase applies again from the next run |
| Warning mails arrive but nobody is deleted | Has Days to delete elapsed since the mail? | The deletion happens in the first run after the deadline, not on the deadline itself |
| Too many accounts qualify | Are Exclude roles and enrolment protection set? | Add the protected roles; consider raising the inactivity period |
| A user complains they lost their account after logging in | Did the login happen before the run that deleted them? | Each run first clears the flags of everyone who came back and only then deletes, so a login before the run is enough. A login after the deleting run cannot help — the account is already gone |
Screenshots
No screenshots yet; there is no capture plan for this plugin.