UC-BEH-ACC-007 — Account anonimiseren als beheerder
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-ACC-007 |
| Naam | Account anonimiseren als beheerder |
| Domein | Beheerder / Accountbeheer |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, identity-providerkoppeling, accountlogkanaal |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Accounts beheren > Accountdetail > Lifecycle |
| Gerelateerde usecases | UC-BEH-ACC-001, UC-BEH-ACC-002, UC-BEH-ACC-003, UC-BEH-ACC-004, UC-BEH-ACC-005, UC-BEH-ACC-006, UC-BEH-ACC-008, UC-BEH-ACC-009, UC-BEH-ACC-010, UC-GEN-ACC-001, UC-GEN-ACC-002, UC-GEN-ACC-005 |
| Primaire entiteiten | Users, Roles, UserRoles, UserSettings, ProfileAvatars, accountlogkanaal |
| Secundaire entiteiten / events | UserRelationships, RelationshipInvitations, TeacherLevels, TeacherLevelAuthorizations, LevelCollaborators, ExerciseRuns, LiveViewAudit, SystemMessages, PrivateMessageThreads, Tickets |
| Gerelateerde popups | POP-BEH-ACC-ANONYMIZE-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De usecase beschrijft hoe een beheerder een OefenHub-account via een beheerflow laat anonimiseren. Dit is een zware, niet-reguliere lifecycleactie naast de selfservice-flow voor accountverwijdering.
Anonimisering vervangt zichtbare persoonsgegevens systematisch door niet-persoonsherleidbare waarden, zet het account buiten regulier gebruik en ruimt afhankelijke toegang op. Historische domeindata blijft behouden waar dat nodig is voor audit, resultaten, meldingen en reconstructie.
De actie wijzigt niet rechtstreeks het identity-provideraccount. OefenHub beheert de interne applicatie-identiteit, profielvelden, rollen, relaties en afhankelijkheden binnen het eigen domein.
Uitgangspunten
- Anonimisering is een definitieve beheeractie binnen OefenHub.
- Voornaam wordt Anoniem, tussenvoegsel wordt #, achternaam wordt een korte niet-voorspelbare code en e-mailadres wordt anoniem.<code>@verwijderd.acc.
- De waarde # is gereserveerd voor systeemgebruik.
- Afhankelijke toegang wordt beëindigd of opgeruimd volgens domeinregels.
- Oude en nieuwe identiteit worden afgeschermd accountlogmatig vastgelegd.
3. Scope
Deze usecase beschrijft:
- Anonimiseren van één intern OefenHub-account door beheerder.
- Vervangen van zichtbare identiteit door systeemwaarden.
- Zetten van Users.IsActive op false.
- Beëindigen of niet langer autoriserend maken van actieve rollen, relaties en toegang waar nodig.
- Afhandelen van docentniveau-eigenaarschap waar het account eigenaar is.
- Behouden van historische tickets, berichten, runs en auditdata zonder actuele persoonsgegevens.
- Vastleggen van reden en oude/nieuwe identiteit in afgeschermd accountlogkanaal.
Deze usecase beschrijft niet:
- Wachtwoorden, tokens, secrets, identity-provider-sessies of credentialstatus beheren.
- Een Keycloak- of identity-provideraccount rechtstreeks wijzigen of verwijderen.
- Vrij relatiebeheer tussen gebruikers uitvoeren; relatieflows blijven bronhoudend in het relatiedomein.
- Profielwijzigingen als selfservice-gebruikersflow dupliceren; eigen profielbeheer blijft bronhoudend in generiek/profiel.
- Popupteksten, knopteksten of inputlabels specificeren; usecases verwijzen uitsluitend naar PopupKey.
- Identity-provideraccount verwijderen.
- Historische runs, resultaten, tickets of berichten hard verwijderen.
- Een geanonimiseerd account herstellen naar een persoonsaccount.
- Een gewone gebruikersprofielwijziging uitvoeren.
- Zonder impactanalyse afhankelijke docentniveau-eigenaarschap laten bestaan.
3.1 Afbakening met aangrenzende domeinen
| Onderdeel | Afbakening |
|---|---|
| Generiek / Account | Login, provisioning, logout en selfservice-accountverwijdering blijven bronhoudend in het generieke accountdomein. |
| Generiek / Profiel en voorkeuren | Eigen profiel- en voorkeurenbeheer blijft gebruikergericht; accountbeheer bevat alleen beheerdercorrecties en uitzonderingsacties. |
| Generiek / Relaties | Relatie-uitnodigingen, acceptatie en normale ontkoppeling blijven in het relatiedomein; accountbeheer kan wel afhankelijke toegang beëindigen bij lifecycle-acties. |
| Beheerder / Docentondersteuning | Docentstructuur, leerlingtoegang en collaborators worden daar supportmatig beheerd; accountbeheer ziet accountbrede identiteit, rollen en lifecycle. |
| Identity provider | Authenticatie, wachtwoorden, verificatie, tokens en credentials blijven buiten OefenHub-accountbeheer. |
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 Accounts beheren of een onderliggende accountbeheerroute. |
| PRE-004 | Clientstate, routeparameters of verborgen formuliervelden bepalen nooit welk account gewijzigd mag worden. |
| PRE-005 | De identity provider blijft bronhouder voor authenticatie, wachtwoorden, tokens, sessies en credential lifecycle. |
| PRE-006 | De beheerder heeft accountdetail geopend. |
| PRE-007 | Het doelaccount is niet al geanonimiseerd. |
| PRE-008 | De beheerder heeft afhankelijkheden kunnen inzien. |
| PRE-009 | Voor docentniveau-eigenaarschap is een geldig opvolgscenario bepaald of blokkade vastgesteld. |
| PRE-010 | De beheerder heeft een expliciete reden voor anonimisering. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | Persoonsherleidbare zichtbare accountvelden zijn vervangen door systeemwaarden. |
| POST-002 | Users.IsActive is false. |
| POST-003 | Afhankelijke toegang is beëindigd, overgedragen of geblokkeerd volgens domeinregels. |
| POST-004 | Historische data blijft beschikbaar zonder actuele persoonsgegevens van het geanonimiseerde account. |
| POST-005 | Oude en nieuwe identiteit plus reden zijn afgeschermd accountlogmatig vastgelegd. |
| POST-006 | Identity-providercredentials zijn niet gewijzigd. |
6. Trigger
De usecase start wanneer de beheerder in accountdetail de actie Account anonimiseren kiest en de zware bevestigingsflow start.
7. Normale processtroom
| Stap | Actor | Component / context | Actie | Resultaat | Data / controle |
|---|---|---|---|---|---|
| 1 | Beheerder | Accountdetail | Kiest Account anonimiseren. | De frontend opent de zware bevestigingsflow. | Users.Id. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag anonimiseren. | Server-side controle. |
| 3 | Backend | AccountService | Laadt doelaccount en actuele identiteit. | Persoonsvelden en status worden vastgesteld. | Users. |
| 4 | Backend | DependencyService | Bepaalt afhankelijkheden. | Rollen, relaties, docentniveau-eigenaarschap, tickets en actieve contexten worden geanalyseerd. | Domeinrecords. |
| 5 | Backend | DependencyService | Controleert opvolgscenario voor docentniveau-eigendom. | Onbeheerde actieve onderwijscontext wordt voorkomen. | TeacherLevels, collaborators. |
| 6 | Frontend | Popupcomponent | Toont zware bevestiging en vraagt reden. | Reden is verplicht. | POP-BEH-ACC-ANONYMIZE-CONFIRM. |
| 7 | Beheerder | Popupcomponent | Bevestigt met reden. | De backend ontvangt definitieve opdracht. | Bevestiging. |
| 8 | Backend | AccountService | Vervangt zichtbare identiteit door systeemwaarden. | Account is niet-persoonsherleidbaar in normale UI. | Users. |
| 9 | Backend | AccountService | Zet account inactief en ruimt afhankelijke toegang op. | Reguliere toegang en afhankelijke autorisaties eindigen. | Users, UserRoles, UserRelationships, autorisaties. |
| 10 | Backend | Accountlog | Legt oude en nieuwe identiteit afgeschermd vast. | Audit is beschikbaar voor bevoegde technische beheercontext. | Accountlogkanaal. |
| 11 | Frontend | Accountdetail | Toont geanonimiseerde accountstatus. | Persoonsgerichte acties zijn niet langer beschikbaar. | Geanonimiseerd account. |
8. Alternatieve en exceptionele processtromen
| Stap | Situatie | Afhandeling | PopupKey | Datagevolg |
|---|---|---|---|---|
| 2 | Actor is geen beheerder. | De actie wordt geweigerd. | Niet van toepassing. | Geen. |
| 3 | Account is al geanonimiseerd. | De actie wordt geblokkeerd. | Niet van toepassing. | Geen. |
| 4 | Afhankelijkheden kunnen niet betrouwbaar worden bepaald. | Anonimisering wordt geblokkeerd totdat afhankelijkheden duidelijk zijn. | Niet van toepassing. | Geen. |
| 5 | Docent is eigenaar van niveau zonder geldig opvolgscenario. | Anonimisering wordt geblokkeerd of vereist eerst eigendomsoverdracht/inactiefscenario. | Niet van toepassing. | Geen. |
| 6 | Reden ontbreekt. | Bevestigen blijft onmogelijk. | POP-BEH-ACC-ANONYMIZE-CONFIRM. | Geen. |
| 7 | Beheerder annuleert. | Er wordt niets opgeslagen. | POP-BEH-ACC-ANONYMIZE-CONFIRM. | Geen. |
| 9 | Deelcleanup faalt binnen transactie. | De transactie rolt terug; er blijft geen half-geanonimiseerde accounttoestand achter. | Niet van toepassing. | Geen blijvende mutatie. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Anonimisering is een definitieve interne OefenHub-lifecycleactie. |
| BR-002 | Persoonsvelden worden vervangen door niet-persoonsherleidbare systeemwaarden. |
| BR-003 | De waarde # is gereserveerd en wordt alleen systeemmatig als tussenvoegsel gebruikt. |
| BR-004 | Een geanonimiseerd account is niet heractiveerbaar naar een persoonsaccount via accountbeheer. |
| BR-005 | Afhankelijke toegang wordt beëindigd, overgedragen of niet langer autoriserend gemaakt. |
| BR-006 | Historische tickets, berichten, runs en auditdata blijven bestaan zonder actuele persoonsgegevens te tonen. |
| BR-007 | Identity-providercredentials worden niet door OefenHub-accountbeheer gewijzigd. |
| BR-008 | Oude en nieuwe identiteit worden afgeschermd accountlogmatig vastgelegd. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | Doelaccount moet bestaan en nog niet geanonimiseerd zijn. |
| VAL-002 | Reden is verplicht. |
| VAL-003 | Anonieme code moet niet-voorspelbaar en uniek genoeg zijn voor e-mailadres en achternaam. |
| VAL-004 | Anoniem e-mailadres moet voldoen aan e-mailvalidatie en uniek zijn binnen Users.Email. |
| VAL-005 | Docentniveau-eigenaarschap moet vóór uitvoering een geldig opvolgscenario hebben. |
| VAL-006 | De hele anonimiseer- en cleanupflow moet transactioneel of compenseerbaar zijn. |
| VAL-007 | Client mag geen anonieme waarden aanleveren; de backend genereert deze. |
11. Datamutaties en events
| Onderdeel | Mutatie / event |
|---|---|
| Users | FirstName, MiddleName, LastName, Email, DisplayName, IsActive en UpdatedAtUtc worden systeemmatig bijgewerkt. |
| UserRoles | Actieve rollen worden beëindigd of niet langer autoriserend gemaakt volgens lifecyclebeleid. |
| UserRelationships en RelationshipInvitations | Actieve relaties worden administratief beëindigd en open uitnodigingen niet langer accepteerbaar gemaakt waar van toepassing. |
| Docentstructuur en autorisaties | Afhankelijke toegang wordt beëindigd of eigenaarschap wordt volgens geldige flow overgedragen. |
| LiveViewAudit | Open live-meekijkrecords krijgen waar nodig een eindmoment. |
| Accountlogkanaal | Oude en nieuwe identiteit, actor, reden en tijdstip worden afgeschermd vastgelegd. |
12. Geen datamutaties
| Object / gegeven | Niet wijzigen |
|---|---|
| Identity provider | Geen rechtstreekse wijziging van extern account of credentials. |
| ExerciseRuns | Historische runs blijven bestaan en worden niet hard verwijderd. |
| Tickets en TicketHistory | Meldingen blijven voor beheeranalyse beschikbaar zonder actuele persoonsgegevens. |
| PrivateMessageThreads en SystemMessages | Historische context blijft volgens zichtbaarheid en retentie bestaan. |
| ProfileAvatars | Avatarrecords zelf wijzigen niet. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
| PopupKey | Gebruik |
|---|---|
| POP-BEH-ACC-ANONYMIZE-CONFIRM | Zware bevestiging met verplichte reden voor anonimisering. |
Popupinhoud, knopteksten, themakeuzes en eventuele inputlabels blijven bronhoudend in het centrale popupregister en popup-themes.
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Accountbeheer ondersteunt beheerdergestuurde anonimisering naast selfservice-accountverwijdering. |
| Technisch Ontwerp | Technisch Ontwerp: identiteit en accountlifecycle, autorisatie, logging en foutafhandeling en privacy en anonimisering beschrijven de technische uitwerking. Anonimisering vervangt persoonsvelden, beëindigt toegang en logt oude/nieuwe identiteit afgeschermd. |
| Software Requirements Specification | SRS moet definitieve aard, reasonplicht, afhankelijkheden en identity-providerafbakening vastleggen. |
| Database | Wijzigt Users en afhankelijke autoriserende records; historische domeindata blijft bestaan. |
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 |
|---|---|---|
UC-BEH-ACC-007-REQ-001 | SRS-ACC-002 SRS-ACC-004 SRS-ADM-002 SRS-ADM-003 SRS-ADM-001 SRS-NFR-PRV-001 AC-ACC-002 AC-ACC-004 AC-ADM-002 AC-ADM-003 AC-ADM-001 AC-NFR-PRV-001 | Een beheerder een account kunnen laten anonimiseren via een zware bevestigingsflow |
UC-BEH-ACC-007-REQ-002 | SRS-ADM-003 SRS-ADM-001 SRS-NFR-PRV-001 AC-ADM-003 AC-ADM-001 AC-NFR-PRV-001 | Voor anonimisering een reden verplicht stellen |
UC-BEH-ACC-007-REQ-003 | SRS-ADM-001 SRS-NFR-PRV-001 AC-ADM-001 AC-NFR-PRV-001 | Zichtbare persoonsgegevens vervangen door systeemwaarden |
UC-BEH-ACC-007-REQ-004 | SRS-ADM-003 SRS-ADM-001 SRS-NFR-PRV-001 AC-ADM-003 AC-ADM-001 AC-NFR-PRV-001 | Users.IsActive op false zetten bij anonimisering |
UC-BEH-ACC-007-REQ-005 | SRS-AUTH-001 SRS-ADM-001 AC-AUTH-001 AC-ADM-001 | Afhankelijke toegang beëindigen, overdragen of blokkeren volgens domeinregels |
UC-BEH-ACC-007-REQ-006 | SRS-ADM-001 SRS-NFR-PRV-001 AC-ADM-001 AC-NFR-PRV-001 | Historische domeindata bewaren zonder actuele persoonsgegevens te tonen |
UC-BEH-ACC-007-REQ-007 | SRS-ACC-002 SRS-ADM-002 SRS-ADM-001 SRS-NFR-AUD-001 AC-ACC-002 AC-ADM-002 AC-ADM-001 AC-NFR-AUD-001 | Oude en nieuwe identiteit afgeschermd accountlogmatig vastleggen |
UC-BEH-ACC-007-REQ-008 | SRS-ACC-002 SRS-ADM-002 SRS-ADM-001 AC-ACC-002 AC-ADM-002 AC-ADM-001 | Geen identity-provideraccount rechtstreeks wijzigen |