forked from wangziqi/ruoyi-vue-pro
56 lines
4.4 KiB
Markdown
56 lines
4.4 KiB
Markdown
# 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
|
|
|
|
- [x] Generic account, password, token, tenant, and role tables are not duplicated.
|
|
- [x] Student/teacher/class permission matrix is documented and tested.
|
|
- [x] Cross-class and cross-tenant access is denied.
|
|
- [x] Invitation acceptance is idempotent and auditable.
|
|
- [x] Platform-admin tenant-ignore operations are explicit and permission guarded (none are exposed by this bounded capability).
|
|
- [x] Database changes use `flyway-postgresql`.
|
|
- [x] 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.
|
|
- [x] Supervision assignees are validated by `AdminUserApi`, and students are enriched by `MemberUserApi`.
|
|
- [x] 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.
|