Manage Central Access Control › Access Control
🎬 Simulate:

Access Control

Role Assignments
User Email Role Scope Date
Khamla Vongsa khamla.vongsa@admin.edu.la Super Administrator All institutions 2026-01-10
Phonesavanh Boupha phonesavanh@admin.edu.la Sale Administrator All institutions 2026-03-05
Soukvilay Thao soukvilay@admin.edu.la Tag Administrator All institutions 2026-04-22
Bounma Keodouangdy bounma@admin.edu.la Central Approve All institutions 2026-05-30
Vilayvanh Sisouphanh vilayvanh@admin.edu.la Program Administrator All institutions 2026-06-02
Anousone Chanthavong anousone@admin.edu.la Instructor All institutions 2026-06-18
Somchai Keovongsa somchai.k@luangprabangvc.edu.la Program Administrator Luangprabang Vocational College 2026-02-14
Latsamy Phommachanh latsamy.p@luangprabangvc.edu.la Instructor Luangprabang Vocational College 2026-03-20
Chanthone Vilaysack chanthone.v@luangprabangvc.edu.la Instructor Luangprabang Vocational College 2026-04-11

Screen Flow (from flow.puml):

→ confirm / cancel → Access Control → [exit]
📝 Spec notes — UC-IDP.16 / SCR-IDP.60 + SCR-IDP.63 + SCR-IDP.65 (fields, actions, requirements)
Identity
  • Screen: SCR-IDP.60 — Access Control
  • Use case: UC-IDP.16 — Manage Central Access Control
Brief description

