UC-BEH-ACC-002 — Accountdetail openen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-ACC-002 |
| Naam | Accountdetail openen |
| 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 |
| Gerelateerde usecases | UC-BEH-ACC-001, UC-BEH-ACC-003, UC-BEH-ACC-004, UC-BEH-ACC-005, UC-BEH-ACC-006, 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 | Niet van toepassing |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De usecase beschrijft hoe een beheerder de detailweergave van één account opent. Accountdetail brengt profielsamenvatting, rollen, actieve status, instellingenoverzicht, lifecycle-informatie en relevante afhankelijkheden samen zonder directe mutatie te veroorzaken.
De detailpagina is het startpunt voor vervolgacties zoals rollen beheren, deactiveren, heractiveren, anonimiseren en instellingen corrigeren. Elke vervolgactie voert opnieuw een server-side autorisatie- en validatiecontrole uit.
De detailweergave toont voldoende context om zware acties verantwoord te nemen, maar blijft gescheiden van identity-providerbeheer en van normale gebruikersprofielselfservice.
Uitgangspunten
- Accountdetail wordt altijd geopend met een server-side gevalideerde Users.Id.
- De beheerder ziet alleen OefenHub-domeingegevens en geen credentials.
- Afhankelijkheden zoals actieve rollen, docentniveau-eigenaarschap en open meldingen worden als samenvatting of waarschuwing getoond.
- Zware acties vereisen een aparte bevestigingsflow met reden waar relevant.
- De detailpagina voert zelf geen mutatie uit.
3. Scope
Deze usecase beschrijft:
- Openen van accountdetail voor één account.
- Tonen van profiel- en identiteitssamenvatting uit Users.
- Tonen van actieve en historische rolcontext.
- Tonen van accountstatus en mogelijke vervolgacties.
- Tonen van afhankelijkheden die relevant zijn voor lifecycle-acties.
- Doorverwijzen naar rolbeheer, statusbeheer, instellingenbeheer en lifecyclelog.
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.
- De geselecteerde vervolgactie uitvoeren; dit hoort bij de specifieke vervolgusecase.
- Volledige relatie-, berichten-, meldingen- of docentstructuurhistorie uitwerken.
- Credentialstatus van de identity provider tonen.
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 vanuit het accountoverzicht precies één account geselecteerd. |
| PRE-007 | De geselecteerde Users.Id bestaat op het moment van openen. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | De beheerder ziet accountdetail voor precies één account. |
| POST-002 | Geen accountdata is gewijzigd. |
| POST-003 | Beschikbare vervolgacties zijn afgeleid uit actuele status, rollen en afhankelijkheden. |
| POST-004 | Niet-toegestane acties zijn verborgen of uitgeschakeld met veilige toelichting. |
| POST-005 | Credentialinformatie is niet getoond. |
6. Trigger
De usecase start wanneer de beheerder vanuit het accountoverzicht de actie Open detail kiest.
7. Normale processtroom
| Stap | Actor | Component / context | Actie | Resultaat | Data / controle |
|---|---|---|---|---|---|
| 1 | Beheerder | Accountoverzicht | Kiest Open detail voor één account. | De frontend opent de detailroute. | Users.Id. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag accountdetail raadplegen. | Server-side autorisatie. |
| 3 | Backend | AccountService | Laadt Users-record. | Profiel- en statusgegevens worden opgehaald. | Users. |
| 4 | Backend | RoleService | Laadt actieve en relevante historische rollen. | Rollen en rolmutaties worden samengevat. | UserRoles, Roles. |
| 5 | Backend | DependencyService | Bepaalt lifecycle-afhankelijkheden. | Waarschuwingen voor eigenaarschap, actieve relaties of open context worden getoond. | Docentstructuur, relaties, tickets. |
| 6 | Backend | SettingsService | Laadt compacte UserSettings-samenvatting. | Instelbare beheerdercorrecties worden herkenbaar gemaakt. | UserSettings. |
| 7 | Frontend | Accountdetail | Toont detailtabs en vervolgacties. | De beheerder kiest eventueel een vervolgactie. | Read-only detailweergave. |
8. Alternatieve en exceptionele processtromen
| Stap | Situatie | Afhandeling | PopupKey | Datagevolg |
|---|---|---|---|---|
| 2 | Gebruiker is geen beheerder. | De backend weigert detailtoegang. | Niet van toepassing. | Geen. |
| 3 | Account bestaat niet of is hard technisch verwijderd buiten normale flow. | De detailpagina toont niet-beschikbaarafhandeling en verwijst terug naar overzicht. | Niet van toepassing. | Geen. |
| 3 | Account is geanonimiseerd. | Detail toont geanonimiseerde identiteit en beperkt persoonsgerichte acties. | Niet van toepassing. | Geen. |
| 5 | Afhankelijkheden kunnen gedeeltelijk niet worden bepaald. | Zware lifecycle-acties worden niet aangeboden totdat afhankelijkheden betrouwbaar zijn vastgesteld. | Niet van toepassing. | Geen. |
| 7 | Account is het eigen beheerderaccount. | Risicovolle acties zoals eigen beheerderrol intrekken of eigen account deactiveren worden apart geblokkeerd of vereisen expliciete systeemregel. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Accountdetail is read-only totdat een specifieke vervolgactie wordt gestart. |
| BR-002 | De detailpagina toont geen identity-providercredentials. |
| BR-003 | Elke vervolgactie voert opnieuw autorisatie en validatie uit. |
| BR-004 | Afhankelijkheden moeten zichtbaar zijn voordat de beheerder een zware lifecycleactie kan kiezen. |
| BR-005 | Geanonimiseerde accounts tonen geen persoonsgegevens. |
| BR-006 | Niet-publieke rollen moeten zichtbaar zijn als beheerrollen. |
| BR-007 | Eigen accountbeheer door een beheerder mag niet leiden tot lock-out van het laatste beheerdersaccount. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | Users.Id is verplicht en moet bestaan. |
| VAL-002 | De backend moet controleren dat de actor beheerder is op het moment van lezen. |
| VAL-003 | Historische rolgegevens mogen alleen uit UserRoles worden afgeleid. |
| VAL-004 | Actiebeschikbaarheid mag niet door de client worden bepaald. |
| VAL-005 | Afhankelijkheidssamenvattingen mogen geen persoonsgegevens van andere gebruikers onnodig tonen. |
| VAL-006 | Geanonimiseerde identiteit moet als zodanig worden herkend. |
11. Datamutaties en events
| Onderdeel | Mutatie / event |
|---|---|
| Geen domeinmutatie | Accountdetail openen wijzigt geen data. |
| Geen lifecycle-event | Louter lezen schrijft geen accountlogregel of domeinevent. |
12. Geen datamutaties
| Object / gegeven | Niet wijzigen |
|---|---|
| Users | Geen status- of profielwijziging. |
| UserRoles | Geen rolmutatie. |
| UserSettings | Geen instellingwijziging. |
| Identity provider | Geen credential- of sessiewijziging. |
| Relaties, tickets en docentstructuur | Alleen samenvattend raadplegen. |
13. State diagram
Niet van toepassing. Deze usecase wijzigt geen persistente domeinstatus. De weergegeven toestand is een read-only scherm- of readmodeltoestand en wordt daarom niet als statusmodel opgenomen.
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Niet van toepassing
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Accountdetail is de beheerderweergave voor één account en startpunt voor vervolgacties. |
| Technisch Ontwerp | Technisch Ontwerp: identiteit en accountlifecycle, autorisatie, logging en foutafhandeling en privacy en anonimisering beschrijven de technische uitwerking. Detailreadmodel combineert Users, UserRoles, UserSettings en afhankelijkheidssamenvattingen. |
| Software Requirements Specification | SRS moet vastleggen dat detail openen geen mutatie is en dat vervolgacties herautoriseren. |
| Database | Leest account-, rol-, instellingen- en afhankelijkheidsdata zonder wijziging. |
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-002-REQ-001 | SRS-AUTH-004 SRS-ACC-002 SRS-ADM-002 SRS-ADM-001 AC-AUTH-004 AC-ACC-002 AC-ADM-002 AC-ADM-001 | Accountdetail voor één geselecteerd account kunnen tonen |
UC-BEH-ACC-002-REQ-002 | SRS-AUTH-001 SRS-ACC-002 SRS-ADM-002 SRS-ADM-001 AC-AUTH-001 AC-ACC-002 AC-ADM-002 AC-ADM-001 | Accountdetail server-side autoriseren |
UC-BEH-ACC-002-REQ-003 | SRS-ADM-002 SRS-ADM-001 AC-ADM-002 AC-ADM-001 | Rollen, status, instellingen en lifecycle-afhankelijkheden tonen |
UC-BEH-ACC-002-REQ-004 | SRS-RDM-001 SRS-ADM-001 AC-RDM-001 AC-ADM-001 | Vervolgacties afleiden uit actuele serverdata |
UC-BEH-ACC-002-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 | Geen identity-providercredentials tonen |
UC-BEH-ACC-002-REQ-006 | SRS-ACC-002 SRS-ACC-004 SRS-ACC-008 SRS-ADM-002 SRS-ADM-003 SRS-ADM-001 AC-ACC-002 AC-ACC-004 AC-ACC-008 AC-ADM-002 AC-ADM-003 AC-ADM-001 | Geanonimiseerde accounts zonder persoonsgegevens tonen |
UC-BEH-ACC-002-REQ-007 | SRS-AUTH-001 SRS-ADM-001 AC-AUTH-001 AC-ADM-001 | Risicovolle acties blokkeren wanneer afhankelijkheden niet betrouwbaar bepaald zijn |