Online User Manual & Help Guide

Purpose

Install or upgrade Learner Records Hub, the optional Learner Profile activity and the optional website connector safely.

Current package set

Recommended upgrade steps

1. Back up Moodle code, Moodle database and moodledata.
2. Replace local/learnerhub with the new package.
3. Replace companion plugins only where used.
4. Run Moodle upgrade and purge caches.
5. Validate the licence and run System Health.
6. Open Dashboards, Learners, Applications, Payments, Integrations, Compliance and Demo Data Manager for a quick smoke test.

Purpose

The Dashboard Hub gives users one place to open focused dashboards for operational, analytics, Moodle learning, applications, finance, compliance, integration and results review.

Dashboard	Use it for	Screen view
Operational Dashboard	Daily action queues, messages, payment balance, catalogue publishing and system actions.	View screen
Analytics Dashboard	Learner growth, programme registrations, intake distribution and compliance readiness trends.	View screen
Moodle Learning Dashboard	Mapped Moodle courses, enrolments, completion, activity completion and grade evidence.	View screen
Applications Dashboard	Application pipeline, document readiness, payment readiness and conversion workload.	View screen
Finance Dashboard	Deposits, balances, pending payments, failed payments, unlinked payments and refunds.	View screen
Compliance Dashboard	Compliance profile readiness and regulatory preparation views.	View screen
Integration Dashboard	Connector health, catalogue publishing, API events and sync exceptions.	View screen
Results & SoR Dashboard	Formal results, evidence gaps, verification and Statement of Results readiness.	View screen

Purpose

The Moodle Learning Dashboard shows whether Moodle learning activity is available to LRH as supporting evidence. It is intentionally scoped to mapped Moodle courses to avoid heavy site-wide reporting queries.

What it shows

• Mapped Moodle courses and visible mapped courses.
• Active learners in mapped courses.
• Course completion evidence.
• Activity completion evidence.
• Grade evidence records.
• Evidence gaps that may need review before formal result approval.

How to interpret it

Moodle remains the learning platform and evidence source. LRH remains the formal control point for result approval, verification and Statement of Results readiness.

Purpose

The learner record is the central person record used across registrations, applications, documents, compliance values, Moodle evidence and reports.

Current profile tabs

• Overview and personal details.
• Registrations and programme history.
• Learning Evidence, including Moodle completion and activity completion evidence.
• Results, used for formal result review.
• SoR, used for Statement of Results readiness and release review where applicable.
• Documents and audit-linked evidence.

Developer request examples

The plugin Help Centre contains the full endpoint-by-endpoint examples with JSON bodies and cURL commands. The examples below show the expected pattern for external systems. Use placeholder tokens only in documentation; never publish live connector tokens or HMAC secrets.

Good practice

Use controlled lookup values for compliance-sensitive fields and avoid duplicating learner address, citizenship or demographic fields across disconnected records.

Purpose

Programmes define the learning or qualification offering. Intakes define the delivery cohort. Moodle course mappings connect programme records to learning evidence.

Recent updates

• Programmes can be assigned one or more formal compliance profiles.
• A programme with no compliance profile is treated as not applicable for formal compliance readiness checks.
• Catalogue publishing controls allow selected programmes/intakes to be made available to approved website connectors.
• WooCommerce product creation supports controlled application-first or payment-after-approval journeys.

Purpose

Applications are applicant-facing workflow records captured from the website or managed internally before becoming learner registrations.

Core workflow

1. Applicant submits profile, programme/intake selection and required applicant-owned fields.
2. Documents and payments are reviewed where required.
3. Reviewer uses the Application Decision Centre to check readiness.
4. Accepted and ready applications are converted into learner and registration records.

Controls

Duplicate application rules, document review, payment status and compliance capture protect the journey before conversion.

Purpose

Payment dashboards and payment records help finance users review deposits, full payments, balances, pending payments, failed payments and refund-review items.

Important model

WooCommerce or the configured payment provider remains the payment authority. LRH records the payment status, linked application/learner context and review indicators.

Purpose

Documents and compliance values support onboarding, application review, regulatory preparation and evidence organisation.

Current model

• Document types can be configured and reviewed with status workflows.
• Application documents can be promoted to learner-level documents on conversion.
• Compliance profiles determine which formal readiness checks apply to a programme.
• Compliance values can prefill from learner, Moodle, application and programme/intake context without overwriting manually confirmed values.
• Lookup CSV import supports generic lookup sets and StatsSA/QCTO area data.