The Access Control page is the role assignment management console for UC-IDP.16 — a single filterable table listing every role assignment the current Admin has visibility into. Columns are identical for every row; a Scope column distinguishes platform-wide assignments ("All institutions") from assignments tied to one institute (that institute's name). A single "+ Add" button sits above the table and opens the Add Role Assignment dialog (SCR-IDP.63), which resolves its own Scope line automatically from the Admin's current Working Institute context — it is not a choice made by which button was clicked. The Remove action on any row opens the shared Remove Role Assignment Confirmation dialog (SCR-IDP.65). Self-removal of an Admin's own primary role assignment, and removal of the last Super Administrator assignment, are blocked.

Fields — Role Assignments View
  • filter_search "Search user" — text · empty default · always visible · max_length 255
  • filter_role "Role" — enum · always visible · union of every role the Admin can see
  • assignment_user_name "User" — text · User.firstname · read-only · always visible
  • assignment_user_email "Email" — text · User.email · read-only · always visible
  • assignment_role_name "Role" — text · Role.name · read-only · always visible
  • assignment_scope "Scope" — text · computed · read-only · always visible — "All institutions" for platform-wide rows, or the specific institute name
  • assignment_date "Date" — date · UserRole.assigned_at · read-only · always visible (⚠ UserRole.assigned_at not yet in entities.puml)
  • empty_message_assignments "(empty state)" — literal "No role assignments found. Click '+ Add' to create the first assignment." · visible when assignment_list.count == 0 · read-only
Actions — SCR-IDP.60
  • apply_filters "Search" — always enabled · triggers UC-IDP.16-M-1
  • clear_filters "Clear Filters" — always enabled · triggers UC-IDP.16-M-1
  • add_assignment "+ Add" — always enabled · opens SCR-IDP.63, which resolves its own Scope from the Admin's current Working Institute context · triggers UC-IDP.16-M-2
  • remove_assignment "Remove" — enabled when assignment_is_not_self_role == true · triggers UC-IDP.16-A-2A-1; opens SCR-IDP.65
Additional requirements
  1. Every role assignment and removal attempt (successful or failed) is recorded to the audit trail with: actor, target user, role, institution scope (if applicable), and timestamp — within 1 s of the action. [refs: NFR-11]
  2. The Super Administrator cannot remove their own Super Administrator assignment. [refs: —]
  3. At least one active Super Administrator role assignment must exist at all times — the Remove action for the last Super Administrator assignment is disabled in the UI and rejected server-side if bypassed. [refs: —]
  4. Access is zone-gated, and this gating determines which rows appear in the table: a Super Administrator sees every assignment; a Program Administrator sees only their own Working Institute's Program Administrator/Instructor assignments. The single "+ Add" button is available to either — its resolved Scope follows the same Working Institute context. [refs: NFR-10, SS-IDP.31]
↳ Embedded dialog: SCR-IDP.63 — Add Role Assignment (serves both zones)

Type: dialog · Opened by: the single "+ Add" button on SCR-IDP.60 · Returns to: SCR-IDP.60 on Confirm (success) or Cancel · Scenario AF-2B: auto-opens with Scope = Working Institute (demonstrates the "Working Institute selected" context, without a separate button) · Scenario AF-4A: auto-opens (Global scope) with result summary (partial success) · Scenario AF-4B: auto-opens (Global scope) with all-duplicate error (stays open for correction)

Merged 2026-07-15 (rev 2) from two separate dialogs (SCR-IDP.64 Add Central Role Assignment + the original SCR-IDP.63) — they differed only in whether a Scope line was shown. Rev 3 then merged SCR-IDP.60's two Add buttons into one, since the Scope line was already resolved from Working Institute context, not from which button was clicked. Role checkboxes are filtered by the Admin's own authority: Program Administrator sees only Program Administrator and Instructor; Super Administrator sees the full role set. A central-level role checked is always platform-wide, independent of the Scope line shown.

Fields
  • scope_label "Scope" — text · computed · read-only · always visible — "All institutions (platform-wide)" or the Working Institute's name
  • roles "Roles" — enum (multi-select checkboxes) · one_of [super_administrator, sale_administrator, tag_administrator, central_approve, program_administrator, instructor] · min_items 1 · required
  • member_search "Search member" — text · empty default · always visible · max_length 255
  • selected_members "Members to assign" — multi-item chip list · enforced non-empty via confirm.enabled_when · read-only (per-item × remove button)
Actions
  • add_member_from_search "+ (select from search results)" — enabled when member_search.has_match == true · triggers UC-IDP.16-M-4
  • remove_member "× (per-member)" — always enabled · triggers UC-IDP.16-M-4
  • confirm "Confirm" — enabled when selected_members.count > 0 && roles.count > 0 · triggers UC-IDP.16-M-4
  • cancel "Cancel" — always enabled · dismisses dialog, no data change
Additional requirements
  1. After each successful member selection from search results, the search box clears immediately so the Admin can search for the next member without manual clearing.
  2. Each member in the selected list shows the user's full name and email alongside a per-member × remove button; a user already in the list is excluded from the search dropdown to prevent duplicate selection.
  3. If Confirm results in a mix of new and duplicate assignments (at the resolved scope), the dialog shows a result summary (two labelled groups — Assigned and Skipped) before auto-closing.
  4. If all selected members already hold all selected roles at the resolved scope, the dialog remains open with an error message listing the duplicate combinations — no assignments are created.
  5. Role options are filtered by the Admin's own authority, independent of the resolved Scope.
  6. The Scope line describes what a Program Administrator/Instructor selection applies to — it does not affect central-level role selections, which are always platform-wide.
  7. Adding a role here only works on users who already have an account (found via member search) — inviting a brand-new Instructor remains exclusively UC-IDP.04's flow.
↳ Embedded dialog: SCR-IDP.65 — Remove Role Assignment Confirmation
Identity
  • Screen: SCR-IDP.65 — Remove Role Assignment Confirmation
  • Type: dialog (Bootstrap modal — no standalone page)
  • Opened by: "Remove" button on SCR-IDP.60 (triggers UC-IDP.16-A-2A-1)
  • Shared by: both zones of UC-IDP.16
  • Scenarios: AF-2A (confirm removal); Cancel closes with no change and has no dedicated scenario (not a distinct UC flow step)
Brief description

Confirmation dialog that appears when an administrator clicks "Remove" on a role assignment in the Access Control page. Displays the selected assignment (user name, email, and role) so the administrator can review the target before confirming. No data entry is required — the administrator either confirms the removal or cancels to return to the Access Control page with no changes.

Fields (all read-only display)
  • user_display_name "User" — text · computed from User.firstname + User.lastname · pre-loaded from selected row · read-only
  • user_email "Email" — text · sourced from user's active staff or instructor profile · pre-loaded from selected row · read-only
  • role_name "Role" — text · Role.name · read-only
Actions
  • confirm_remove "Confirm Remove" — always enabled · triggers UC-IDP.16-A-2A-3; removes assignment, records audit entry, closes dialog, refreshes list
  • cancel "Cancel" — always enabled · closes dialog without changes (not a distinct UC flow step)
Additional requirements
  1. The assignment details displayed (user name, email, and role) must exactly match the record selected in SCR-IDP.60 — no summarisation or truncation is permitted.
  2. The dialog must be keyboard-accessible — Tab cycles focus between "Confirm Remove" and "Cancel"; Enter/Space activates the focused button; Escape key triggers Cancel. [refs: NFR-09]