EDU-012 — Classes and education relationships

Status: implemented
Type: bounded vertical capability
Phase: 4
Decision: Education owns tenant-local classes, student/teacher relationships, learning-risk rules, and follow-up tasks. System RBAC, AdminUser, departments, and data-permission policy remain authoritative; Member owns student accounts. Class roles never become System roles.

Tenant-admin outcome

Tenant administrators manage classes, student education relationships, invitations, and supervision within explicit tenant and row-level scopes while Member/System remain the owners of generic users and roles.

Scope

Education class entity and membership relationships.
Student/teacher/class domain roles without duplicating System RBAC.
Invitations and duplicate-safe acceptance.
Education profile extensions.
Supervision relationships and data scopes if retained.
Audit and operation logging.

Delivered contract

V4140 creates education_class, education_class_member, education_class_invitation, and append-only invitation audit.
Both students and teachers are existing tenant-scoped Member users validated through MemberUserApi; Education stores only IDs and domain roles.
Management permissions are independent: education:class:create, education:class:query, education:class-member:query, and education:class-invitation:create. Permissions are provisioned separately by System RBAC and are not represented in class relationships.
All aggregate tenant IDs come from TenantContextHolder; tenant-qualified mapper predicates and PostgreSQL triggers reject cross-tenant relationships.
Invitation creation is idempotent per tenant, actor, and key with request-hash conflict detection. Acceptance locks the invitation, checks invitee and expiry, and writes relationship plus audit in one transaction.
This capability intentionally excludes account creation, password handling, platform tenant-ignore operations, and education profile duplication.
V4270 adds supervision without changing account ownership: risk evidence is aggregated from existing Education practice, wrong-question, session, and vocabulary tables; Member and System data are API projections only.
Classes, rules, and follow-ups carry only dept_id/owner_user_id authorization projections and are registered with RuoYi DeptDataPermissionRule for department/self row scope.
Risk preview, rule authoring, idempotent task generation, and optimistic task handling have independent System permissions. (tenant_id, batch_key, student_user_id) is the retry-safe generation key; atomic PostgreSQL conflict-ignore and a subsequent scoped read return the same committed task to concurrent callers without recovering from a failed transaction.

Role and permission semantics

STUDENT and TEACHER are Education relationship labels only; they do not grant System RBAC permissions or authorize administrative endpoints.
Tenant administrators act through explicit System permissions (education:class:* and education:class-invitation:*).
A Member principal may only accept an invitation addressed to their own member user ID; accepting a STUDENT or TEACHER invitation creates that relationship but no additional API authority in this bounded slice.
Future teacher actions require a separate permission matrix and endpoints; no implicit role-based elevation is implemented.

Acceptance criteria

Generic account, password, token, tenant, and role tables are not duplicated.
Student/teacher/class permission matrix is documented and tested.
Cross-class and cross-tenant access is denied.
Invitation acceptance is idempotent and auditable.
Platform-admin tenant-ignore operations are explicit and permission guarded (none are exposed by this bounded capability).
Database changes use flyway-postgresql.
Risk preview and follow-up reads respect tenant plus System department/self data scope, including an unfiltered-class CTE aggregation path verified against a real LoginUser/DeptDataPermissionRespDTO PostgreSQL context.
Supervision assignees are validated by AdminUserApi, and students are enriched by MemberUserApi.
Follow-up generation and handling are duplicate-safe and stale-write-safe.

Risk and rollback

Risk: High authorization and relationship-integrity risk.
Rollback: Disable management endpoints and correct relationships through audited forward operations.

4.4 KiB Raw Blame History