Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/exelearning/mod_exelearning/llms.txt

Use this file to discover all available pages before exploring further.

mod_exelearning stores minimal personal data — only the attempt history table — and implements the full Moodle Privacy API to support GDPR data exports and erasure requests. Course backups capture the complete activity state including grade-item mappings and (optionally) attempt history, and the File API enforces per-area access control so students can consume content without being able to download the source package.

Privacy (GDPR)

classes/privacy/provider.php implements three interfaces:
InterfacePurpose
core_privacy\local\metadata\providerDeclares what personal data the plugin stores and which subsystems it feeds.
core_privacy\local\request\core_userlist_providerReverse lookup — finds all users who have data in a given context.
core_privacy\local\request\plugin\providerHandles data export and deletion requests.

Personal data stored

The only user-data table is exelearning_attempt (DEC-0007 flat attempt history). get_metadata() declares it field-by-field:
FieldMeaning
useridThe student the attempt belongs to
attempt1-based attempt number per user/activity
itemnumber0 = overall, >0 = a gradable iDevice
rawscoreRaw score
maxscoreMax score
scaledscorerawscore/maxscore in 0..1
statuscompleted / passed / failed / incomplete
timecreated / timemodifiedTimestamps
sessiontoken exists in the table but is not exported — it is a per-page-load correlation token used to group auto-commits into a single attempt, not a user-identifying value.
The privacy metadata also declares a core_grades subsystem link because the plugin pushes each user’s scores into the Moodle gradebook via grade_update() (add_subsystem_link('core_grades', ...), provider.php:63). This ensures privacy tooling accounts for the gradebook data flow.

Deletion

All three deletion entry points delete exelearning_attempt rows and then recalculate the gradebook so an erased user keeps no stale grade with no backing attempt (clear_grades_for_users(), provider.php:81–95).
RequestProvider method
Delete all users in a contextdelete_data_for_all_users_in_context()
Delete one user across contextsdelete_data_for_user()
Delete a set of users in one contextdelete_data_for_users()

Backup coverage

backup/moodle2/backup_exelearning_stepslib.php::define_structure() covers:
ElementBacked up?Conditional
exelearning instance (all settings incl. gradeenabled, grademodel, grademethod, gradepass, gradecat, maxattempt, reviewmode, teachermodevisible)YesAlways
exelearning_grade_item (structural package metadata)YesAlways — not gated by userinfo
exelearning_attemptYesOnly when userinfo is set
intro files (activity description)YesAlways
package files (ELPX source)YesAlways
content files (extracted package)YesAlways
gradesyncrevNoDeliberately omitted — restored copy re-scans on first view
Moodle grade_item rowsNoRe-created by grade_sync::sync() on first view
gradesyncrev is intentionally excluded from the backup. Leaving it out forces the restored copy to re-scan its package once on first view, rebuilding the gradebook columns from the actual package contents rather than trusting a potentially stale sync marker.

Restore specifics

1

User id remapping

usermodified is remapped to a valid local user or falls back to 0; attempt.userid is remapped via the user mapping table.
2

gradecat cross-course reset

gradecat is a course-specific grade_categories.id (DEC-0034). It survives a same-course duplicate but not a cross-course restore. The restore step keeps it only if the category exists in the destination course; otherwise it resets to 0 (the course top category). Per-iDevice items are re-parented on first view by exelearning_apply_grade_category()grade_item_manager::apply_category() (B4, DEC-0044).
3

Moodle grade items re-created, not restored

The plugin’s own exelearning_grade_item rows are restored, but the actual Moodle gradebook grade_item columns are not restored directly. They are re-created on first view when grade_sync::sync() runs, paired with the deliberately omitted gradesyncrev.
4

File re-attachment

Related files (intro, package, content) are re-attached after the tables are restored in after_execute().
The round-trip backup/restore test lives at tests/backup_restore_test.php (@covers \backup_exelearning_activity_task).

File API areas

The plugin uses three file areas:
Areaitemid schemeWho can fetchNotes
contentcontent/{revision}Any viewer with mod/exelearning:viewExtracted site; SVG served inline; revision-based cache busting.
packagepackage/0 (itemid = revision)Teachers only (moodle/course:manageactivities)Raw ELPX source — students cannot download it.
introcore-managedAny viewerActivity description, handled by core.

Pluginfile access control

exelearning_pluginfile() in lib.php:494 enforces access in layers:
1

Context check

Require CONTEXT_MODULE; refuse otherwise.
2

Course login

require_course_login($course, true, $cm).
3

View capability

require_capability('mod/exelearning:view', $context) — applies to all areas.
4

Package area gate (teachers only)

content files are served to any viewer. The package area additionally requires require_capability('moodle/course:manageactivities', $context) — students can render the extracted activity but are blocked from downloading the authoring source.
SVG files in the content area are served inline ($options['dontforcesvgdownload'] = true) so eXeLearning v4 icons render correctly rather than triggering a download — the same flag used by mod_scorm. Revision-based cache busting is automatic: the content URL embeds {revision}; bumping revision on save invalidates old URLs, making a long cache lifetime safe.

Build docs developers (and LLMs) love