UC-BEH-FEAT-002 — Featuretoggle wijzigen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-FEAT-002 |
| Naam | Featuretoggle wijzigen |
| Domein | Beheerder / Features en systeemnotificaties |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, beheerlogcomponent |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Site Instellingen > Features > tab Features |
| Gerelateerde usecases | UC-BEH-FEAT-001, UC-BEH-SET-004 |
| Primaire entiteiten | SiteFeatureToggles, SiteFeatureToggleHistory, Users |
| Secundaire entiteiten / events | FeatureToggleChanged, FeatureToggleChangeRejected |
| Gerelateerde popups | POP-BEH-FEAT-TOGGLE-CONFIRM, POP-BEH-FEAT-TOGGLE-SAVED, POP-BEH-FEAT-TOGGLE-FAILED |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft het wijzigen van een bestaande sitebrede featuretoggle. De beheerder wijzigt uitsluitend de booleaanse status van een vooraf bekende FeatureKey.
De mutatie werkt SiteFeatureToggles bij en legt de oude en nieuwe waarde vast in SiteFeatureToggleHistory. De wijziging is direct functioneel relevant voor onderliggende domeinflows, maar die flows blijven verantwoordelijk voor eigen server-side controles.
Voorbeelden zijn het uitschakelen van nieuwe registraties, nieuwe privéberichtacties, live meekijken, oefeningdelen, test-oefeningen, meldingen indienen en toegankelijkheidsbediening.
Uitgangspunten
- Alleen bestaande en bekende featurekeys zijn wijzigbaar.
- Een wijziging is sitebreed en geldt niet alleen voor de huidige sessie.
- De beheerder bevestigt de wijziging expliciet.
- Domeindata blijft bestaan wanneer een feature wordt uitgezet.
3. Scope
Deze usecase beschrijft:
- Wijzigen van IsEnabled voor een bestaande SiteFeatureToggle.
- Vastleggen van actor, tijdstip, oude waarde en nieuwe waarde.
- Tonen van bevestiging en resultaat.
- Voorkomen van vrije sleutelwijziging of nieuwe featureaanmaak.
- Direct beschikbaar maken van de nieuwe status voor server-side featurecontroles.
Deze usecase beschrijft niet:
- Nieuwe featurekeys toevoegen.
- Domeinspecifieke gevolgen zoals privéberichten verwijderen of meldingen sluiten.
- Niet-booleaanse instellingen wijzigen.
- Toegankelijkheidsinstellingen van individuele gebruikers aanpassen.
3.1 Afbakening met aangrenzende usecases
| Onderdeel | Afbakening |
|---|---|
| UC-BEH-FEAT-001 | Levert het overzicht waaruit de beheerder een toggle kiest. |
| UC-BEH-SET-004 | Beschrijft specifiek gedrag van AccessibilityEnabled. |
| Onderliggende domeinen | Respecteren de status bij hun eigen acties, maar wijzigen de feature niet. |
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 Site Instellingen-route is beschikbaar via de beheerdernavigatie. |
| PRE-004 | Clientstate, querystringwaarden of zichtbare UI-elementen bepalen niet zelfstandig de autorisatie. |
| PRE-005 | De gekozen FeatureKey bestaat en is beheerbaar. |
| PRE-006 | De gewenste nieuwe waarde verschilt van de actuele waarde of wordt als geen-wijziging afgehandeld. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | SiteFeatureToggles.IsEnabled is bijgewerkt wanneer de mutatie geldig is. |
| POST-002 | UpdatedAtUtc en UpdatedByUserId zijn bijgewerkt. |
| POST-003 | SiteFeatureToggleHistory bevat oude en nieuwe waarde. |
| POST-004 | Onderliggende domeinflows kunnen de nieuwe featurestatus gebruiken. |
| POST-005 | Er is geen domeindata verwijderd. |
6. Trigger
De usecase start wanneer de beheerder in het features-overzicht een bestaande featuretoggle aan- of uitzet en de wijziging bevestigt.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Features-tab | Wijzigt een bestaande toggle. | De frontend toont bevestigingspopup op basis van PopupKey. | POP-BEH-FEAT-TOGGLE-CONFIRM. |
| 2 | Beheerder | Bevestigingspopup | Bevestigt de wijziging. | De frontend verstuurt FeatureKey en gewenste booleaanse waarde. | Geen vrije sleutelinput. |
| 3 | Backend | Autorisatiecomponent | Controleert beheerdercontext opnieuw. | Bij ontbreken van rechten wordt de mutatie geweigerd. | Server-side autorisatie. |
| 4 | Backend | Featurevalidatie | Controleert of FeatureKey bekend en beheerbaar is. | Onbekende of read-only sleutel wordt geblokkeerd. | Centrale sleutelset. |
| 5 | Backend | Database-transactie | Leest actuele togglewaarde. | OldValue wordt bepaald vóór update. | SiteFeatureToggles. |
| 6 | Backend | Database-transactie | Werkt IsEnabled, UpdatedAtUtc en UpdatedByUserId bij. | De wijziging wordt atomair opgeslagen. | UTC-tijdstip. |
| 7 | Backend | Historie | Schrijft SiteFeatureToggleHistory. | OldValue, NewValue, actor en tijdstip worden vastgelegd. | Audit. |
| 8 | Backend | Featurestatus | Maakt nieuwe status beschikbaar voor runtime-controles. | Afhankelijk van implementatie via cache invalidatie of directe herlezing. | Configuratiegedrag. |
| 9 | Frontend | Features-tab | Toont resultaat en ververst de regel. | De beheerder ziet de nieuwe status en laatste wijzigingsgegevens. | POP-BEH-FEAT-TOGGLE-SAVED. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 1 | Beheerder annuleert de bevestiging. | De toggle blijft ongewijzigd en de oorspronkelijke waarde blijft zichtbaar. | Bevestigingspopup sluiten. | Geen. |
| ALT-002 | 3 | Sessierechten zijn vervallen. | De backend weigert de mutatie en toont veilige foutafhandeling. | POP-BEH-FEAT-TOGGLE-FAILED. | Geen. |
| ALT-003 | 4 | FeatureKey is onbekend of niet beheerbaar. | De wijziging wordt geweigerd; de GUI mag de sleutel niet toevoegen. | POP-BEH-FEAT-TOGGLE-FAILED. | Geen. |
| ALT-004 | 5 | Actuele waarde is inmiddels door een andere beheerder gewijzigd. | De backend controleert de actuele waarde en verwerkt de nieuwe mutatie op basis van actuele databasewaarheid. | POP-BEH-FEAT-TOGGLE-FAILED of bevestiging opnieuw. | Alleen bij geldige herbevestiging. |
| ALT-005 | 6 | Opslaan faalt. | De transactie wordt teruggedraaid; er ontstaat geen gedeeltelijke history. | POP-BEH-FEAT-TOGGLE-FAILED. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Featuremutaties zijn altijd server-side geautoriseerd. |
| BR-002 | Alleen IsEnabled is via deze flow wijzigbaar. |
| BR-003 | FeatureKey is read-only en mag niet via de GUI worden gewijzigd. |
| BR-004 | Bij iedere succesvolle wijziging wordt history vastgelegd met oude en nieuwe waarde. |
| BR-005 | Een uitgeschakelde feature blokkeert nieuwe acties, maar verwijdert geen bestaande gegevens. |
| BR-006 | Onderliggende domeinflows mogen niet vertrouwen op alleen verborgen UI; zij controleren de featurestatus zelf. |
| BR-007 | Toegankelijkheid uitschakelen bewaart UserSettings en verhindert alleen aanbieden/toepassen zolang de feature uit staat. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | FeatureKey moet exact overeenkomen met een bekende sleutel. |
| VAL-002 | Nieuwe waarde moet boolean zijn. |
| VAL-003 | De actor moet een actieve beheerder zijn. |
| VAL-004 | UpdatedAtUtc wordt als UTC-tijdstip vastgelegd. |
| VAL-005 | OldValue en NewValue moeten beide vastgelegd kunnen worden in history. |
| VAL-006 | De mutatie moet transactioneel zijn: update en history slagen samen of niet. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | SiteFeatureToggles update | IsEnabled, UpdatedAtUtc en UpdatedByUserId worden bijgewerkt. |
| MUT-002 | SiteFeatureToggleHistory insert | Oude waarde, nieuwe waarde, actor en tijdstip worden vastgelegd. |
| MUT-003 | FeatureToggleChanged event | Applicatielogica kan de gewijzigde status publiceren voor runtime-controles. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | FeatureKey | De technische sleutel blijft ongewijzigd. |
| NO-002 | SystemSettings | Niet-booleaanse instellingen worden niet aangepast. |
| NO-003 | UserSettings | Gebruikerswaarden blijven bestaan. |
| NO-004 | Domeinrecords | Privéberichten, meldingen, oefeningen, relaties en resultaten worden niet verwijderd. |
| NO-005 | Identity provider | Logincredentials en Keycloakstatus worden niet rechtstreeks gewijzigd. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Deze usecase verwijst uitsluitend naar PopupKey. Popupteksten, knopteksten, inputlabels en themakeuzes blijven bronhoudend in het popupregister en popup-themes.
| PopupKey | Gebruik |
|---|---|
| POP-BEH-FEAT-TOGGLE-CONFIRM | Bevestigt wijziging van een sitebrede featuretoggle. |
| POP-BEH-FEAT-TOGGLE-SAVED | Terugkoppeling na succesvolle wijziging. |
| POP-BEH-FEAT-TOGGLE-FAILED | Veilige foutmelding bij validatie- of opslagfout. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Legt vast dat Features alleen echte sitebrede toggles wijzigen. |
| Technisch Ontwerp | Technisch Ontwerp: communicatie en systeemnotificaties, readmodels en badges en frontendstate beschrijven de technische uitwerking. Vraagt transactionele update plus history en server-side hercontrole van autorisatie. |
| Software Requirements Specification | Levert eisen voor booleaanse mutatie, audit, sleutelvalidatie en dataretentie bij uitschakelen. |
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-FEAT-002-REQ-001 | SRS-ADM-001 SRS-POP-003 AC-ADM-001 AC-POP-003 | Alleen bestaande bekende featuretoggles wijzigbaar maken |
UC-BEH-FEAT-002-REQ-002 | SRS-ADM-001 SRS-POP-003 AC-ADM-001 AC-POP-003 | FeatureKey read-only houden |
UC-BEH-FEAT-002-REQ-003 | SRS-ADM-001 SRS-POP-003 SRS-NFR-AUD-001 AC-ADM-001 AC-POP-003 AC-NFR-AUD-001 | Iedere featurewijziging transactioneel opslaan met auditgeschiedenis |
UC-BEH-FEAT-002-REQ-004 | SRS-ADM-005 SRS-ADM-001 AC-ADM-005 AC-ADM-001 | Bij uitschakelen geen bestaande domeindata verwijderen |
UC-BEH-FEAT-002-REQ-005 | SRS-AUTH-001 SRS-ADM-002 SRS-ADM-001 SRS-POP-003 AC-AUTH-001 AC-ADM-002 AC-ADM-001 AC-POP-003 | Onderliggende domeinflows verplicht server-side featurestatus laten controleren |
UC-BEH-FEAT-002-REQ-006 | SRS-ADM-002 SRS-ADM-001 SRS-NFR-AVL-001 AC-ADM-002 AC-ADM-001 AC-NFR-AVL-001 | Bij mislukte opslag rollback uitvoeren |
UC-BEH-FEAT-002-REQ-007 | SRS-ADM-001 AC-ADM-001 | De beheerder na succesvolle wijziging de actuele status en laatste wijziging tonen |