Skip to main content

UC-BEH-ACC-009 — Gebruikersinstelling als beheerder wijzigen

1. Kerngegevens

VeldWaarde
Usecase-IDUC-BEH-ACC-009
NaamGebruikersinstelling als beheerder wijzigen
DomeinBeheerder / Accountbeheer
Primaire actorBeheerder
Secundaire actor(en)Frontend, backend, database, autorisatiecomponent, identity-providerkoppeling, accountlogkanaal
RolcontextActieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker
Betrokken schermenAccounts beheren > Accountdetail > Instellingen
Gerelateerde usecasesUC-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-007, UC-BEH-ACC-008, UC-BEH-ACC-010, UC-GEN-ACC-001, UC-GEN-ACC-002, UC-GEN-ACC-005
Primaire entiteitenUsers, Roles, UserRoles, UserSettings, ProfileAvatars, accountlogkanaal
Secundaire entiteiten / eventsUserRelationships, RelationshipInvitations, TeacherLevels, TeacherLevelAuthorizations, LevelCollaborators, ExerciseRuns, LiveViewAudit, SystemMessages, PrivateMessageThreads, Tickets
Gerelateerde popupsPOP-BEH-ACC-SETTING-CHANGE-CONFIRM
PopupregisterOntwerpbronnen — Popup-register
MoSCoWMust

2. Omschrijving

De usecase beschrijft hoe een beheerder een gebruikersinstelling corrigeert of wijzigt vanuit accountbeheer. Het gaat om UserSettings-waarden die functioneel in OefenHub thuishoren, waaronder verborgen voorkeuren zoals DontWarnAgainOnDunno en toegankelijkheidsinstellingen.

Deze beheerroute is geen vervanging van normale profiel- of voorkeurenflows. De beheerder gebruikt de route voor support, correctie of beheeranalyse en de wijziging wordt auditbaar vastgelegd.

Gebruikersinstellingen wijzigen presentatiegedrag of gebruikersgedrag, maar nooit autorisaties, rollen, zichtbare gegevenssets, relaties of domeintoegang.

Uitgangspunten

  • UserSettings is bron van waarheid voor voorkeuren en toegankelijkheidsinstellingen na login.
  • Browserwaarden of cookies zijn afgeleid en geen tweede bron van waarheid.
  • De beheerder kan verborgen voorkeuren corrigeren waar FO/TO/SRS dit toestaat.
  • Instellingen hebben codegedreven type en bereik.
  • Een beheerderwijziging vereist bevestiging en reden.

3. Scope

Deze usecase beschrijft:

  • Openen van instellingenoverzicht voor één account.
  • Wijzigen van toegestane UserSettings-velden.
  • Valideren van datatype, bereik en rolcontext.
  • Vastleggen van actor, oude waarde, nieuwe waarde en reden.
  • Afleiden dat browserwaarden bij volgende synchronisatie opnieuw uit UserSettings volgen.
  • Blokkeren van instellingen die autorisatie of zichtbare dataset zouden wijzigen.

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.
  • E-mailadres, wachtwoord of credentialinstellingen wijzigen.
  • Rollen of autorisaties wijzigen via UserSettings.
  • Nieuwe instellingensleutels toevoegen.
  • Vrije JSON-instellingen opslaan zonder codegedreven definitie.
  • Browsercookie rechtstreeks beheren.

3.1 Afbakening met aangrenzende domeinen

OnderdeelAfbakening
Generiek / AccountLogin, provisioning, logout en selfservice-accountverwijdering blijven bronhoudend in het generieke accountdomein.
Generiek / Profiel en voorkeurenEigen profiel- en voorkeurenbeheer blijft gebruikergericht; accountbeheer bevat alleen beheerdercorrecties en uitzonderingsacties.
Generiek / RelatiesRelatie-uitnodigingen, acceptatie en normale ontkoppeling blijven in het relatiedomein; accountbeheer kan wel afhankelijke toegang beëindigen bij lifecycle-acties.
Beheerder / DocentondersteuningDocentstructuur, leerlingtoegang en collaborators worden daar supportmatig beheerd; accountbeheer ziet accountbrede identiteit, rollen en lifecycle.
Identity providerAuthenticatie, wachtwoorden, verificatie, tokens en credentials blijven buiten OefenHub-accountbeheer.

