UC-BEH-FRONT-001 — Frontpagebeheer openen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-FRONT-001 |
| Naam | Frontpagebeheer openen |
| 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-SITE-001, UC-BEH-FRONT-002, UC-BEH-FRONT-003, UC-BEH-FRONT-005, UC-BEH-FRONT-006 |
| Primaire entiteiten | ContentBlocks, ContentBlockHistory, Users |
| Secundaire entiteiten / events | DomainType, ContextType, frontpage-readmodels |
| Gerelateerde popups | Niet van toepassing |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
De beheerder opent de beheerpagina Frontpagebeheer vanuit Site Instellingen. Het systeem toont contexttabs en een overzicht van beheerbare frontpagecontent zonder direct wijzigingen uit te voeren.
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 opent de beheerpagina Frontpagebeheer vanuit Site Instellingen. Het systeem toont contexttabs en een overzicht van beheerbare frontpagecontent zonder direct wijzigingen uit te voeren.
- 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 | De usecase "Frontpagebeheer openen" is uitgevoerd binnen de beheerdercontext. |
| POST-002 | De beheerder ziet een actuele, veilige weergave of een duidelijke blokkade. |
| POST-003 | Read-only acties hebben geen domeinmutatie uitgevoerd. |
| POST-004 | Er zijn geen content-, history-, account-, autorisatie- of frontpage-runtimegegevens gewijzigd. |
| POST-005 | Er is geen historyrecord aangemaakt door alleen openen, selecteren, raadplegen of controleren. |
| POST-006 | Ongeldige contexten of identifiers zijn veilig geblokkeerd zonder gedeeltelijke gegevensweergave. |
| POST-007 | Technische sleutels en codegedreven velden zijn ongewijzigd gebleven. |
| POST-008 | Andere domeinen zoals accounts, meldingen, relaties en oefenruns zijn niet gewijzigd. |
6. Trigger
De usecase start wanneer de beheerder de actie Frontpagebeheer openen uitvoert binnen het beheeronderdeel Beheerder / Frontpagebeheer.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Site Instellingen | Kiest het beheeronderdeel. | Frontend vraagt de beheerpagina op. | Server-side autorisatie verplicht. |
| 2 | Frontend | Routering | Stuurt routeverzoek naar backend. | Backend controleert actieve beheerdercontext. | Geen client-only toegang. |
| 3 | Backend | Autorisatiecomponent | Controleert account, rol en routebevoegdheid. | Alleen actieve beheerder krijgt toegang. | Users, Roles, UserRoles. |
| 4 | Backend | Overzichtservice | Laadt de relevante beheerrecords. | Alleen records binnen het subdomein worden opgehaald. | ContentBlocks, ContentBlockHistory, Users. |
| 5 | Backend | Filter- en zoekmodel | Bepaalt standaardweergave, filters en sortering. | Het overzicht krijgt stabiele sortering en veilige lege staat. | Readmodel. |
| 6 | Backend | Geschiedenisindicatie | Bepaalt waar history beschikbaar is. | De UI toont doorklikmogelijkheden zonder historydetails direct te laden. | Historytabellen. |
| 7 | Backend | Frontend | Levert overzichtsreadmodel. | Frontend ontvangt records, metadata, filteropties en toegestane acties. | Geen mutatie. |
| 8 | Frontend | Beheerpagina | Rendert overzicht en detailpositie. | De beheerder ziet welke records of contexten beschikbaar zijn. | Afbakening tot beheerpagina. |
| 9 | Beheerder | Beheerpagina | Zoekt, filtert of selecteert een record. | Systeem beperkt resultaten tot het subdomein. | Zoeken wijzigt geen data. |
| 10 | Beheerder | Beheerpagina | Kiest eventueel een detail- of bewerkactie. | Vervolgusecase neemt over. | Geen directe domeinmutatie vanaf openen. |
| 11 | Frontend | Beheerpagina | Toont lege of foutstaat indien nodig. | Geen technische details worden gelekt. | Veilige UI-afhandeling. |
| 12 | Systeem | Audit | Registreert geen beheerwijziging. | Alleen daadwerkelijke wijzigingen worden auditbaar vastgelegd. | Geen AdminAuditLog door alleen openen. |
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 | 4 | De gevraagde context of het gevraagde record bestaat niet. | Het systeem toont een veilige niet-beschikbaarafhandeling. | Inline melding. | Geen. |
| ALT-004 | 4 | Er zijn geen contentblokken of historyregels voor de gekozen scope. | Het systeem toont een neutrale lege staat. | Niet van toepassing. | Geen. |
| ALT-005 | 5 | De beheerder levert een onbekende ContextType, BlockKey of filterwaarde aan. | Backend weigert de query of valt terug op een veilige lege staat zonder extra data te tonen. | Inline validatie of neutrale melding. | Geen. |
| ALT-006 | 6 | De readmodelopbouw faalt technisch. | Het systeem toont een veilige foutmelding zonder technische details. | Veilige foutmelding. | Geen. |
| ALT-007 | 6 | De beheerder probeert vanuit deze raadpleegflow een wijziging af te dwingen. | Backend negeert of weigert de muterende payload en voert geen command uit. | Inline blokkade. | Geen. |
9. Business rules
| ID | Regel |
|---|---|
| BR-UC-BEH-FRONT-001-001 | Frontpagebeheer beheert alleen inhoud binnen vooraf codevast bekende bloklocaties. |
| BR-UC-BEH-FRONT-001-002 | De frontpage-layout, blokvolgorde en structurele aanwezigheid van blokken blijven codegedreven. |
| BR-UC-BEH-FRONT-001-003 | Gecombineerde rolfrontpages worden runtime samengesteld uit basiscontexten en krijgen geen zelfstandig persistent frontpageontwerp. |
| BR-UC-BEH-FRONT-001-004 | Alle wijzigingen in beheerbare contentvelden worden veldniveau of changesetniveau historisch vastgelegd. |
| BR-UC-BEH-FRONT-001-005 | Contentwijzigingen mogen geen autorisaties, navigatierechten of zichtbare gegevenssets wijzigen. |
| BR-UC-BEH-FRONT-001-006 | De beheerder mag alleen contexten beheren waarvoor de applicatie een bekende frontpagecontext ondersteunt. |
| BR-UC-BEH-FRONT-001-007 | Het openen van het overzicht is read-only en mag geen inhoudelijke beheerwijziging registreren. |
| BR-UC-BEH-FRONT-001-008 | Zoeken, filteren en sorteren wijzigen geen brondomeinrecords. |
| BR-UC-BEH-FRONT-001-009 | De standaardweergave moet een veilige lege staat ondersteunen. |
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 | Niet van toepassing voor deze read-only flow; bij vervolgacties wordt de actuele recordversie opnieuw opgehaald. |
| 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 | De flow is read-only en wijzigt geen ContentBlocks, ContentBlockHistory, accounts, autorisaties of frontpage-runtimegegevens. |
Transactionele uitgangspunten
- Er wordt geen command uitgevoerd en geen historyrecord aangemaakt.
- Filteren, selecteren en raadplegen zijn readmodelacties.
- Technische fouten leiden tot veilige foutafhandeling zonder gedeeltelijke mutatie.
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
Hoofdsequence
Vervolgsequence
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, server-side autorisatie, readmodelopbouw en het read-only gebruik van ContentBlocks, ContentBlockHistory en Users. |
| Software Requirements Specificatie | Beschrijft requirements voor toegangscontrole, read-only raadpleging, veilige foutafhandeling en afbakening van beheerbare versus codegedreven velden. |
| Database-informatie | Beschrijft of sleutelsets en readmodellen voor ContentBlocks en ContentBlockHistory voldoende uitleesbaar zijn voor deze flow. |
| Ontwerpbronnen en registers | Beschrijven autorisatiematrix, business rules en relevante matrices bij; command- en eventregisters worden voor deze read-only flow niet uitgebreid. |
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-001-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-001-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-001-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-001-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-001-005 | SRS-RDM-001 SRS-ADM-001 SRS-CNT-001 AC-RDM-001 AC-ADM-001 AC-CNT-001 | Zoek-, filter- en selecteeracties behandelen als read-only acties zonder domeinmutatie |
REQ-UC-BEH-FRONT-001-006 | SRS-ADM-001 SRS-CNT-001 SRS-NFR-AUD-001 AC-ADM-001 AC-CNT-001 AC-NFR-AUD-001 | Deze raadpleegflow uitvoeren zonder persistente domeinmutatie of historyregistratie |
REQ-UC-BEH-FRONT-001-007 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Technische sleutels en codegedreven velden beschermen tegen wijziging via deze flow |
REQ-UC-BEH-FRONT-001-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-001-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-001-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-001-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-001-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-001-013 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | Frontpageblokstructuur, volgorde en layout codegedreven houden |
REQ-UC-BEH-FRONT-001-014 | SRS-ADM-001 SRS-CNT-001 AC-ADM-001 AC-CNT-001 | De usecase "Frontpagebeheer openen" uitvoeren volgens de afbakening van het subdomein Beheerder / Frontpagebeheer |