Deployment · Sync to LMS · Client choice
This note walks through the Deployment tab, Linh’s Save → Deploy rules, the LMS org hierarchy, and fork (Set Up for New Trimester), then the open question: what does the UI Module code field mean for roster sync? We recommend Option B (treat the field as a Course Offering code; drop the same-code lock after fork) because it matches LMS roster behaviour and the current Course Builder implementation. If Option B is not accepted, Product still needs clear rules for Option A.
Open Figma — Deployment tab (node 2765-39512)Example module: Software Engineering Principles (ICT 2101), Undeployed v1.0, enrolment type Sync to LMS Module. The tab has three blocks: Enrolment Configuration → Deploy → Set Up for New Trimester (fork; see §4).
End-to-end rules for the flow in §1 (from a related Figma comment). Summary first; expand for the verbatim note.
Open question: what “Module Code” and “instance” mean here, versus fork keeping the same code — see §5.
Configuration: - The editor selects the Enrolment Type (Sync to LMS or SIT). - Input Module Code, select MC/Module Group, and select Trimester. If Enrolment Type is Sync to LMS, then MC is optional. If Enrolment Type is SIT/Public, then Module Group is required (this is a new added rule to make it easier for Admin to organise SIT/Public modules, because these are not verified against the LMS). - Click [Save]: If Enrolment Type is Sync to LMS, the system performs two checks: (1) The system verifies the Module Code (or if that fails, then the MC Code) against the LMS. If successful, it displays reference info (Module Name, Cluster, Programme). (2) The system checks internally if another module already exists inside the platform. If yes, display an error message "A module with this Module Code already exists." - If Enrolment Type is SIT/Public, the system only checks for duplicate module code (no need to verify against LMS). Deployment (Sync to LMS): - Can only be initiated 2 weeks before the trimester starts. 2-Step Sync Logic: - Priority 1: Search for an instance matching Module Code + Trimester. - Priority 2 (Fallback): Search for an instance matching MC Code + Trimester. - If a match is found, deployment proceeds and automated roster syncing begins. Deployment (SIT): - Can be deployed immediately after saving. No 2-week restriction. Post-Deployment Logic (for all Enrolment Types): - < 7 Days: Users can click [Undeploy] to retract the module. - > 7 Days: The [Undeploy] button is replaced by [Request Admin Approval].
In LMS, both the academic structure and the semester hierarchy meet at Course Offering — and that is where the student class list lives.
Before the Sync to LMS “Module code” question in §5, here is the fork flow as confirmed with Product and described in SRS §3.4.4 / §3.6.8.
Unchanged across fork: Module Code (= X).
Changed: version (1.0 → 2.0), trimester, and LMS offering / roster.
The source module (v1) is never altered.
Per Linh: v1 and v2 have two different student lists. After fork, User A (a student on v1) still only sees v1 unless enrolled on the new run’s offering.
Roster sync must bind to one Course Offering. The open question is what the UI Module code field means when Deploy resolves that offering — and how that interacts with fork keeping the same locked code (§4).
“Instance” here means Course Offering. Ambiguity: what does Module code mean in Priority 1?
Fits the fork story (same Module code across runs). But Module (type 101) has no student class list — the roster lives on each Offering. Builder Trimester is internal only (not synced from LMS), so it is not an LMS key we can rely on to pick the offering.
Straightforward for enrolment (one code → one roster). Conflicts with fork “same Module code, cannot change” (§4).
Breaks here: Module code alone cannot identify one enrolment list. Builder Trimester is internal only (not synced from LMS), so Linh’s “Module Code + Trimester → instance” is not a reliable LMS lookup unless Product defines a separate mapping rule.
Breaks here: enrolment sync is straightforward, but fork with separate v1/v2 student lists cannot keep one immutable “Module code” if that field is actually an Offering code.
Optional stronger check: Offering codes of v1 and v2 must both sit under the same LMS Module (type 101) — same subject family, different offerings/rosters.