4. Pre-condities

IDVoorwaarde
PRE-001De gebruiker is succesvol ingelogd in OefenHub.
PRE-002De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft.
PRE-003De beheerder bevindt zich binnen Accounts beheren of een onderliggende accountbeheerroute.
PRE-004Clientstate, routeparameters of verborgen formuliervelden bepalen nooit welk account gewijzigd mag worden.
PRE-005De identity provider blijft bronhouder voor authenticatie, wachtwoorden, tokens, sessies en credential lifecycle.
PRE-006De beheerder heeft accountdetail geopend.
PRE-007Het doelaccount heeft een UserSettings-record of kan veilig met defaults worden geïnitialiseerd volgens bestaande accountregels.
PRE-008De te wijzigen instelling is beheerbaar en codegedreven gedefinieerd.
PRE-009De beheerder heeft een reden voor de wijziging.

5. Post-condities

IDResultaat
POST-001De toegestane UserSettings-waarde is gewijzigd.
POST-002UpdatedAtUtc is bijgewerkt.
POST-003Oude en nieuwe waarde, actor en reden zijn auditbaar vastgelegd.
POST-004Geen rol, autorisatie of relatie is gewijzigd.
POST-005Eventuele browserwaarde wordt bij volgende normale synchronisatie opnieuw afgeleid.

6. Trigger

De usecase start wanneer de beheerder in accountdetail een beheerbare gebruikersinstelling wijzigt.

7. Normale processtroom

StapActorComponent / contextActieResultaatData / controle
1BeheerderAccountdetailOpent tab Instellingen.De frontend laadt UserSettings.Users.Id.
2BackendAutorisatiecomponentControleert beheerdercontext.Alleen beheerder mag instellingen wijzigen.Server-side controle.
3BackendSettingsServiceLaadt UserSettings en beheermetadata.Type, bereik en beheerbaarheid per veld worden bepaald.UserSettings en codeconfiguratie.
4BeheerderInstellingenpaneelWijzigt een toegestane instelling.De frontend vraagt validatie.Nieuwe waarde.
5BackendSettingsServiceValideert datatype, bereik en autorisatiegrens.Ongeldige wijzigingen worden geblokkeerd.Codegedreven definitie.
6FrontendPopupcomponentVraagt bevestiging en reden.Reden is verplicht.POP-BEH-ACC-SETTING-CHANGE-CONFIRM.
7BeheerderPopupcomponentBevestigt met reden.De backend ontvangt wijziging en reden.Bevestiging.
8BackendSettingsServiceSlaat UserSettings-wijziging op.Waarde en UpdatedAtUtc worden bijgewerkt.UserSettings.
9BackendAccountlogLegt wijziging vast.Oude waarde, nieuwe waarde, actor en reden zijn auditbaar.Accountlogkanaal.
10FrontendAccountdetailToont bijgewerkte instelling.De beheerder ziet de nieuwe waarde.Nieuwe settingswaarde.

8. Alternatieve en exceptionele processtromen

StapSituatieAfhandelingPopupKeyDatagevolg
2Actor is geen beheerder.De wijziging wordt geweigerd.Niet van toepassing.Geen.
3UserSettings ontbreekt.Het systeem initialiseert veilig met defaults wanneer het account verder geldig is, of blokkeert wanneer dat niet veilig kan.Niet van toepassing.Eventueel nieuw UserSettings-record volgens accountregels.
4Instelling is read-only of niet beheerbaar.De UI staat wijziging niet toe en de backend weigert alsnog.Niet van toepassing.Geen.
5Waarde buiten bereik of verkeerd type.De wijziging wordt geweigerd.Niet van toepassing.Geen.
6Reden ontbreekt.Bevestigen blijft onmogelijk.POP-BEH-ACC-SETTING-CHANGE-CONFIRM.Geen.
7Beheerder annuleert.Er wordt niets opgeslagen.POP-BEH-ACC-SETTING-CHANGE-CONFIRM.Geen.

9. Business rules