Purpose

QCTO tools support providers that need structured QCTO course mapping, compliance pack preparation and Statement of Results evidence review.

Key screens

• QCTO course mapping.
• QCTO course template/scaffold support.
• SoR evidence overview.
• Results and SoR dashboard.
• Export packs and readiness checks.

Purpose

The Enterprise integration layer connects LRH with approved WordPress/WooCommerce sites for public programme catalogue, applications, payments, student portal workflows and approved external API integrations.

Security model

• Production connector URLs should use HTTPS.
• Connector tokens are scoped and signed.
• Secrets are not shown in dashboards.
• Documents are not stored in WordPress; LRH remains the protected document/control point.
• No password bridge is used between WordPress and Moodle.
• SSO readiness is based on shared identity provider planning and account mapping.

Recommended screen views

Recommended views include connector settings, security status, catalogue sync, programme product page, application form, checkout and student portal screens.

Purpose

The Integration API guide is for approved Enterprise customers who need to connect systems other than the supplied WordPress/WooCommerce connector, such as a CRM, custom application portal, internal website or finance platform.

Connection rules

• Create a dedicated connector key for each external system.
• Enable only the scopes that system needs.
• Use HTTPS/TLS for production connectors.
• Send the connector token as an Authorization: Bearer header.
• Sign write operations with HMAC-SHA256 using timestamp, nonce and signature headers.
• Do not expose Moodle user IDs, LRH learner IDs, ID/passport numbers, documents, connector tokens or restricted compliance files externally.

Common endpoints

Example request headers

Authorization: Bearer YOUR_CONNECTOR_TOKEN
X-LRH-Timestamp: 2026-06-25T13:20:00Z
X-LRH-Nonce: 7d2a8f3c-unique-per-request
X-LRH-Signature: base64(hmac_sha256(secret, method + '
' + path + '
' + timestamp + '
' + nonce + '
' + body_sha256))

Example: read published catalogue

curl -X GET 'https://moodle.example.edu/local/learnerhub/api/catalogue.php'   -H 'Authorization: Bearer YOUR_CONNECTOR_TOKEN'   -H 'Accept: application/json'

Example JSON: application submission body

{
  "external_reference": "APP-2026-000123",
  "programme_code": "BUS-ADMIN-NQF4",
  "intake_code": "2026-JUL",
  "applicant": {
    "first_name": "Amina",
    "last_name": "Nkosi",
    "email": "amina@example.com",
    "mobile": "+27 82 000 0000"
  },
  "consent": {
    "privacy_notice_accepted": true,
    "accepted_at": "2026-06-25T13:20:00Z"
  }
}

Purpose

The student portal gives applicants and learners a controlled front-end view of applications, documents, messages, payments, programmes, course access and profile information.

Current portal areas

• Dashboard and full-browser shell.
• Applications and journey/status view.
• Documents.
• Messages.
• Fees and payments.
• Programmes and courses.
• Profile updates using LRH-aligned lookup fields.

Purpose

LRH supports validation-first imports, controlled exports, duplicate learner review and data quality workflows.

Key areas

• Bulk Import Centre and import logs.
• Lookup CSV import, including StatsSA area imports.
• Data Quality Centre and issue review.
• Duplicate learner detection.
• Export Centre builder, learner export and organisation export routing.

Purpose

Messaging and support features give administrators structured ways to manage templates, notification rules, support requests and support sessions.

Key areas

• Message Template Centre.
• Notification rules and send queue.
• Support Desk.
• Support Session and gated release diagnostics.
• System Health and operational error centre.

Purpose

The Demo Data Manager creates representative sample records for training, demonstrations and walkthroughs.

Current alignment

Sample data is aligned with learners, organisations, programmes, intakes, registrations, programme compliance profile assignments, catalogue publishing, applications, documents, payments, integration events, templates, notification rules, dashboards and QCTO-related test records.

Safety model

• Demo records use explicit markers such as LRH-DEMO-*, lrhdemo_*, [Demo] and [LRH_DEMO_DATA].
• Demo removal targets only marked demo data.
• Demo data does not create Moodle courses or change real Moodle course content.

GPL alignment

Where Learner Records Hub is distributed as a Moodle plugin, the plugin code that interfaces with Moodle core is provided in line with Moodle GNU GPL licensing expectations.

Package entitlements

The commercial package covers Switch Cloud Studio product features, updates, configuration support and service access. It does not sell or restrict Moodle core software.