UC-BEH-DOCSUP-012 — Docent-docenttoegang forceren
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-DOCSUP-012 |
| Naam | Docent-docenttoegang forceren |
| Domein | Beheerder / Docentondersteuning |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, docentondersteuningcomponent, historiecomponent |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Content > Docent ondersteuning |
| Gerelateerde usecases | UC-BEH-DOCSUP-001, UC-BEH-DOCSUP-002, UC-BEH-DOCSUP-003, UC-BEH-DOCSUP-004, UC-BEH-DOCSUP-005, UC-BEH-DOCSUP-006, UC-BEH-DOCSUP-007, UC-BEH-DOCSUP-008, UC-BEH-DOCSUP-009, UC-BEH-DOCSUP-010, UC-BEH-DOCSUP-011, UC-BEH-DOCSUP-013, UC-BEH-DOCSUP-014 |
| Primaire entiteiten | Users, UserRoles, Roles, TeacherLevels, TeacherLevelCategories, TeacherLevelCategoryExercises, Exercises, ExerciseModules, ExerciseHistory, LevelCollaborators, LevelStudentAuthorizations, UserRelationships |
| Secundaire entiteiten / events | RelationshipEvents, SystemMessages, beheerlog, docentondersteuning-readmodels, autorisatiecomponent |
| Gerelateerde popups | POP-BEH-DOCSUP-FORCE-TEACHER-RELATION-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder vanuit docentondersteuning bij uitzondering een docent-docentcontext forceert tussen de geselecteerde docent en een andere actieve docent.
De actie is bedoeld voor supportscenario’s waarin een geldige samenwerking nodig is om een collaboratoractie of eigendomsoverdracht correct te kunnen voorbereiden, terwijl de normale uitnodigingsflow niet bruikbaar is. Deze beheeractie is expliciet en auditbaar.
De actie is supportgericht, vindt plaats binnen één geselecteerde docentcontext en vereist server-side validatie van beide docentaccounts en de beoogde docent-docentrelatie.
De wijziging wordt auditbaar vastgelegd. De actie wijzigt geen historische runs, resultaten of centrale categorie- en module-identiteit.
Uitgangspunten
- Docentondersteuning werkt altijd vanuit één gekozen docentcontext.
- De beheerder heeft supportgerichte inzage, maar mutaties blijven beperkt tot expliciete beheeracties met audit.
- Centrale categorie- en module-identiteit worden niet vanuit deze pagina beheerd.
- Server-side autorisatie is leidend; clientstate mag geen objecttoegang afdwingen.
- Historische runs, resultaten en PDF-contexten worden niet herschreven.
3. Scope
Deze usecase beschrijft:
- Selecteren van een doel-docent voor een docent-docentcontext met de gekozen docent.
- Controleren dat beide gebruikers actieve docentaccounts zijn.
- Voorkomen van dubbele of conflicterende actieve docent-docentrelaties.
- Tonen van een bevestiging via PopupKey met verplichte reden.
- Aanmaken of heractiveren van de docent-docentrelatie met audit en relatie-event.
Deze usecase beschrijft niet:
- Centraal categoriebeheer; dat blijft bronhoudend in Beheerder / Categorieën beheren.
- Centraal technisch modulebeheer; dat blijft bronhoudend in Beheerder / Modules beheren.
- Volledig account- en rolbeheer; dat blijft bronhoudend in Beheerder / Accountbeheer.
- Reguliere docentflows vervangen; docentondersteuning is supportgericht en niet de primaire docentinterface.
- Live meekijken tijdens actieve oefeningen; beheerders mogen geschiedenis analyseren, maar niet live meekijken.
- Popupteksten, knopteksten of inputlabels specificeren; usecases verwijzen uitsluitend naar PopupKey.
3.1 Afbakening met aangrenzende domeinen
| Onderdeel | Afbakening |
|---|---|
| Docent / Oefenaanbod | Docenten beheren hun eigen niveaus, categorieën en oefeningen via de reguliere docentflows; docentondersteuning biedt beheerderinzage en gerichte correctie. |
| Beheerder / Categorieën beheren | Centrale categorie-identiteit, migratie en statuswijziging worden daar beheerd, niet in docentondersteuning. |
| Beheerder / Modules beheren | Technische modulemetadata en modulemigraties worden daar beheerd; docentondersteuning kan alleen concrete oefeningcontext inspecteren. |
| Beheerder / Accountbeheer | Rollen, accountstatus en account lifecycle horen daar; docentondersteuning gebruikt bestaande account- en relatiecontext. |
| Generiek / Relaties | Relaties en uitnodigingen blijven bronhoudend in het relatiedomein; docentondersteuning kan alleen bestaande geldige context gebruiken of een expliciete beheeractie auditen. |
4. Pre-condities
| ID | Voorwaarde |
|---|---|
| PRE-001 | De gebruiker is succesvol ingelogd in OefenHub. |
| PRE-002 | De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft. |
| PRE-003 | De beheerder bevindt zich binnen de beheeromgeving via Content > Docent ondersteuning. |
| PRE-004 | De pagina gebruikt actuele serverdata; clientstate, routeparameters of verborgen formuliervelden bepalen geen autorisatie, docentcontext, niveaucontext of oefeningcontext. |
| PRE-005 | De ondersteuningsweergave voor één docent is geopend. |
| PRE-006 | Er is een doel-docent geselecteerd die een actief docentaccount heeft. |
| PRE-007 | De beheerder heeft de actie expliciet gekozen. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | Er bestaat een actieve docent-docentcontext tussen de geselecteerde docent en de doel-docent wanneer alle validaties slagen. |
| POST-002 | De wijziging is auditbaar vastgelegd. |
| POST-003 | Historische resultaten en runs blijven ongewijzigd. |
| POST-004 | Afgeleide collaborator- en kandidaatlijsten kunnen opnieuw worden opgebouwd. |
| POST-005 | Onbevoegde of ongeldige contexten zijn veilig geblokkeerd. |
6. Trigger
De usecase start wanneer de beheerder de actie Docent-docenttoegang forceren kiest en bevestigt.
7. Normale processtroom
| Stap | Actor | Component / context | Handeling | Resultaat | Belangrijke gegevens |
|---|---|---|---|---|---|
| 1 | Beheerder | Docentondersteuning | Kiest de beheeractie. | De frontend opent de bevestiging. | Geselecteerde context. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag de actie uitvoeren. | Server-side rolcontext. |
| 3 | Backend | DocentContextService | Valideert de geselecteerde docent en doel-docent. | Alleen twee actieve docentaccounts zijn toegestaan. | Users, UserRoles, Roles. |
| 4 | Backend | RelatieService | Controleert bestaande docent-docentrelatie. | Dubbele of conflicterende actieve relaties worden voorkomen. | UserRelationships. |
| 5 | Beheerder | Popup | Bevestigt actie en vult reden in wanneer vereist. | De definitieve verwerking start. | POP-BEH-DOCSUP-FORCE-TEACHER-RELATION-CONFIRM |
| 6 | Backend | RelatieService | Maakt of heractiveert de docent-docentrelatie. | De docent-docentcontext wordt actief. | UserRelationships, RelationshipEvents. |
| 7 | Backend | AuditService | Legt de actie vast. | De wijziging is herleidbaar. | Beheerlog / history. |
| 8 | Frontend | Docentondersteuning | Ververs de context. | De beheerder ziet de actuele situatie. | Readmodel opnieuw geladen. |
8. Alternatieve en exceptionele processtromen
| Stap | Situatie | Afhandeling | PopupKey | Datamutatie |
|---|---|---|---|---|
| 2 | Beheerdercontext is ongeldig. | De backend weigert de actie en toont een veilige blokkade. | POP-BEH-DOCSUP-NO-ACCESS | Geen. |
| 3 | De geselecteerde docent bestaat niet of is niet toegankelijk. | De ondersteuningsweergave wordt niet geopend of wordt veilig teruggezet naar het overzicht. | POP-BEH-DOCSUP-SAVE-ERROR | Geen. |
| 4 | Het gekozen object bestaat niet meer. | De pagina toont dat het object niet beschikbaar is en ververst de context. | Niet van toepassing | Geen. |
| 5 | De readmodeldata is tijdelijk incompleet. | De beschikbare gegevens worden getoond met veilige ontbrekend-status; ontbrekend wordt niet als nul geïnterpreteerd. | Niet van toepassing | Geen. |
| 6 | De beheerder gebruikt een oude route of clientstate. | De backend negeert de clientcontext en herleidt de actuele context opnieuw. | Niet van toepassing | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-UC-BEH-DOCSUP-012-001 | De actie is alleen toegestaan binnen een geldige server-side beheerdercontext. |
| BR-UC-BEH-DOCSUP-012-002 | Beide betrokken gebruikers moeten actieve docentaccounts zijn. |
| BR-UC-BEH-DOCSUP-012-003 | De geselecteerde docent en doel-docent mogen niet dezelfde gebruiker zijn. |
| BR-UC-BEH-DOCSUP-012-004 | De beheerder moet de actie expliciet bevestigen en een reden opgeven. |
| BR-UC-BEH-DOCSUP-012-005 | Dubbele of conflicterende actieve docent-docentrelaties zijn niet toegestaan. |
| BR-UC-BEH-DOCSUP-012-006 | De actie maakt geen collaborator-koppeling en draagt geen eigenaarschap over. |
| BR-UC-BEH-DOCSUP-012-007 | Historische runs, resultaten en PDF-contexten worden niet herschreven. |
| BR-UC-BEH-DOCSUP-012-008 | De wijziging moet auditbaar zijn. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-UC-BEH-DOCSUP-012-001 | De beheerderrol wordt vlak vóór mutatie gecontroleerd. |
| VAL-UC-BEH-DOCSUP-012-002 | De geselecteerde docent en doel-docent moeten bestaan. |
| VAL-UC-BEH-DOCSUP-012-003 | Beide gebruikers moeten een actieve docentrol hebben. |
| VAL-UC-BEH-DOCSUP-012-004 | De doel-docent mag niet dezelfde gebruiker zijn als de geselecteerde docent. |
| VAL-UC-BEH-DOCSUP-012-005 | Er mag nog geen conflicterende actieve docent-docentrelatie bestaan. |
| VAL-UC-BEH-DOCSUP-012-006 | De reden is verplicht en mag niet leeg zijn. |
| VAL-UC-BEH-DOCSUP-012-007 | De mutatie moet transactioneel worden verwerkt. |
| VAL-UC-BEH-DOCSUP-012-008 | Gelijktijdige wijzigingen moeten vóór opslaan opnieuw worden gevalideerd. |
| VAL-UC-BEH-DOCSUP-012-009 | De client mag geen verborgen velden als bron van waarheid gebruiken. |
11. Datamutaties en events
| Object / event | Mutatie |
|---|---|
| UserRelationships / RelationshipEvents | Aanmaken of activeren van docent-docentcontext met beheer-geforceerde herkomst. |
| Beheerlog / history | Vastleggen van beheerder, tijdstip, betrokken objecten en reden. |
| SystemMessages | Informatief bericht aan de betrokken docenten wanneer zij een actief intern account hebben; het bericht is geen relatiebron. |
12. Geen datamutaties
| Object | Waarom geen mutatie |
|---|---|
| LevelCollaborators | Er wordt geen collaborator-koppeling aangemaakt; dat blijft UC-BEH-DOCSUP-010. |
| TeacherLevels | Eigenaarschap, niveaugegevens en zichtbaarheid blijven ongewijzigd. |
| LevelStudentAuthorizations | Leerlingtoegang wordt niet gewijzigd. |
| ExerciseRuns | Historische runs, resultaten, gedeelde oefeningen en PDF-contexten blijven behouden. |
| User credentials | Wachtwoorden, tokens en identity-providergegevens blijven buiten scope. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
| PopupKey | Gebruik |
|---|---|
| POP-BEH-DOCSUP-FORCE-TEACHER-RELATION-CONFIRM | Bevestiging voor de actie Docent-docenttoegang forceren. |
| POP-BEH-DOCSUP-SAVE-ERROR | Foutafhandeling wanneer de beheeractie niet kan worden opgeslagen. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Onderdeel | Afleiding |
|---|---|
| Functioneel Ontwerp | FO moet Docent-docenttoegang forceren beschrijven als expliciete supportactie binnen docentondersteuning. |
| Technisch Ontwerp | Technisch Ontwerp: technische rolflows, oefencatalogus, relatiebeheer en logging en historie beschrijven de technische uitwerking. TO vereist transactionele verwerking van relatieheractivatie of relatieaanmaak, server-side validatie en auditregistratie. |
| Software Requirements Specification | SRS moet vastleggen dat forceren alleen twee actieve docentaccounts mag verbinden en geen collaborator- of eigendomsmutatie uitvoert. |
| Database | Wijzigt UserRelationships / RelationshipEvents en auditrecords; historische runs blijven ongewijzigd. |
19. SRS-trace
Deze usecase bevat geen normatieve requirementtekst. De centrale eis en acceptatiecriteria staan in de SRS; onderstaande tabel koppelt de usecase-afleiding alleen aan centrale SRS-*- en AC-*-items.
| Usecase-afleiding | Dekt | Usecasecontext |
|---|---|---|
REQ-UC-BEH-DOCSUP-012-001 | SRS-AUTH-001 SRS-TCH-001 SRS-ADM-008 SRS-ADM-001 AC-AUTH-001 AC-TCH-001 AC-ADM-008 AC-ADM-001 | Een beheerder de actie Docent-docenttoegang forceren kunnen laten uitvoeren binnen docentondersteuning |
REQ-UC-BEH-DOCSUP-012-002 | SRS-AUTH-001 SRS-TCH-001 SRS-ADM-001 AC-AUTH-001 AC-TCH-001 AC-ADM-001 | De docentcontext server-side valideren |
REQ-UC-BEH-DOCSUP-012-003 | SRS-ACC-002 SRS-TCH-001 SRS-ADM-002 SRS-ADM-001 AC-ACC-002 AC-TCH-001 AC-ADM-002 AC-ADM-001 | Afdwingen dat beide betrokken gebruikers actieve docentaccounts zijn |
REQ-UC-BEH-DOCSUP-012-004 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | Een bevestiging via PopupKey gebruiken |
REQ-UC-BEH-DOCSUP-012-005 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | De wijziging auditbaar vastleggen |
REQ-UC-BEH-DOCSUP-012-006 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | De geforceerde oorsprong auditbaar vastleggen en altijd een verplichte reden vragen |
REQ-UC-BEH-DOCSUP-012-007 | SRS-LRN-009 SRS-ADM-001 SRS-CNT-001 AC-LRN-009 AC-ADM-001 AC-CNT-001 | Historische runs, resultaten en centrale contentidentiteit niet herschrijven |
REQ-UC-BEH-DOCSUP-012-008 | SRS-ADM-001 SRS-NFR-SEC-001 AC-ADM-001 AC-NFR-SEC-001 | Conflicterende gelijktijdige wijzigingen veilig afhandelen |