Tabula Rasa – Automatic User Lifecycle Management for Moodle

Niels Gandraß

mail Niels.Gandrass@haw-hamburg.de
globe https://gandrass.de

Moodle.NRW Community Conference 2026

Ruhr University Bochum

2026-11-12

Motivation

Why and when do we even want to get rid of users and other content?

gavel Legal construction Technical apartment Organizational

Legal requirements

Let's get through the boring stuff first ...

delete_sweep

contract Art. 5 GDPR

We need to remove old user records and other personally
identifiable information (PII) from our systems without undue delay

webhook

contract Art. 19 GDPR

Students deleted from the university IDM must be deleted
from Moodle without undue delay

archive

contract Art. 17 GDPR

Students can't simply request the deletion of exam data or grades. Deletion can't be a simple self-service process.

Technical & Organizational aspects

home_storage Your moodledata/ folder is only getting bigger

chevron_right All uploaded files and submissions are kept for active users

database Your Moodle database grew to a decent size while containing mostly unused data

more_time Certain tasks or database queries take ages to complete

chevron_right Some housekeeping tasks still scale largely with the amount of total user data

database_search Having less data to sift through leaves more time for the interesting tasks

person_search Avoiding name collisions when searching for users

chevron_right Enrolling the correct "John Smith" out of 30 ones can be error-prone

layers_clear Phasing out old content (e.g., question types or activities)

chevron_right Some plugins can only be uninstalled once all usages / instances are deleted

User vs. Course Lifecycle

How user lifecycles differ from course lifecycles

And can't we just have one plugin?!

Same idea – different subject

Both, tool_lifecycle and tool_userautodelete, are powerful workflow engines
with pluggable building blocks ... they just look after different things!

Course Lifecycle
tool_lifecycle

Manages your courses
Courses are selected initially by filters
Can have interactive steps
Backup, hide, notify, delete, ...

User Lifecycle
tool_userautodelete

Manages your user accounts
Users can be filtered at any stage
Runs fully automated
Notify, suspend, delete, anonymize, ...

Better together

Why having one generalist if you can have two specialists?

Each plugin does one job, and does it well!

Course Lifecycle
tool_lifecycle

add

User Lifecycle
tool_userautodelete

equal

- Tabula Rasa -
A Clean Moodle

Our Current
User Lifecycle(s)

How users get on and off our Moodle platforms

Different platforms, different user lifecycles

We run a number of Moodle platforms with diverging user management

University Moodles

Used solely by our students
Primary auth method is SSO
One account per university member
Semester-based user creation

Public Moodle

Open to the public
Local accounts and multiple SSOs
Anonymous temporary accounts
Constant user fluctuation

University Moodle

The simple and straightforward case

Public Moodle

The "slightly" more complicated case ...

Key takeaways

tactic It's only simple until it isn't

schema User lifecycles can be multi-staged

groups Different user groups may require different lifecycles

file_export External systems / events can dictate the flow

all_inclusive There is no simple "one size fits all" solution

Moodle Plugin:
User Lifecycle Management

The Automatic User Deletion plugin grew into a fully-fledged workflow management engine.

Key features

auto_transmission Automatically manages users based on flexible workflows

filter_alt Extensive criteria for selection / filtering users

settings_account_box Various actions to perform on user accounts

security GDPR-compliant deletion of user data

science Dry-run mode for verifying the configuration

monitoring Action log to audit performed actions

construction Highly configurable (time thresholds, auth method, ...)

dynamic_form Dynamic variables (e.g., user names) in email templates

Moodle Plugin:
Automatic User Lifecycle Management
(tool_userautodelete)

Filters and actions

User filters and actions are lightweight and flexible sub-plugins

Filters	Actions
web_traffic Last access passkey Auth method id_card (Custom) Profile field approval_delegation Role school Enrolments groups Cohort account_circle_off Suspension check_circle Confirmation date_range Date range timer Time delay	id_card Set (Custom) profile field account_circle_off Suspend account_circle Unsuspend groups Add / Remove cohort mail Send mail license Remove badges delete Delete security Anonymize

Example workflow

Example workflow (edit mode)

Dry-run

Action logs

All actions performed by the plugin are logged in a cumulative fashion.

Specific workflows, steps, and actions can be identified, filtered for, and sorted by.

GDPR-compliant user deletion

Removing the remaining personally identifiable information (PII) after Moodle "deleted" a user

deleted	0
username	johndoe
password	<Password Hash>
email	jd@foo.com
firstname	John
lastname	Doe
institution	Awesome Uni
idnumber	123456789
description	My secret is 1234
phone1	+00 123456789
address	North Pole 1
lastip	10.0.0.42
picture

Moodle user table for active user

arrow_right_alt
Delete
user

deleted	1
username	jd@foo.com.1772113756
password	<Password Hash>
email	<MD5 Hash>
firstname	John
lastname	Doe
institution	Awesome Uni
idnumber	empty
description	My secret is 1234
phone1	+00 123456789
address	North Pole 1
lastip	10.0.0.42
picture	broken_image

Moodle user table for deleted user

arrow_right_alt
Remove
PII

deleted	1
username	DELETED-USER-1
password	empty
email	DELETED-USER-1@localhost
firstname	DELETED
lastname	DELETED
institution	empty
idnumber	empty
description	empty
phone1	empty
address	empty
lastip	empty
picture	broken_image

Moodle user table after PII removal

Modeling
Institution-specific Use-cases

Leveraging the workflow engine to support your institution's lifecycles

Using filters, actions, and multiple workflows

You got various user groups that require different lifecycles? We got you covered!

mitre Having multiple workflows allows targeting different user groups independently

rebase_edit Steps, filters, and actions can be combined freely

format_list_numbered Workflows are ordered and follow a deterministic execution model

looks_one A user will only ever be in a single workflow at a given point in time

pause_circle Workflows can either be disabled individually or paused globally

vacuum Timeout / user retention can be configured on a per-workflow basis

Creating custom filters and user actions

All filters and user actions are small yet flexible sub-plugins and
can therefore easily be extended according to your specific needs

https://moodleuserlifecycle.gandrass.de/dev

You can find detailed instructions on implementing your own sub-plugins
within the developer documentation!

Contributing

You created something that could help others? Wonderful!

bug_report

Open an issue

Found a bug or have an idea? Let us know!

merge

Submit a pull request

Fixes, features, and docs are always welcome

extension

Share your sub-plugins

Your custom filters and actions can help others

ngandrass/moodle-tool_userautodelete

Quickstart and Resources

I got you hooked and you would like to start exploring the plugin? Nice!

Quickstart

You can find a quick guide on how to install the plugin and
get started with your first workflow in the comprehensive online documentation

https://moodleuserlifecycle.gandrass.de/

Getting the plugin

The user lifecycle management plugin is available on GitHub
and via the Moodle Marketplace!

https://marketplace.moodle.com/plugins/tool_userautodelete

https://github.com/ngandrass/moodle-tool_userautodelete

Q&A Session

Now it's time for your questions!

You can find all slides of this talk at
globe https://gandrass.de