UC-BEH-ACC-006 — Account heractiveren
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-ACC-006 |
| Naam | Account heractiveren |
| 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-007, 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-REACTIVATE-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De usecase beschrijft hoe een beheerder een eerder gedeactiveerd OefenHub-account heractiveert. Heractiveren zet Users.IsActive weer op true, maar herstelt geen account dat al geanonimiseerd is.
De actie vereist een expliciete reden, omdat hiermee toegang opnieuw mogelijk wordt gemaakt voor een bestaand intern account. De identity provider blijft bronhouder voor daadwerkelijke loginmogelijkheid; OefenHub herstelt alleen de interne applicatietoegang.
Heractiveren voert geen automatische heropbouw uit van relaties, open uitnodigingen of ingetrokken autorisaties. Historische data blijft beschikbaar volgens de normale regels, maar beëindigde afhankelijkheden worden niet impliciet gereactiveerd.
Uitgangspunten
- Alleen tijdelijk gedeactiveerde accounts zijn heractiveerbaar.
- Geanonimiseerde accounts zijn niet heractiveerbaar als persoonsaccount.
- Een reden is verplicht.
- UserRoles blijven zoals ze administratief geregistreerd staan.
- Identity-providerstatus kan nog steeds login verhinderen buiten OefenHub.
3. Scope
Deze usecase beschrijft:
- Heractiveren van één gedeactiveerd intern account.
- Vastleggen van reden in accountlogkanaal.
- Opnieuw toestaan van OefenHub-applicatiecontext na geldige identity-providerlogin.
- Blokkeren van heractivatie voor geanonimiseerde accounts.
- Tonen van waarschuwingen over niet-automatisch herstelde afhankelijkheden.
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.
- Geanonimiseerd account de-anonimiseren.
- Identity-provideraccount herstellen.
- Verbroken relaties, ingetrokken niveauautorisaties of beëindigde collaboratorrechten automatisch herstellen.
- Wachtwoord resetten of e-mailadres verifiëren.
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 bestaat en heeft Users.IsActive = false. |
| PRE-008 | Het account is niet geanonimiseerd. |
| PRE-009 | De actuele rolset en afhankelijkheden zijn geladen. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | Users.IsActive van het doelaccount is true. |
| POST-002 | De reden en actor zijn accountlogmatig vastgelegd. |
| POST-003 | Het account kan bij geldige identity-providerlogin weer een OefenHub-context krijgen. |
| POST-004 | Eerder beëindigde relaties of autorisaties zijn niet automatisch hersteld. |
| POST-005 | Identity-providercredentials zijn ongewijzigd. |
6. Trigger
De usecase start wanneer de beheerder in accountdetail de actie Account heractiveren kiest.
7. Normale processtroom
| Stap | Actor | Component / context | Actie | Resultaat | Data / controle |
|---|---|---|---|---|---|
| 1 | Beheerder | Accountdetail | Kiest Account heractiveren. | De frontend opent de bevestigingsflow. | Users.Id. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag heractiveren. | Server-side controle. |
| 3 | Backend | AccountService | Laadt doelaccount. | Gedeactiveerde status wordt vastgesteld. | Users.IsActive = false. |
| 4 | Backend | AccountService | Controleert of account geanonimiseerd is. | Geanonimiseerde accounts worden uitgesloten. | Anonieme naam/e-mailpatronen en logstatus. |
| 5 | Frontend | Popupcomponent | Vraagt bevestiging en reden. | Reden is verplicht. | POP-BEH-ACC-REACTIVATE-CONFIRM. |
| 6 | Beheerder | Popupcomponent | Bevestigt met reden. | De backend ontvangt reden. | Bevestiging. |
| 7 | Backend | AccountService | Zet Users.IsActive op true. | Interne applicatietoegang is weer mogelijk. | Users. |
| 8 | Backend | Accountlog | Legt heractivatie vast. | Actor, doelaccount, reden en statuswijziging zijn auditbaar. | Accountlogkanaal. |
| 9 | Frontend | Accountdetail | Toont actieve status. | Vervolgacties worden opnieuw afgeleid. | Nieuwe status. |
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 actief. | Heractiveren wordt niet opnieuw uitgevoerd; detail wordt vernieuwd. | Niet van toepassing. | Geen. |
| 4 | Account is geanonimiseerd. | Heractivatie wordt geblokkeerd. | Niet van toepassing. | Geen. |
| 5 | Reden ontbreekt. | Bevestigen blijft onmogelijk. | POP-BEH-ACC-REACTIVATE-CONFIRM. | Geen. |
| 6 | Beheerder annuleert. | Er wordt niets opgeslagen. | POP-BEH-ACC-REACTIVATE-CONFIRM. | Geen. |
| 7 | Identity provider weigert na heractivatie alsnog externe login. | OefenHub toont bij login de normale externe-authenticatieafhandeling; OefenHub herstelt dit niet. | Niet van toepassing. | Users.IsActive blijft true. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Alleen gedeactiveerde, niet-geanonimiseerde accounts zijn heractiveerbaar. |
| BR-002 | Heractivatie zet Users.IsActive op true. |
| BR-003 | Heractivatie vereist een reden. |
| BR-004 | Heractivatie herstelt geen externe identity-providerstatus. |
| BR-005 | Heractivatie herstelt geen eerder beëindigde relaties of autorisaties. |
| BR-006 | UserRoles blijven zoals administratief geregistreerd; ontbrekende rollen worden niet automatisch toegevoegd. |
| BR-007 | De heractivatie wordt accountlogmatig vastgelegd. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | Doelaccount moet bestaan. |
| VAL-002 | Users.IsActive moet false zijn. |
| VAL-003 | Account mag niet geanonimiseerd zijn. |
| VAL-004 | Reden is verplicht. |
| VAL-005 | Actor moet beheerder zijn op moment van opslaan. |
| VAL-006 | Concurrente statuswijziging wordt vlak voor opslaan opnieuw gecontroleerd. |
11. Datamutaties en events
| Onderdeel | Mutatie / event |
|---|---|
| Users | IsActive wordt true en UpdatedAtUtc wordt bijgewerkt. |
| Accountlogkanaal | Heractivatie wordt met reden vastgelegd. |
12. Geen datamutaties
| Object / gegeven | Niet wijzigen |
|---|---|
| Identity provider | Geen credential- of accountstatuswijziging. |
| UserRoles | Geen roltoekenningen toevoegen of herstellen. |
| Relaties en autorisaties | Geen beëindigde afhankelijkheden heractiveren. |
| UserSettings | Instellingen blijven ongewijzigd. |
| ExerciseRuns en berichten | Historische data blijft ongewijzigd. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
| PopupKey | Gebruik |
|---|---|
| POP-BEH-ACC-REACTIVATE-CONFIRM | Bevestiging met verplichte reden voor heractiveren. |
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 | Beheerder kan tijdelijk uitgeschakelde accounts heractiveren. |
| Technisch Ontwerp | Technisch Ontwerp: identiteit en accountlifecycle, autorisatie, logging en foutafhandeling en privacy en anonimisering beschrijven de technische uitwerking. Heractivatie wijzigt Users.IsActive en logt de actie, zonder identity-provideraanpassing. |
| Software Requirements Specification | SRS moet blokkade voor geanonimiseerde accounts en geen automatisch herstel van afhankelijkheden vastleggen. |
| Database | Wijzigt Users.IsActive; schrijft accountlog. |
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-006-REQ-001 | SRS-ACC-002 SRS-ADM-002 SRS-ADM-001 AC-ACC-002 AC-ADM-002 AC-ADM-001 | Een beheerder een gedeactiveerd account kunnen laten heractiveren |
UC-BEH-ACC-006-REQ-002 | SRS-AUTH-001 SRS-ACC-002 SRS-ACC-004 SRS-ACC-008 SRS-ADM-002 SRS-ADM-003 AC-AUTH-001 AC-ACC-002 AC-ACC-004 AC-ACC-008 AC-ADM-002 AC-ADM-003 | Heractivatie blokkeren voor geanonimiseerde accounts |
UC-BEH-ACC-006-REQ-003 | SRS-ADM-001 AC-ADM-001 | Voor heractivatie een reden verplicht stellen |
UC-BEH-ACC-006-REQ-004 | SRS-ADM-001 AC-ADM-001 | Users.IsActive op true zetten bij heractivatie |
UC-BEH-ACC-006-REQ-005 | SRS-ADM-001 SRS-NFR-SEC-001 SRS-NFR-PRV-001 SRS-ARCH-002 AC-ADM-001 AC-NFR-SEC-001 AC-NFR-PRV-001 AC-ARCH-002 | Bij heractivatie geen identity-providercredentials wijzigen |
UC-BEH-ACC-006-REQ-006 | SRS-AUTH-001 SRS-REL-001 SRS-ADM-001 AC-AUTH-001 AC-REL-001 AC-ADM-001 | Relaties en autorisaties niet automatisch herstellen |
UC-BEH-ACC-006-REQ-007 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | Heractivatie auditbaar loggen |