sharix-open-moodle

ShariX Moodle Integration

Optional Django module for integrating ShariX Open / ShariX Platform with Moodle through Moodle REST web services. The recommended mode uses the Moodle plugin local_sharix; standard Moodle REST remains as a compatibility fallback.

What the module does

1. Adds a Metaservice-admin page for mapping a local Django/LDAP group to a Moodle course.
2. Synchronises users from the local group to Moodle:
   • enhanced mode calls local_sharix_sync_cohort_access and reconciles a plugin-owned cohort plus a standard Moodle cohort-enrolment instance;
   • compatibility mode preserves the historical cohort_members / manual_enrol standard-REST workflow.
3. Adds a Moodle-specific resource_type in memory and stores Moodle course metadata for dbsynce.Resource in the optional module model MoodleCourseResource.

Integration modes

Enhanced mode (recommended)

Install local_sharix in Moodle and use a token issued for its ShariX Integration API service. The module performs local_sharix_get_info handshake and, for supported API v1, uses Moodle-side client policy and scope for:

• curated existing courses;
• actor-owned existing courses checked with Moodle capabilities;
• idempotent provider course creation;
• Stage 4 managed cohort access through local_sharix_sync_cohort_access;
• Stage 4 controlled individual access through local_sharix_ensure_user_enrolment;
• Stage 5 normalized enrolment/completion/grade facts through local_sharix_get_course_user_state.

In enhanced mode ShariX no longer creates Moodle cohorts or cohort-enrolment instances through core REST functions. local_sharix owns those remote objects. Starting with Stage 5, checks also stop collecting completion and grades through several raw core calls: the plugin returns one normalized course-user state and ShariX applies its own CheckDefinition policy.

Compatibility mode

If Moodle clearly reports that local_sharix_get_info does not exist, ShariX keeps the legacy standard-REST provider-course path. Role IDs/shortnames and MOODLE_ALLOWED_COURSE_IDS are compatibility-only policy in this mode. Authentication/authorization errors, disabled clients, or unsupported plugin API versions do not silently fall back.

Compatibility tokens still need the legacy standard REST functions used by the enabled workflows, including user/course lookup, enrolment, completion and grade-report functions. Compatibility group sync remains available. Enhanced mode uses the local_sharix managed-access and normalized-state endpoints instead.

.env variables

MOODLE_BASE_URL=https://study.example.org
MOODLE_TOKEN=
MOODLE_REST_ENDPOINT=/webservice/rest/server.php
MOODLE_TIMEOUT=20
MOODLE_VERIFY_SSL=True

MOODLE_LOCAL_USER_FIELD=phone_number
MOODLE_USER_SEARCH_FIELD=username
MOODLE_INCLUDE_FRONTPAGE=False
MOODLE_DEFAULT_STUDENT_ROLE_ID=5

MOODLE_SYNC_MODE=cohort_members
MOODLE_REMOVE_STALE_MEMBERS=True
MOODLE_COHORT_IDNUMBER_PREFIX=sharix
MOODLE_TRY_CREATE_COHORT_ENROLMENT=False
MOODLE_COHORT_ENROLMENT_FUNCTION=local_ws_enrolcohort_add_instance

MOODLE_RESOURCE_TYPE_CODE=20000
MOODLE_RESOURCE_TYPE_NAME=moodle course
MOODLE_COURSE_URL_TEMPLATE={base_url}/course/view.php?id={course_id}
MOODLE_ALLOWED_COURSE_IDS=
MOODLE_RESOURCE_TEACHING_ROLE_IDS=3,4
MOODLE_RESOURCE_TEACHING_ROLE_SHORTNAMES=editingteacher,teacher
MOODLE_RESOURCE_COURSE_CACHE_SECONDS=60

In enhanced mode MOODLE_ALLOWED_COURSE_IDS, teaching-role settings, MOODLE_COHORT_IDNUMBER_PREFIX, MOODLE_TRY_CREATE_COHORT_ENROLMENT and MOODLE_COHORT_ENROLMENT_FUNCTION are compatibility-only. Moodle-side local_sharix scope and ownership are authoritative. MOODLE_REMOVE_STALE_MEMBERS still controls whether enhanced reconciliation removes users that are no longer in the local group, but such removal is limited to the exact local_sharix-owned cohort.

Platform connection points

Add sharix_moodle to INSTALLED_APPS_LOCAL.

In core/urls.py add:

path('my/moodle/', include('sharix_moodle.urls')),

The exact prefix should match your current ShariX admin prefix. If your project uses sv.SHARIX_ADMIN_PATH, use that instead of hardcoding my/.

In sharix_admin/context_processors.py, inside if is_metaservice_admin: add:

if sv.is_local_app_enabled("sharix_moodle"):
    from sharix_moodle.menu import append_platform_menu_item
    append_platform_menu_item(items, _add_menu_item)

In sharix_admin/lib/access_matrix.py, add:

"moodle_course_groups": {"METASERVICE-ADMIN"},

Service / Open connection points

For the newer menu implementation in ShariX Open, add to sharix_admin/lib/menu.py optional modules block:

