UC-BEH-CAT-004 — Categoriestatus wijzigen
1. Kerngegevens
| Veld | Waarde |
|---|---|
| Usecase-ID | UC-BEH-CAT-004 |
| Naam | Categoriestatus wijzigen |
| Domein | Beheerder / Categorieën beheren |
| Primaire actor | Beheerder |
| Secundaire actor(en) | Frontend, backend, database, autorisatiecomponent, categoriebeheercomponent, historiecomponent |
| Rolcontext | Actieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker |
| Betrokken schermen | Content > Categorieën beheren |
| Gerelateerde usecases | UC-BEH-CAT-001, UC-BEH-CAT-002, UC-BEH-CAT-003, UC-BEH-CAT-005, UC-BEH-CAT-006, UC-BEH-CAT-007 |
| Primaire entiteiten | Categories, CategoryHistory, CategoryMigrations, TeacherLevelCategories, TeacherLevelCategoryExercises |
| Secundaire entiteiten / events | Users, ExerciseRuns, SharedExercises, categoriebeheer-readmodels |
| Gerelateerde popups | POP-BEH-CAT-STATUS-CONFIRM |
| Popupregister | Ontwerpbronnen — Popup-register |
| MoSCoW | Must |
2. Omschrijving
Deze usecase beschrijft hoe een beheerder de functionele status van een centrale categorie wijzigt, bijvoorbeeld door een categorie niet langer nieuw kiesbaar te maken via soft-delete of door een eerder uitgefaseerde categorie te herstellen.
Een statuswijziging naar niet-kiesbaar is alleen toegestaan wanneer er geen actieve docentniveaukoppelingen en geen actieve oefenkoppelingen meer aan de categorie hangen. Functioneel geldt: eerst migreren of loskoppelen, daarna pas status wijzigen.
De wijziging wordt vastgelegd op Categories.IsDeleted en auditbaar geregistreerd in CategoryHistory met ActionType SOFT_DELETE of RESTORE.
Uitgangspunten
- Categorieën zijn centrale onderwijsinhoud en geen private docentlabels.
- Naam, kleur en icoon vormen samen de centrale categorie-identiteit.
- Beheeracties op categorieën zijn volledig server-side gevalideerd.
- Historische resultaten behouden hun oorspronkelijke categoriecontext.
- Popupinhoud blijft bronhoudend in het centrale popupregister.
3. Scope
Deze usecase beschrijft:
- Soft-deleten of uitfaseren van een centrale categorie wanneer geen actieve afhankelijkheden bestaan.
- Herstellen van een soft-deleted categorie wanneer dat server-side toegestaan is.
- Blokkeren van statuswijzigingen bij actieve TeacherLevelCategories of TeacherLevelCategoryExercises.
- Bevestiging met verplichte reden.
- Vastleggen van CategoryHistory voor statuswijziging.
Deze usecase beschrijft niet:
- Docentniveaubeheer, leerlingautorisaties of oefeningconfiguratie wijzigen; die blijven bronhoudend in docentflows of docentondersteuning.
- Nieuwe centrale categorieën aanmaken vanuit beheer; categorie-aanmaak is bronhoudend in de docentflow of via technische migratie wanneer dat expliciet nodig is.
- Historische exercise runs herschrijven; bestaande runs behouden hun oorspronkelijke categoriecontext.
- Popupteksten of knopteksten specificeren; usecases verwijzen uitsluitend naar PopupKey.
- Migreren van gebruik naar een doelcategorie; dit hoort bij UC-BEH-CAT-005 en UC-BEH-CAT-006.
- Naam, kleur of icoon wijzigen; dit hoort bij UC-BEH-CAT-003.
- Hard verwijderen van categorieën.
3.1 Afbakening met aangrenzende domeinen
| Onderdeel | Afbakening |
|---|---|
| Docent / Oefenaanbod | Docenten koppelen categorieën aan niveaus en maken waar toegestaan nieuwe centrale categorieën aan; beheer past de centrale identiteit en onderhoudsacties toe. |
| Beheerder / Docentondersteuning | Support op concrete docentstructuren mag categoriegebruik inspecteren, maar centrale categorie-identiteit wordt hier beheerd. |
| Leerling / Oefenaanbod | Leerlingen zien alleen afgeleide toegankelijke categorieën; deze bundel bepaalt niet zelfstandig leerlingtoegang. |
| Database-informatie | Categories, CategoryHistory en CategoryMigrations blijven de technische bron voor centrale categorie-identiteit en audit. |
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 de beheeromgeving via Content > Categorieën beheren. |
| PRE-004 | De pagina gebruikt actuele serverdata; clientstate, routeparameters of verborgen formuliervelden bepalen geen autorisatie of categorie-identiteit. |
| PRE-005 | De beheerder heeft de detailweergave van één categorie geopend. |
| PRE-006 | De actuele impactwaarden zijn server-side beschikbaar. |
| PRE-007 | De gewenste statusovergang is zichtbaar in de sectie Categorie. |
5. Post-condities
| ID | Resultaat |
|---|---|
| POST-001 | Categories.IsDeleted is gewijzigd wanneer alle voorwaarden geldig waren. |
| POST-002 | UpdatedByUserId en UpdatedAtUtc zijn bijgewerkt. |
| POST-003 | CategoryHistory bevat een statuswijzigingsregel met reden. |
| POST-004 | Bij geblokkeerde statuswijziging is geen datamutatie uitgevoerd. |
| POST-005 | Actieve docentstructuur en historische rungegevens blijven ongewijzigd. |
6. Trigger
De usecase start wanneer de beheerder in de sectie Categorie een statuswijziging kiest, zoals uitfaseren of herstellen.
7. Normale processtroom
| Stap | Actor | Scherm / component | Actie | Systeemrespons | Data / regel |
|---|---|---|---|---|---|
| 1 | Beheerder | Sectie Categorie | Kiest statuswijziging. | De frontend vraagt server-side statuscontrole op. | CategoryId en gewenste overgang. |
| 2 | Backend | Autorisatiecomponent | Controleert beheerdercontext. | Alleen beheerder mag status wijzigen. | Server-side autorisatie. |
| 3 | Backend | Impactcontrole | Controleert actieve docentniveaukoppelingen. | Status naar niet-kiesbaar wordt geblokkeerd zolang actieve koppelingen bestaan. | TeacherLevelCategories.IsActive. |
| 4 | Backend | Impactcontrole | Controleert actieve oefenkoppelingen. | Status naar niet-kiesbaar wordt geblokkeerd zolang actieve oefenkoppelingen bestaan. | TeacherLevelCategoryExercises.IsActive. |
| 5 | Frontend | Popup | Toont bevestigingspopup met verplichte reden. | De beheerder bevestigt bewust de statuswijziging. | PopupKey POP-BEH-CAT-STATUS-CONFIRM. |
| 6 | Beheerder | Popup | Bevestigt met reden. | De backend verwerkt de statuswijziging. | Reason verplicht. |
| 7 | Backend | CategorieService | Wijzigt IsDeleted of herstelt de categorie. | Categories wordt bijgewerkt. | Categories.IsDeleted. |
| 8 | Backend | HistorieService | Schrijft CategoryHistory. | ActionType is SOFT_DELETE of RESTORE. | CategoryHistory. |
| 9 | Frontend | Detailweergave | Toont nieuwe status. | Beschikbare vervolgacties worden herberekend. | Detailreadmodel. |
8. Alternatieve en exceptionele processtromen
| ID | Vanaf stap | Situatie | Systeemgedrag | Popup / melding | Datamutatie |
|---|---|---|---|---|---|
| ALT-001 | 2 | Gebruiker is geen beheerder. | De backend weigert toegang. | Niet van toepassing. | Geen. |
| ALT-002 | 3 | Er bestaan actieve docentniveaukoppelingen. | De statuswijziging naar niet-kiesbaar wordt geblokkeerd met uitleg. | Niet van toepassing. | Geen. |
| ALT-003 | 4 | Er bestaan actieve oefenkoppelingen. | De statuswijziging naar niet-kiesbaar wordt geblokkeerd met uitleg. | Niet van toepassing. | Geen. |
| ALT-004 | 5 | Beheerder annuleert. | De status blijft ongewijzigd. | POP-BEH-CAT-STATUS-CONFIRM. | Geen. |
| ALT-005 | 6 | Reden ontbreekt. | De bevestiging wordt geweigerd. | POP-BEH-CAT-STATUS-CONFIRM. | Geen. |
| ALT-006 | 7 | Categorie is intussen door andere actie gewijzigd. | De backend herlaadt de actuele status en voert geen verouderde overgang uit. | Niet van toepassing. | Geen. |
9. Business rules
| ID | Business rule |
|---|---|
| BR-001 | Een categorie mag niet niet-kiesbaar worden gemaakt zolang actieve docentniveaukoppelingen bestaan. |
| BR-002 | Een categorie mag niet niet-kiesbaar worden gemaakt zolang actieve oefenkoppelingen bestaan. |
| BR-003 | Een statuswijziging is een beheeractie met verplichte reden. |
| BR-004 | Hard delete van Categories is niet toegestaan vanuit de GUI. |
| BR-005 | Een soft-deleted categorie blijft historisch raadpleegbaar en mag in beheerhistory zichtbaar blijven. |
| BR-006 | Herstellen van een categorie maakt geen oude docentkoppelingen automatisch actief. |
| BR-007 | Statuslabels in de GUI zijn afgeleid uit IsDeleted en gebruikscontext; zij vervangen geen historyregistratie. |
10. Datavalidatie
| ID | Validatie |
|---|---|
| VAL-001 | CategoryId is verplicht en moet bestaan. |
| VAL-002 | De gewenste overgang moet passen bij de actuele status. |
| VAL-003 | Actieve TeacherLevelCategories moeten server-side worden geteld. |
| VAL-004 | Actieve TeacherLevelCategoryExercises moeten server-side worden geteld. |
| VAL-005 | Reason is verplicht en maximaal 500 tekens. |
| VAL-006 | Restore mag geen naamconflict veroorzaken met een actieve categorie. |
| VAL-007 | De statusovergang moet transactioneel worden uitgevoerd met historyregistratie. |
11. Datamutaties en events
| ID | Mutatie / event | Toelichting |
|---|---|---|
| MUT-001 | Update Categories | IsDeleted, UpdatedByUserId en UpdatedAtUtc worden aangepast. |
| MUT-002 | CategoryHistory CREATE | Statuswijziging wordt vastgelegd met SOFT_DELETE of RESTORE en reden. |
12. Geen datamutaties
| ID | Geen mutatie | Reden |
|---|---|---|
| NO-001 | TeacherLevelCategories | Koppelingen worden niet automatisch gedeactiveerd of hersteld. |
| NO-002 | TeacherLevelCategoryExercises | Oefenkoppelingen blijven ongewijzigd. |
| NO-003 | CategoryMigrations | Statuswijziging maakt geen migratierecord aan. |
| NO-004 | ExerciseRuns | Historische runs blijven ongewijzigd. |
| NO-005 | Users | Rollen en accounts blijven ongewijzigd. |
13. State diagram
14. Decision flow
15. Data lifecycle diagram
16. Sequence diagrammen
17. Popupverwijzingen
Deze usecase verwijst uitsluitend naar PopupKey. Popupteksten, knopteksten, inputlabels, acties en themakeuzes blijven bronhoudend in het popupregister en popup-themes.
| PopupKey | Gebruik |
|---|---|
| POP-BEH-CAT-STATUS-CONFIRM | Bevestiging van statuswijziging met verplichte reden. |
18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification
| Document | Afleiding |
|---|---|
| Functioneel Ontwerp | Statuswijziging is alleen toegestaan zonder actieve docentniveau- en oefenkoppelingen. |
| Technisch Ontwerp | Technisch Ontwerp: oefencatalogus, databaseontwerp en historie en background jobs beschrijven de technische uitwerking. Status wordt technisch op Categories verwerkt en auditbaar vastgelegd in CategoryHistory. |
| Software Requirements Specification | SRS moet blokkade bij actieve afhankelijkheden, verplichte reden en restore-validatie eisen. |
| Database | Gebruikt Categories.IsDeleted en CategoryHistory; geen hard delete. |
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-CAT-004-REQ-001 | SRS-CAT-001 SRS-ADM-001 AC-CAT-001 AC-ADM-001 | Statuswijziging van categorieën alleen voor beheerders toestaan |
UC-BEH-CAT-004-REQ-002 | SRS-AUTH-001 SRS-CAT-002 SRS-TCH-002 SRS-ADM-001 AC-AUTH-001 AC-CAT-002 AC-TCH-002 AC-ADM-001 | Uitfaseren blokkeren zolang actieve docentniveaukoppelingen bestaan |
UC-BEH-CAT-004-REQ-003 | SRS-AUTH-001 SRS-ADM-001 AC-AUTH-001 AC-ADM-001 | Uitfaseren blokkeren zolang actieve oefenkoppelingen bestaan |
UC-BEH-CAT-004-REQ-004 | SRS-ADM-001 AC-ADM-001 | Een verplichte reden vragen vóór statuswijziging |
UC-BEH-CAT-004-REQ-005 | SRS-ADM-001 SRS-NFR-AUD-001 AC-ADM-001 AC-NFR-AUD-001 | Statuswijzigingen vastleggen in CategoryHistory |
UC-BEH-CAT-004-REQ-006 | SRS-CAT-001 SRS-ADM-001 AC-CAT-001 AC-ADM-001 | Categorieën niet hard verwijderen via de beheer-GUI |
UC-BEH-CAT-004-REQ-007 | SRS-CAT-001 SRS-ADM-001 SRS-NFR-SEC-001 AC-CAT-001 AC-ADM-001 AC-NFR-SEC-001 | Herstel van een soft-deleted categorie veilig valideren op naamconflicten |
UC-BEH-CAT-004-REQ-008 | SRS-CAT-001 SRS-ADM-001 AC-CAT-001 AC-ADM-001 | Oude koppelingen niet automatisch herstellen door een categorierestore |