UC-BEH-DOCSUP-013 — Eigenaarschap overdragen als beheerder
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-DOCSUP-013 |
| Naam | Eigenaarschap overdragen als beheerder |
| 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-012, 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-TRANSFER-OWNER-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder vanuit docentondersteuning het eigenaarschap van een niveau overdraagt aan een bestaande actieve collaborator van datzelfde niveau.
De actie is supportgericht, vindt plaats binnen één geselecteerde docentcontext en vereist server-side validatie van het niveau, de huidige eigenaar, de nieuwe eigenaar en de bestaande collaborator-koppeling.
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:
- Uitvoeren van de beheeractie: Eigenaarschap overdragen als beheerder.
- Controleren van beheerderrol, docentcontext en objectcontext.
- Tonen van een bevestiging via PopupKey.
- Verwerken van de domeinmutatie wanneer alle validaties slagen.
- Auditbaar vastleggen van actor, tijdstip, reden en betrokken objecten.
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 één relevant niveau of object binnen de docentcontext geselecteerd. |
| PRE-007 | De beheerder heeft de actie expliciet gekozen. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De actie Eigenaarschap overdragen als beheerder is verwerkt wanneer alle validaties slagen. |
| POST-002 | De wijziging is auditbaar vastgelegd. |
| POST-003 | Historische resultaten en runs blijven ongewijzigd. |
| POST-004 | Afgeleide overzichten en aantallen kunnen opnieuw worden opgebouwd. |
| POST-005 | Onbevoegde of ongeldige contexten zijn veilig geblokkeerd. |
6. Trigger
De usecase start wanneer de beheerder de actie Eigenaarschap overdragen als beheerder 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 docent- en niveaucontext. | Objecten buiten context worden geweigerd. | TeacherLevels en contextrecords. |
| 4 | Backend | Domeinservice | Controleert object-specifieke voorwaarden. | Alle business rules worden opnieuw server-side toegepast. | Relaties, autorisaties, collaborators of eigenaar. |
| 5 | Beheerder | Popup | Bevestigt actie en vult reden in wanneer vereist. | De definitieve verwerking start. | POP-BEH-DOCSUP-TRANSFER-OWNER-CONFIRM |
| 6 | Backend | Domeinservice | Voert de mutatie transactioneel uit. | De domeinstatus wordt aangepast. | TeacherLevels en LevelCollaborators |
| 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-013-001 | De actie is alleen toegestaan binnen een geldige server-side docentcontext. |
| BR-UC-BEH-DOCSUP-013-002 | Het niveau moet binnen de geselecteerde docentcontext vallen. |
| BR-UC-BEH-DOCSUP-013-003 | De nieuwe eigenaar moet een actieve collaborator van hetzelfde niveau zijn. |
| BR-UC-BEH-DOCSUP-013-004 | De nieuwe eigenaar moet een actief docentaccount hebben. |
| BR-UC-BEH-DOCSUP-013-005 | De nieuwe eigenaar mag niet gelijk zijn aan de huidige eigenaar. |
| BR-UC-BEH-DOCSUP-013-006 | De beheerder moet de actie expliciet bevestigen en een reden opgeven. |
| BR-UC-BEH-DOCSUP-013-007 | De vorige eigenaar blijft na overdracht actieve collaborator van hetzelfde niveau. |
| BR-UC-BEH-DOCSUP-013-008 | Leerlingautorisaties, resultaten en historische runs blijven ongewijzigd. |
| BR-UC-BEH-DOCSUP-013-009 | De wijziging moet auditbaar zijn. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-UC-BEH-DOCSUP-013-001 | De beheerderrol wordt vlak vóór mutatie gecontroleerd. |
| VAL-UC-BEH-DOCSUP-013-002 | LevelId is verplicht en moet binnen de geselecteerde docentcontext vallen. |
| VAL-UC-BEH-DOCSUP-013-003 | NewOwnerUserId is verplicht en moet een actief docentaccount zijn. |
| VAL-UC-BEH-DOCSUP-013-004 | NewOwnerUserId moet een actieve collaborator-koppeling op hetzelfde niveau hebben. |
| VAL-UC-BEH-DOCSUP-013-005 | NewOwnerUserId mag niet gelijk zijn aan de huidige eigenaar. |
| VAL-UC-BEH-DOCSUP-013-006 | De reden is verplicht en mag niet leeg zijn. |
| VAL-UC-BEH-DOCSUP-013-007 | De mutatie moet transactioneel worden verwerkt. |
| VAL-UC-BEH-DOCSUP-013-008 | Gelijktijdige wijzigingen moeten vóór opslaan opnieuw worden gevalideerd. |
11. Datamutaties en events
| Object / event | Mutatie |
|---|---|
| TeacherLevels en LevelCollaborators | Actuele eigenaar wordt gewijzigd; de vorige eigenaar blijft of wordt actieve collaborator van hetzelfde niveau. |
| 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 rechtenbron. |
12. Geen datamutaties
| Object | Waarom geen mutatie |
|---|---|
| UserRelationships | Docent-docentrelaties worden niet aangemaakt of verwijderd. |
| LevelStudentAuthorizations | Leerlingtoegang blijft ongewijzigd. |
| Exercises | Oefeningen en configuratie blijven ongewijzigd. |
| 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-TRANSFER-OWNER-CONFIRM | Bevestiging voor de actie Eigenaarschap overdragen als beheerder. |
| 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 Eigenaarschap overdragen als beheerder 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 eigenaarschap, borging van de collaboratorstatus van de vorige eigenaar, server-side contextvalidatie en auditregistratie. |
| Software Requirements Specification | SRS moet voorwaarden, bevestiging, redenplicht en uitsluitingen voor Eigenaarschap overdragen als beheerder vastleggen. |
| Database | Wijzigt TeacherLevels en LevelCollaborators 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-013-001 | SRS-TCH-007 SRS-ADM-008 SRS-ADM-001 AC-TCH-007 AC-ADM-008 AC-ADM-001 | Een beheerder de actie Eigenaarschap overdragen als beheerder kunnen laten uitvoeren binnen docentondersteuning |
REQ-UC-BEH-DOCSUP-013-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-013-003 | SRS-AUTH-001 SRS-ADM-002 SRS-ADM-001 AC-AUTH-001 AC-ADM-002 AC-ADM-001 | Object-specifieke voorwaarden opnieuw server-side controleren |
REQ-UC-BEH-DOCSUP-013-004 | SRS-ADM-001 SRS-POP-001 AC-ADM-001 AC-POP-001 | Een bevestiging via PopupKey gebruiken |
REQ-UC-BEH-DOCSUP-013-005 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | De wijziging auditbaar vastleggen |
REQ-UC-BEH-DOCSUP-013-006 | SRS-CAT-001 SRS-TCH-006 SRS-ADM-001 AC-CAT-001 AC-TCH-006 AC-ADM-001 | Eigenaarschap uitsluitend overdragen aan een bestaande actieve collaborator van hetzelfde niveau |
REQ-UC-BEH-DOCSUP-013-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-013-008 | SRS-ADM-001 SRS-NFR-SEC-001 AC-ADM-001 AC-NFR-SEC-001 | Conflicterende gelijktijdige wijzigingen veilig afhandelen |