if sv.is_local_app_enabled("sharix_moodle"):
    _append_once(STAFF_METASERVICE_MENU_GLOBAL, 'moodle_course_groups')
    _append_once(STAFF_METASERVICE_MENU_CUSTOMIZABLE, 'moodle_course_groups')

    MENU_SCHEME_LIST_OPEN['moodle_course_groups'] = [
        'sharix_moodle',
        'education',
        'Moodle: курсы',
    ]

And add to sharix_admin/lib/access_matrix.py:

"moodle_course_groups": {"roles": ("METASERVICE-ADMIN",)},

Resource course integration for service

The domain-facing adapter exposes three enhanced resource paths when allowed by the Moodle client policy:

1. an allowed curated existing course;
2. an existing course managed by the current actor;
3. creation of a new Moodle course.

MoodleResourceFormMixin provides the generic fields. A caller that saves a generic resource passes the validated source and creation fields to save_moodle_resource_metadata(). The service-constructor integration uses the same public facade and uses its training-course title/description when creating a new Moodle course.

Remote course creation is idempotent. The form carries a stable opaque creation-request UUID across validation/retry and passes it to Moodle as the idempotency key. A retry of the same submitted form therefore recovers the same Moodle course even if the local DB transaction rolled back after the remote create.

Existing MoodleCourseResource bindings remain editable without forcing a destructive rebind when Moodle is temporarily unavailable or the current scope later changes. New/changed bindings are always revalidated server-side.

Managed group access and manual sync

MoodleCourseGroupBinding keeps the ShariX-side business mapping local group → Moodle course. Stage 4 adds a stable UUID to every binding. Enhanced mode sends group:<uuid> as the opaque ownership key to Moodle.

The cached cohort_id / cohort_idnumber fields in ShariX are diagnostic only. The source of truth for Moodle ownership is local_sharix_access_binding. A first enhanced sync creates the owned cohort and cohort-enrolment instance automatically; no manual Moodle enrolment-method setup and no local_ws_enrolcohort_add_instance call are required.

Stale-member removal never unenrols a user globally and never edits LDAP cohorts, administrator cohorts, manual access or another client's cohort.

Run all active bindings or one binding:

python manage.py sync_moodle_courses
python manage.py sync_moodle_courses --id 1

The command reports integration mode, stable external key, access-binding/cohort/enrolment-instance ids, requested/resolved users, additions/removals and missing Moodle usernames.

Shared requirement checks

The optional module may bind one shared dbsynce.CheckDefinition to a Moodle course through MoodleCheckBinding. The binding stores the check's stable public_id rather than a cross-module foreign key.

Supported modes:

• ENROLL_AND_VERIFY — enrol the user when necessary and then wait for Moodle completion/grade data;
• VERIFY_ONLY — never grant course access, only inspect existing completion/grade data.

The shared RequirementCheck remains the source of truth for the verification result. Stage 5 reads one normalized Moodle state containing user/enrolment, completion and grade facts. ShariX still decides whether completion is required, which minimum percentage applies and whether the shared check PASSES or FAILS.

For ENROLL_AND_VERIFY, the adapter first reads state. When access is missing it calls ensure_user_enrolment with the stable key check:<RequirementCheck.public_id> and leaves the check PENDING. A later refresh reads completion/grade facts. Existing LDAP/cohort/manual/other access is reused and is not duplicated.

For VERIFY_ONLY, ShariX never grants access. It only evaluates the normalized state already present in Moodle.

Non-decisive Moodle evidence is persisted on the same PENDING RequirementCheck (result_data and score fields) so DB-only onboarding/presentation code can show the latest known state without contacting Moodle. Decisive results continue through the shared apply_requirement_check_result() path. No parallel training-status model is introduced.

Moodle completion is integration evidence, not an artificial document. Existing certificate/document/manual evidence mechanisms remain unchanged and independent.

Stage 17 employment onboarding and local acts

Employment training is configured through the shared requirements model. The Moodle module is only the delivery/verification adapter:

1. create or reuse an ordinary dbsynce.CheckDefinition;
2. configure it for automatic verification with automation_provider_code=moodle, confirmation_algorithm=delivery_provider_result, and online delivery;
3. create/sync the corresponding MoodleCourseResource;
4. bind the definition to the resource on Moodle: checks;
5. reference that same check code from the existing Relationship/position requirements policy.

For pre-employment onboarding use ENROLL_AND_VERIFY. The concrete RequirementCheck authorizes course enrolment, so a candidate can start and complete required training before the employee LDAP group is granted. Course completion/grade is written back to the same RequirementCheck; the existing Relationship requirements evaluator then sees the new result. There is no parallel HR training status table.

Course IDs are deployment data and must not be hard-coded in Python or in a universal employment-course list. The actual list of local acts/training is also deployment-specific. Typical categories in the approved HR source set may include internal labour rules, employee personal-data policy, commercial secret rules, information-security rules, occupational-safety training and position-specific job instructions, but administrators decide which concrete CheckDefinition/Moodle resource applies to each position.

Organization local-act content belongs in the approved Moodle/content lifecycle according to its ownership, privacy and licence policy. Signed or personal employee copies must not be committed to source Git.

The binding page does not contact Moodle while rendering the employment onboarding projection. The candidate explicitly starts/refreshes a check; normal Relationship requirement evaluation remains DB-only.