IDBusiness rule
BR-001UserSettings wijzigen mag geen rollen, autorisaties of zichtbare datasets wijzigen.
BR-002Browserwaarden voor toegankelijkheid zijn afgeleid van UserSettings en geen tweede bron van waarheid.
BR-003Beheerderwijziging van UserSettings vereist reden en audit.
BR-004Instellingstype en bereik zijn codegedreven; beheerders kiezen geen vrij type.
BR-005DontWarnAgainOnDunno mag als verborgen voorkeur door beheerder gecorrigeerd worden wanneer functioneel toegestaan.
BR-006Sitebrede uitschakeling van toegankelijkheid verwijdert individuele gebruikerswaarden niet.
BR-007Nieuwe instellingensleutels ontstaan niet via accountbeheer.

10. Datavalidatie

IDValidatie
VAL-001Users.Id moet bestaan.
VAL-002UserSettings.UserId moet naar het doelaccount verwijzen.
VAL-003Instelling moet op beheerbaar staan in codegedreven definitie.
VAL-004Nieuwe waarde moet passen bij datatype en toegestaan bereik.
VAL-005Reden is verplicht.
VAL-006Client mag geen veldnaam buiten de toegestane set injecteren.
VAL-007Concurrente wijziging wordt vlak voor opslaan opnieuw gevalideerd.

11. Datamutaties en events

OnderdeelMutatie / event
UserSettingsToegestane instellingwaarde en UpdatedAtUtc worden bijgewerkt.
AccountlogkanaalOude waarde, nieuwe waarde, actor en reden worden vastgelegd.
UserSettings initialisatie bij ontbrekenAlleen wanneer UserSettings ontbreken bij een geldig account en veilige defaults toegestaan zijn.

12. Geen datamutaties

Object / gegevenNiet wijzigen
UsersGeen profiel-, status- of identiteitswijziging.
UserRolesGeen rolmutatie.
Relaties en autorisatiesGeen domeintoegang wijzigen.
Identity providerGeen credential- of profielgegeven wijzigen.
BrowsercookieNiet rechtstreeks wijzigen vanuit beheer; synchronisatie volgt normale applicatiestroom.

13. State diagram

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

17. Popupverwijzingen

PopupKeyGebruik
POP-BEH-ACC-SETTING-CHANGE-CONFIRMBevestiging met verplichte reden voor beheerderwijziging van gebruikersinstelling.

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

DocumentAfleiding
Functioneel OntwerpBeheerder mag bepaalde gebruikersinstellingen en verborgen voorkeuren corrigeren.
Technisch OntwerpTechnisch Ontwerp: identiteit en accountlifecycle, autorisatie, logging en foutafhandeling en privacy en anonimisering beschrijven de technische uitwerking. SettingsService gebruikt codegedreven definities voor type, bereik en beheerbaarheid.
Software Requirements SpecificationSRS moet vastleggen welke instellingen beheerbaar zijn en dat zij geen autorisatie mogen wijzigen.
DatabaseWijzigt UserSettings en schrijft accountlog; browserwaarden blijven afgeleid.

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-afleidingDektUsecasecontext
UC-BEH-ACC-009-REQ-001SRS-ADM-001
AC-ADM-001
Een beheerder toegestane UserSettings-velden kunnen laten wijzigen
UC-BEH-ACC-009-REQ-002SRS-ADM-001
AC-ADM-001
Instellingstype en bereik codegedreven valideren
UC-BEH-ACC-009-REQ-003SRS-ADM-001
SRS-NFR-AUD-001
AC-ADM-001
AC-NFR-AUD-001
Beheerderwijzigingen van instellingen met reden vastleggen
UC-BEH-ACC-009-REQ-004SRS-AUTH-001
SRS-ADM-002
SRS-ADM-001
AC-AUTH-001
AC-ADM-002
AC-ADM-001
UserSettings-wijzigingen geen rollen of autorisaties laten wijzigen
UC-BEH-ACC-009-REQ-005SRS-ADM-001
SRS-NFR-SEC-001
AC-ADM-001
AC-NFR-SEC-001
Ontbrekende UserSettings veilig kunnen initialiseren wanneer toegestaan
UC-BEH-ACC-009-REQ-006SRS-RDM-001
SRS-ADM-001
AC-RDM-001
AC-ADM-001
Browserwaarden als afgeleid behandelen
UC-BEH-ACC-009-REQ-007SRS-ACC-002
SRS-ADM-002
SRS-ADM-001
AC-ACC-002
AC-ADM-002
AC-ADM-001
Geen nieuwe instellingensleutels via accountbeheer laten aanmaken