UC-BEH-FRONT-003 — Frontpage-contentblok bewerken
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-FRONT-003 |
| Naam | Frontpage-contentblok bewerken |
| Domein | Beheerder / Frontpagebeheer |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, autorisatiecomponent, database, historyservice |
| Rolcontext | Actieve beheerdercontext; overige combinatierollen geven geen extra beheerrechten binnen deze usecase |
| Betrokken schermen | Site Instellingen > Frontpagebeheer, contexttabs, contentblokeditor, previewblok, geschiedenisdeel |
| Gerelateerde usecases | UC-BEH-FRONT-002, UC-BEH-FRONT-004, UC-BEH-FRONT-005 |
| Primaire entiteiten | ContentBlocks, ContentBlockHistory, Users |
| Secundaire entiteiten / events | DomainType, ContextType, ContentBlockHistory, frontpage-readmodels |
| Gerelateerde popups | POP-BEH-GEN-SAVE-FAILED, POP-BEH-GEN-VALIDATION-FAILED, POP-BEH-GEN-UNSAVED-CHANGES |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De beheerder wijzigt de tekstuele inhoud van een vooraf bekend frontpagecontentblok. De bloklocatie en renderlogica blijven codevast; alleen toegestane contentvelden worden aangepast.
Frontpagebeheer beheert tekstuele inhoud binnen vooraf bepaalde frontpagecontexten. De beheerder kan inhoud per context bekijken, aanpassen en historie raadplegen, maar de structurele pagina-opbouw blijft codegedreven.
De usecase gebruikt als functionele basis: DomainType = FrontPage en ContextType = Public, NoRole, Admin, Teacher, Student of Guardian. Dit betekent dat de beheerinterface geen vrije technische constructies introduceert, maar alleen werkt binnen de bestaande sleutelsets, records en codevaste ankers.
De usecase is bedoeld als definitieve functionele beschrijving voor het verdere FO-, TO- en SRS-traject. Daarom wordt expliciet vastgelegd welke gegevens wel worden gelezen of gewijzigd, welke gegevens bewust niet worden gewijzigd en welke validaties altijd server-side moeten plaatsvinden.
Uitgangspunten
- De beheerdercontext is altijd server-side leidend.
- De beheerinterface maakt onderscheid tussen beheerbare inhoud en technische ankers.
- History is onderdeel van het functionele resultaat wanneer een beheerder een wijziging opslaat.
- Zoeken, filteren, contextselectie en detailopenen zijn read-only totdat expliciet wordt opgeslagen.
- Onbekende of gemanipuleerde identifiers worden veilig geblokkeerd.
- De gebruikersinterface toont geen technische stacktraces of interne databasefouten.
- Domeinoverschrijdende bijwerkingen zijn uitgesloten tenzij een usecase die expliciet benoemt.
- De uitwerking volgt de centrale popup-, DRY- en ontwerpbronafspraken.
3. Scope
Deze usecase beschrijft:
- De beheerder wijzigt de tekstuele inhoud van een vooraf bekend frontpagecontentblok. De bloklocatie en renderlogica blijven codevast; alleen toegestane contentvelden worden aangepast.
- Server-side controleren dat de gebruiker beheerder is.
- Werken binnen de afbakening van Beheerder / Frontpagebeheer.
- Gebruik van DomainType = FrontPage en ContextType = Public, NoRole, Admin, Teacher, Student of Guardian.
- Scheiding tussen beheerbare velden en codegedreven of read-only velden.
- Veilige fout-, lege-staat- en blokkadeafhandeling.
- Geen history- of auditmutatie zolang geen wijziging wordt opgeslagen.
- Readmodelverversing na openen, selectie of raadplegen zonder brondatamutatie.
- Voorkomen dat deze beheeractie onbedoeld andere domeinen wijzigt.
Deze usecase beschrijft niet:
- Vrij bouwen van frontpages als pagebuilder.
- Wijzigen van de vaste volgorde, layout of renderlogica van frontpageblokken.
- Beheren van systeemnotificaties of featuretoggles.
- Aanpassen van docent-, leerling- of ouder-/voogdgegevens.
- Wijzigen van de runtime-prioriteitsregels voor gecombineerde rolfrontpages.
- Wijzigen van accounts, rollen of sessies buiten de autorisatiecontrole.
- Maken of wijzigen van oefenruns, resultaten, relaties, meldingen of privéberichten.
- Aanpassen van onderliggende code, migraties of seeddefinities via de beheerinterface.
4. Pre-condities
| ID | Voorwaarde |
|---|---|
| PRE-001 | De gebruiker is ingelogd en heeft een actief intern OefenHub-account. |
| PRE-002 | De gebruiker bezit een actieve beheerderrol. |
| PRE-003 | De beheerder opent de relevante route via Site Instellingen of een onderliggende beheerpagina. |
| PRE-004 | De relevante records of contexten voor Beheerder / Frontpagebeheer zijn aanwezig of kunnen als veilige lege staat worden getoond. |
| PRE-005 | De server-side autorisatiecomponent is beschikbaar. |
| PRE-006 | De database en historytabellen zijn beschikbaar voor read-only of muterende acties. |
| PRE-007 | De frontend gebruikt de actuele serverrespons en niet alleen eerder opgeslagen clientstate. |
| PRE-008 | Eventuele feature- of routebeschikbaarheid is door de applicatieconfiguratie toegestaan. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | Het gekozen frontpagecontentblok is in bewerkmodus geladen binnen de beheerdercontext. |
| POST-002 | Alleen beheerbare tekstvelden zijn wijzigbaar in de editor. |
| POST-003 | Technische sleutel, domein, context, bloklocatie, renderer en layoutvelden zijn read-only gebleven. |
| POST-004 | De editor kan gewijzigde velden als niet-opgeslagen wijziging tonen. |
| POST-005 | Er is nog geen persistente wijziging aan ContentBlocks of ContentBlockHistory uitgevoerd. |
| POST-006 | Opslaan wordt uitsluitend vervolgd via UC-BEH-FRONT-004. |
| POST-007 | Andere domeinen zoals accounts, meldingen, relaties en oefenruns zijn niet gewijzigd. |
6. Trigger
De usecase start wanneer de beheerder de actie Frontpage-contentblok bewerken uitvoert binnen het beheeronderdeel Beheerder / Frontpagebeheer.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Frontpagebeheer | Selecteert een bestaand contentblok binnen de gekozen context. | Frontend vraagt de actuele blokgegevens met editmetadata op. | DomainType = FrontPage. |
| 2 | Backend | Autorisatiecomponent | Controleert actieve beheerdercontext en recordtoegang. | Zonder beheerderrol wordt geen blokdata geleverd. | Server-side controle. |
| 3 | Backend | Contentblokservice | Laadt actuele waarden, versie en veldmetadata. | Backend onderscheidt beheerbare en read-only velden. | ContentBlocks. |
| 4 | Frontend | Editor | Toont het contentblok in bewerkmodus. | Alleen beheerbare tekstvelden zijn invoerbaar. | BlockKey, ContextType en renderer blijven read-only. |
| 5 | Beheerder | Editor | Past een beheerbaar tekstveld aan. | Frontend markeert het veld als gewijzigd. | Editorstate, geen databasewijziging. |
| 6 | Frontend | Editor | Voert directe invoercontrole uit. | Lege of te lange waarden kunnen al bij het veld worden gemarkeerd. | Clientcontrole is ondersteunend. |
| 7 | Frontend | Editor | Toont opslaan- en annulerenmogelijkheid. | Opslaan start UC-BEH-FRONT-004; annuleren herstelt de serverwaarde in de editor. | Geen persistente mutatie. |
| 8 | Beheerder | Editor | Kiest opslaan, annuleren of teruggaan. | De gekozen vervolgactie bepaalt of een aparte opslaanflow wordt gestart. | Bewerken zelf schrijft niets weg. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 2 | De gebruiker heeft geen actieve beheerderrol. | Backend blokkeert de actie en toont geen beheerdata. | Inline toegang geweigerd of veilige redirect. | Geen. |
| ALT-002 | 3 | Het interne account is gedeactiveerd of geanonimiseerd. | De sessiecontext wordt ongeldig gemaakt voor beheeracties. | Accountafhandeling. | Geen. |
| ALT-003 | 3 | Het contentblok bestaat niet of hoort niet bij DomainType = FrontPage. | Het systeem toont een veilige niet-beschikbaarafhandeling. | Inline melding. | Geen. |
| ALT-004 | 4 | Het blok bevat geen beheerbare velden. | De editor wordt read-only getoond of de bewerkactie wordt geblokkeerd. | Inline toelichting. | Geen. |
| ALT-005 | 5 | De beheerder vult een waarde in die al client-side ongeldig is. | Het veld wordt gemarkeerd; opslaan wordt niet gestart of blijft geblokkeerd. | Inline validatie. | Geen. |
| ALT-006 | 5 | Een read-only veld wordt via clientstate of payload aangepast. | Backend weigert dit wanneer opslaan wordt geprobeerd. | Inline foutmelding bij opslaan. | Geen binnen deze usecase. |
| ALT-007 | 8 | De beheerder annuleert of verlaat de editor zonder opslaan. | De oorspronkelijke serverwaarde blijft leidend; tijdelijke editorstate wordt weggegooid. | Eventuele generieke verlaten-waarschuwing. | Geen. |
9. Business rules
| ID | Regel |
|---|---|
| BR-UC-BEH-FRONT-003-001 | Frontpagebeheer beheert alleen inhoud binnen vooraf codevast bekende bloklocaties. |
| BR-UC-BEH-FRONT-003-002 | De frontpage-layout, blokvolgorde en structurele aanwezigheid van blokken blijven codegedreven. |
| BR-UC-BEH-FRONT-003-003 | Gecombineerde rolfrontpages worden runtime samengesteld uit basiscontexten en krijgen geen zelfstandig persistent frontpageontwerp. |
| BR-UC-BEH-FRONT-003-004 | Alle wijzigingen in beheerbare contentvelden worden veldniveau of changesetniveau historisch vastgelegd. |
| BR-UC-BEH-FRONT-003-005 | Contentwijzigingen mogen geen autorisaties, navigatierechten of zichtbare gegevenssets wijzigen. |
| BR-UC-BEH-FRONT-003-006 | De beheerder mag alleen contexten beheren waarvoor de applicatie een bekende frontpagecontext ondersteunt. |
| BR-UC-BEH-FRONT-003-007 | Opslaan wordt pas als vervolgactie beschikbaar wanneer minstens één beheerbaar veld daadwerkelijk gewijzigd is. |
| BR-UC-BEH-FRONT-003-008 | Bewerken in de editor registreert geen historymoment; history ontstaat pas bij opslaan via UC-BEH-FRONT-004. |
| BR-UC-BEH-FRONT-003-009 | De backend voert alle validaties opnieuw uit, ook wanneer de frontend al voorvalidatie heeft gedaan. |
10. Datavalidatie
| Veld / object | Validatie |
|---|---|
| Beheerdercontext | De gebruiker moet server-side een actieve beheerderrol hebben. |
| Recordtoegang | Het record, blok of template moet binnen het gevraagde subdomein bestaan. |
| Read-only velden | Technische sleutels, actie-identifiers en codegedreven velden mogen niet via de GUI worden gewijzigd. |
| Concurrency | De actuele recordversie wordt meegegeven aan de opslaanflow, zodat UC-BEH-FRONT-004 concurrency kan afdwingen. |
| DomainType | Moet FrontPage zijn voor frontpagebeheer. |
| ContextType | Moet een bekende frontpagecontext zijn: Public, NoRole, Admin, Teacher, Student of Guardian. |
| BlockKey | Moet verwijzen naar een bestaande codevaste bloklocatie. |
| Titel en tekstvelden | Mogen niet als vrije layoutcomponent worden geïnterpreteerd en moeten veilig worden opgeslagen en gerenderd. |
| Geschiedenis | Moet oude en nieuwe waarde, veldnaam, actor en tijdstip kunnen tonen. |
| Gecombineerde context | Mag niet als zelfstandig persistent ontwerp worden opgeslagen. |
| Auditactor | UpdatedByUserId of ChangedByUserId moet naar de uitvoerende beheerder of systeemactor verwijzen. |
| Tijdstip | Wijzigingsmomenten worden in UTC vastgelegd. |
| Rendering | Beheerbare tekst moet veilig worden opgeslagen en gerenderd zonder actieve inhoud. |
| Lege waarden | Verplichte zichtbare velden mogen niet leeg worden opgeslagen wanneer de runtime ze nodig heeft. |
11. Datamutaties en events
| Stap | Type | Entiteit / event | Mutatie |
|---|---|---|---|
| Alle stappen | Database | Niet van toepassing | Bewerken in de editor wijzigt alleen tijdelijke UI-/formulierstate. Persistente opslag gebeurt uitsluitend via UC-BEH-FRONT-004. |
Transactionele uitgangspunten
- Deze usecase opent en wijzigt een editorstate, maar schrijft geen contentrecord weg.
- Server-side validatie vindt opnieuw plaats wanneer de beheerder opslaat.
- Annuleren of navigeren zonder opslaan laat
ContentBlocksenContentBlockHistoryongewijzigd.
12. Geen datamutaties
| Entiteit | Reden |
|---|---|
| Users, Roles en UserRoles | Worden alleen gebruikt voor autorisatiecontrole; rollen of accounts worden niet gewijzigd. |
| Runtime gebruikersdata | Deze beheerusecase wijzigt geen leerling-, docent- of ouder-/voogddata. |
| Tickets en meldingen | Meldingenbeheer blijft in het generieke meldingendomein. |
| ExerciseRuns en resultaten | Oefenruns, geschiedenis en resultaten worden niet aangepast. |
| Relaties en uitnodigingen | Relatiebeheer wordt niet vanuit deze beheerpagina uitgevoerd. |
| Frontpage layoutdefinities in code | Blokvolgorde, structuur en renderlogica worden niet via data gewijzigd. |
| Gecombineerde frontpageontwerpen | Er wordt geen persistent ontwerp per rolcombinatie aangemaakt. |
13. State diagram
Niet van toepassing. Deze usecase wijzigt geen zelfstandig statusobject. De relevante toestanden zijn scherm-, editor- of readmodeltoestanden en worden in de decision flow en het data lifecycle diagram beschreven.
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Usecases verwijzen alleen naar PopupKey. Popupteksten, knopteksten, acties, inputvelden en themakeuzes worden centraal beheerd in het popupregister en de popup-themes.
| PopupKey | Moment | Doel |
|---|---|---|
| Niet van toepassing | Geen bevestigings- of invoerpopup in de normale processtroom. | Inline meldingen, lege staten of veilige redirects volstaan. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Doeldocument | Afleiding |
|---|---|
| Functioneel Ontwerp | Beschrijft welke beheeractie de beheerder kan uitvoeren, welke schermonderdelen zichtbaar zijn en welke grenzen gelden tussen beheerbare inhoud en codegedreven structuur. |
| Technisch Ontwerp | Technisch Ontwerp: domeinmodel en admin-eigenaarschap, databaseontwerp en frontendcompositie beschrijven de technische uitwerking. Beschrijf server-side autorisatie, editorstate, veldmetadata en de overdracht naar de aparte opslaanflow. |
| Software Requirements Specificatie | Beschrijft requirements voor toegangscontrole, editorstate, veilige foutafhandeling en afbakening van beheerbare versus read-only velden. |
| Database-informatie | Beschrijft of ContentBlocks voldoende veldmetadata en versiegegevens biedt om editorstate en de aparte opslaanflow veilig te ondersteunen. |
| Ontwerpbronnen en registers | Beschrijven autorisatiematrix, business rules en relevante matrices bij; command- en eventregisters worden pas geraakt door de aparte opslaanflow. |
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 |
|---|---|---|
REQ-UC-BEH-FRONT-003-001 | SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-ADM-002 AC-ADM-001 AC-CNT-001 | De actie uitsluitend toestaan aan gebruikers met een actieve beheerderrol |
REQ-UC-BEH-FRONT-003-002 | SRS-AUTH-001 SRS-AUTH-002 SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-AUTH-001 AC-AUTH-002 AC-ADM-002 AC-ADM-001 AC-CNT-001 | Alle beheerautorisatie server-side controleren en mag niet vertrouwen op clientstate of routeparameters |
REQ-UC-BEH-FRONT-003-003 | SRS-AUTH-004 SRS-ACC-003 SRS-ACC-005 SRS-ADM-001 SRS-CNT-001 SRS-NFR-SEC-001 AC-AUTH-004 AC-ACC-003 AC-ACC-005 AC-ADM-001 AC-CNT-001 AC-NFR-SEC-001 | Onbekende, ontbrekende of niet-toegankelijke records veilig afhandelen zonder technische details te tonen |
REQ-UC-BEH-FRONT-003-004 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Read-only technische sleutels en codegedreven velden beschermen tegen wijziging via de GUI |
REQ-UC-BEH-FRONT-003-005 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Bewerken in de editor behandelen als tijdelijke formulierstate zonder domeinmutatie |
REQ-UC-BEH-FRONT-003-006 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Opslaan alleen starten als aparte vervolgflow via UC-BEH-FRONT-004 |
REQ-UC-BEH-FRONT-003-007 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-AUD-001 AC-ADM-001 AC-CNT-001 AC-NFR-AUD-001 | Geen ContentBlockHistory registreren door alleen de editor te openen of velden tijdelijk te wijzigen |
REQ-UC-BEH-FRONT-003-008 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-AUD-001 AC-ADM-001 AC-CNT-001 AC-NFR-AUD-001 | Historyrecords als immutable behandelen en niet via de beheerinterface wijzigbaar maken |
REQ-UC-BEH-FRONT-003-009 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-SEC-001 AC-ADM-001 AC-CNT-001 AC-NFR-SEC-001 | Beheerbare tekst veilig opslaan en renderen zonder actieve of onveilige inhoud |
REQ-UC-BEH-FRONT-003-010 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Lege staten en blokkades gebruikersgericht en zonder technische details weergeven |
REQ-UC-BEH-FRONT-003-011 | SRS-ADM-002 SRS-ADM-001 SRS-CNT-001 AC-ADM-002 AC-ADM-001 AC-CNT-001 | Frontpagecontent per basiscontext beheren en geen persistent ontwerp per rolcombinatie aanmaken |
REQ-UC-BEH-FRONT-003-012 | SRS-AUTH-003 SRS-LRN-009 SRS-TCH-001 SRS-GUA-001 SRS-ADM-002 SRS-ADM-001 AC-AUTH-003 AC-LRN-009 AC-TCH-001 AC-GUA-001 AC-ADM-002 AC-ADM-001 | Gecombineerde rolfrontpages runtime samenstellen volgens de prioriteit Beheerder, Docent, Ouder/voogd |
REQ-UC-BEH-FRONT-003-013 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Frontpageblokstructuur, volgorde en layout codegedreven houden |
REQ-UC-BEH-FRONT-003-014 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | De usecase "Frontpage-contentblok bewerken" uitvoeren volgens de afbakening van het subdomein Beheerder / Frontpagebeheer |