Skip to content
LLernHive.

User guide

LernHive Export

LernHive Export packages platform data and the audit trail into a verifiable handover archive. The export page downloads a ZIP with one CSV file per section — participants, courses, course and activity completions, the Moodle standard log and the audit trails and records that other LernHive plugins contribute — plus a manifest.json with a SHA-256 hash for every file. The page lists the exact file names the current bundle will contain.

What this plugin does

LernHive Export packages platform data and the audit trail into a verifiable handover archive. The export page downloads a ZIP with one CSV file per section — participants, courses, course and activity completions, the Moodle standard log and the audit trails and records that other LernHive plugins contribute — plus a manifest.json with a SHA-256 hash for every file. The page lists the exact file names the current bundle will contain.

Who this is for

RoleWhat they do
Platform administrationDownloads the CSV bundle from the export page (holds the export capabilities by default)
Site administratorSets the log window and the local export directory, reviews which roles hold the export capabilities

No other role interacts with this plugin in the current release.

Core concepts

Bundle

A ZIP archive with one CSV file per section and a manifest.json. The manual download from the export page always uses the privacy mode include, so the bundle contains personal data.

Section

One named slice of exported data — for example moodle_logs — with its source row count and the timestamp of the newest source row it represents. Section totals roll up into the manifest header. Other LernHive plugins add their own sections, for example the Audience audit log, seminar bookings, cancellations and attendance, or certification periods.

Manifest

A machine-readable JSON document (schema version 2) that accompanies every bundle. It records when it was generated, the privacy mode applied, how many sections, files and source rows the bundle contains, and one entry per produced file.

Integrity evidence

Every file listed in the manifest carries its byte size and a SHA-256 hash. A receiving party can recompute the hashes and confirm that the archive was not altered after export. LernHive also keeps the file evidence of every run, so a delivered archive can be checked against it later.

Journeys by role

Platform administration: download the CSV bundle

  1. Go to Site administration → Plugins → Local plugins → LernHive → LernHive Export.
  2. Under Files in this bundle, check which CSV files the bundle will contain.
  3. Read the notice on the WORM boundary (see below).
  4. Click Download CSV bundle. The bundle is built immediately and downloaded as a ZIP; large sites with a long log window take correspondingly longer.
  5. Hand the bundle over only through a protected channel: it contains personal data.

Platform administration: verify a delivered bundle

  1. Open manifest.json from the ZIP.
  2. Recompute the SHA-256 hash of each CSV file and compare it with the manifest entry. Matching hashes prove the file was not changed after export — no LernHive access is required.

Site administrator: set the log window and the export directory

  1. Go to Site administration → Plugins → Local plugins → LernHive → Export settings.
  2. Set Standard log window (days) — default 365; 0 exports the full history.
  3. Set Local export directory if export jobs should deliver to a directory on the server. It must be an absolute, writable path.

Site administrator: review export permissions

  1. Go to Site administration → Users → Permissions → Define roles and open the Manager role.
  2. Check Manage LernHive export configuration and runs (local/lernhive_export:manage) and View LernHive export runs (local/lernhive_export:viewruns). Both are allowed for the manager archetype at system context, so Moodle's Manager role (Platform administration) holds them by default. Only :manage opens the export page today.

What the export does not guarantee: WORM

The export produces evidence, not the archive. Moodle offers no WORM (write once, read many) guarantee, and this plugin does not create one.

Everything exported is ordinary, changeable Moodle data. Log rows can be removed by log retention settings or by a privacy deletion request. The SHA-256 hash in the manifest proves that a delivered file has not been altered after the export; it cannot prove that the source data was never altered before it.

Where immutable retention is legally required, the storage destination has to provide it — for example WORM-capable object storage (S3 Object Lock in compliance mode), a WORM tape tier, or an archival system with its own audit trail. That is a decision about where you store the archive, not a Moodle setting. The export page repeats this notice above the download button.

Settings that matter

Under Site administration → Plugins → Local plugins → LernHive → Export settings (site administrators only):

SettingDefaultEffect
Standard log window (days)365How far back moodle_logs.csv reaches. 0 exports the full history — expect a much larger archive and a longer download.
Local export directoryemptyAbsolute, writable directory allowed for jobs that deliver to a local file

Export privacy modes

The privacy mode is part of an export job and recorded in the manifest. The download on the export page always uses include; the other modes apply to jobs that are set up technically, because a job editor is not available yet.

  • Include preserves the section data, including personal data.
  • In Pseudonymise and Exclude mode only columns that the owning plugin declared free of personal data leave the platform unchanged. Columns it has not classified are left out; a contributed section without any declaration is not part of the archive in these modes.
  • Pseudonymise replaces declared user identity values with random tokens. A token is consistent only within one export run; a later run uses different tokens. Pseudonymised data remains personal data under GDPR Article 4(5), so handle and share it as personal data rather than as anonymous data. References to one person's records that a plugin declares as such get tokens of their own kind, for example assignment_… for the certification assignment in certify_periods.csv; they never equal a user_… token.
  • Exclude omits sections that consist of personal records (such as participants and completions) and removes declared personal columns. In moodle_logs.csv, it also clears objectid for rows whose objecttable is user, and contextid plus contextinstanceid for rows whose contextlevel is Moodle's user context.
  • Pseudonymise applies the same row-aware rules in moodle_logs.csv: user objectid and contextinstanceid share the same user_… token as the matching userid. contextid receives a usercontext_… token because it is a different Moodle identifier; it never shares its hash with the user_… token of the same number. Since the release of 2026-10-01 the tokens are derived differently, so they differ from those of earlier exports. These columns can contain text tokens alongside numeric values for unrelated rows; consumers must not parse them as integer-only columns.

These rules cover the declared columns only. The unstructured other payload in Moodle log records is not exported, and identifiers embedded in other sections' values are handled only when that section declares them. Treat filtered exports as personal data where they remain linkable.

Limitations

  • No job editor or run overview in the browser. Export jobs, schedules, privacy modes other than include, Audience and organisation-subtree scopes and the local-file destination work in the background, but they cannot be configured in the user interface yet.
  • CSV only. Moodle Backup (.mbz), SCORM, IMS Content Package, H5P and xAPI packages are planned.
  • Destinations: browser download and a local server directory; S3-compatible storage and SFTP are planned.
  • Scopes: whole site, Audience and organisation subtree; full-tenant, category and date-range scopes are planned.
  • No reporting tile for export runs yet.
  • The download runs inside the web request. Very large log windows can hit server time limits; reduce Standard log window (days) if a download fails.

The bundle contains personal data: participants, completions, the standard log and the plugin audit trails record who did what and from which IP address. LernHive stores which person created an export job and ran an export, and keeps the file evidence (names, sizes, hashes) of every run, but not the ZIP itself. Treat a downloaded bundle as a personal-data export — hand it over only through a protected channel and only to a recipient entitled to receive it.

Troubleshooting

LernHive Export is missing from the site administration. → Check that the plugin is installed and that local_lernhive (which it depends on) is installed and up to date. → Complete any pending upgrade under Site administration → Notifications.

A user cannot open the export page. → The page requires local/lernhive_export:manage in the system context. Ask a site administrator to assign that capability.

The download fails or takes very long. → Reduce Standard log window (days); 0 exports the whole log history.

Screenshots

No current screenshots: the existing images show the Moodle plugins overview and an outdated version of this handbook instead of the export page.

Question about this guide?

We are happy to help — free of charge, no obligation.