04 — Roles, Channels and Data Access
Source: proposal §4.9, §1.1, §4.1 and backoffice mockups.
Roles
| Role | Channel | Main duties |
|---|---|---|
| Student (นักเรียน / นักศึกษา) | Student Mobile App, Student Web Portal | View academic info, register courses, file requests, pay |
| Parent (ผู้ปกครอง) | Parent Mobile App | Follow child's info, attendance, grades, dorm, announcements |
| Teacher / lecturer (ครู / อาจารย์) | Backoffice | Courses, teaching, attendance, grades |
| Coach (ผู้ฝึกสอนกีฬา) | Backoffice | Athlete data, training plans, competitions, fitness |
| Registrar staff (เจ้าหน้าที่ทะเบียน) | Backoffice | Admission, registry, curriculum, requests |
| Finance / scholarship staff | Backoffice | Fees, payments, กยศ., scholarships |
| Dormitory / student-affairs staff | Backoffice | Dorm, leave, entry/exit, welfare |
| Executive (ผู้บริหาร) | Executive Dashboard | Overview, KPIs, analytical reports |
| System administrator (ผู้ดูแลระบบ) | Central Administration | Master data, accounts, permissions, settings |
Mockups also show a เจ้าหน้าที่วิชาการ (academic affairs officer) at campus level [mockup].
Additional actors implied by the BA module structure [inferred from function names]:
| Actor | Where | Duties |
|---|---|---|
| ครูเวร (duty teacher) | SS-05.3, SS-06 | Dorm duty roster, dorm inspection, roll call |
| ครูประจำชั้น (homeroom teacher) [inferred] | SS-03.2, SS-06, SS-07 | Class roll call, probably first approver of leave |
| พยาบาล / health staff [inferred] | SS-09 | Illness, treatment, injury records |
| Nutrition / kitchen staff [inferred] | SS-08 | Menus, meal log, ingredients and cost |
| Counsellor / ฝ่ายปกครอง [inferred] | SS-13 | Discipline, counselling |
| Gate / security staff [inferred] | SS-07.3 | Exit and return log |
| Student as evaluator | UNI-07 | Evaluates instructors |
| Alumni | UNI-08.2 | Self-registers and updates own data, so alumni need accounts [inferred] |
| Applicant (not yet a student) | UNI-02, SS-01 | Applies, so applicants need accounts or guest access [inferred] |
| Parent as approver | SS-14.3 | Confirms the child's requests (e.g. leave), so parents take part in the approval workflow and do not only view |
Data-scoping rules [confirmed in proposal]
Access is determined by role + organisational scope:
- Education level: university (campus) vs. sports school. Workflows and menus differ per level.
- Organisational unit: a specific campus or a specific sports school. Staff only see their own unit.
- Central/executive: can see across all units, with drill-down by campus, school and time period.
- Parent: sees only linked children, and only what is permitted. One parent can be linked to several children, who may be at different levels (mockup: one child at a sports school ม.5/1 and one at a campus, ปี 1).
- AI Bot: answers only within the asking user's permissions.
Backoffice unit switching [mockup]
The Staff Backoffice header has a unit selector (e.g. "วิทยาเขตชลบุรี", "โรงเรียนกีฬาจังหวัดเชียงใหม่"). The sidebar title shows the active unit. The menu set differs by unit type (see 06-ux-ui.md). It is [unknown] whether one user can hold roles in several units. The selector suggests they can.
Roles in the use cases (67)
The use cases name 67 roles. The full list, with the use cases each role takes part in, is in use-cases/README.md#roles. The most frequent are นักศึกษา (80 UCs), นายทะเบียน (54), หัวหน้าภาค, การเงิน, คณบดี (30 each), ผู้ปกครอง (28), งานรับสมัคร, ผู้สมัคร, โค้ช, อาจารย์ที่ปรึกษา and อาจารย์ผู้สอน.
Roles that are new compared with the proposal include: รองอธิการบดีประจำวิทยาเขต (campus VP, a frequent approver), สภาวิชาการ, บัณฑิตวิทยาลัย, อาจารย์ที่ปรึกษาวิทยานิพนธ์, กรรมการสอบทักษะ, หัวหน้างานกีฬา, นักวิทยาศาสตร์การกีฬา, นักกายภาพบำบัด, แพทย์, พยาบาล, นักจิตวิทยา, ผู้รับผิดชอบด้านคุ้มครองเด็ก (safeguarding lead), DPO, นิติกร, ผู้ตรวจสอบภายใน, Data steward, DBA, Helpdesk L1/L2, ผู้ดูแล IAM, ผู้ดูแลความมั่นคงปลอดภัย, IT วิทยาเขต, and external parties (สมาคมกีฬา, สถานประกอบการ, บริษัทประกันภัยคู่สัญญา, ครูพี่เลี้ยง, employers verifying degrees).
Guardians and consent (from use cases W-127, W-128, W-160, W-93)
| Relation | Meaning | Rights |
|---|---|---|
LEGAL | Legal guardian (parent, court-appointed) | Full guardian rights over a minor, including legal consent |
CAREGIVER | Actual carer without legal custody (grandparent, relative) | Daily-care rights delegated by LEGAL or certified by staff (4-eyes), with expiry; cannot give consent that legally needs LEGAL |
LOCAL_GUARDIAN | In-country guardian of a foreign minor | As delegated |
OBSERVER | Parent of an adult student | Only the data categories the student consents to, with expiry, revocable at any time |
EMERGENCY_CONTACT | Contact in emergencies | Notified of incidents |
PICKUP | Authorised to pick up a minor | Appears on the pickup list |
- Verification levels: provisional (ID number + OTP: notifications and payments only) → level 1 (staff check documents in person at reporting-in) → level 2 (ThaID plus online document check).
- At 20 years old or on marriage,
LEGAL/CAREGIVERautomatically becomeOBSERVERand need new consent. - Access is ABAC per relation and data category. The student is notified whenever a guardian is linked.
- Court orders (W-93) create
CustodyRestriction/ContactRestriction, which block pickups, contact and notifications. Safeguarding cases (W-22) can add a ContactRestriction against an alleged staff member.
Open points
- Authentication method (SSO? MFA for staff? ThaID?): [unknown] for TNSU. The 2FA/PIN rules in proposal §5.3 belong to the other project.
- Parent-link verification process (how a parent proves the relationship): [unknown].
- Whether an adult university student's parent gets access by default or only with student consent (PDPA): [unknown]. Flag it as a privacy decision.
- Fine-grained permission model (RBAC only, or RBAC + attribute/unit scoping): [inferred] RBAC + unit scope.