Skip to main content

UC-DOC-LLN-008 - Autorisatiewijziging aan leerling communiceren

1. Kerngegevens

VeldWaarde
Usecase-IDUC-DOC-LLN-008
NaamAutorisatiewijziging aan leerling communiceren
DomeinDocent
SubdomeinLeerlingen en niveau-autorisaties
Primaire actorDocent
Secundaire actor(en)Systeem, Leerling
RolcontextActieve docentcontext met geldige docentrol, relevante docent-leerlingrelatie en toegestane niveaucontext
Betrokken schermenDocent - Leerlingen, Docent - Autorisaties, Docent - Niveau-autorisaties beheren
Gerelateerde usecasesUC-DOC-LLN-005, UC-DOC-LLN-006, UC-DOC-LLN-007, UC-GEN-MSG-001, UC-GEN-MSG-003, UC-LLN-TOEG-001, UC-LLN-TOEG-002, UC-LLN-TOEG-003
Primaire entiteitenUsers, UserRoles, Roles, UserRelationships, TeacherLevels, TeacherStudentLevelAccess
Secundaire entiteiten / eventsSystemMessages, autorisatie-events, leerlingtoegangs-readmodel, audit/logging
Gerelateerde popupsNiet van toepassing
PopupregisterNiet van toepassing
MoSCoWMust

2. Omschrijving

Deze usecase beschrijft hoe OefenHub een leerling informeert over een wijziging in niveau-autorisatie. De communicatie verloopt via het centrale systeemberichtendomein, zonder dat de docent een privébericht opstelt of dat deze usecase de autorisatiewijziging zelf uitvoert.

De usecase blijft bewust binnen het docentdomein. Relatievorming, profielbeheer, accounttoegang, leerlingfrontpagegedrag en generieke berichtafhandeling worden niet opnieuw als bronwaarheid beschreven. Deze flow gebruikt die domeinen alleen als randvoorwaarde of vervolgcontext.

Alle beslissingen die zichtbaarheid of wijzigbaarheid bepalen, worden server-side opnieuw gecontroleerd. Een selectie in de frontend, een oude route of een eerder geladen readmodel mag nooit zelfstandig bepalen dat een docent een leerling of niveau mag wijzigen.

3. Scope

3.1 Binnen scope

  • Ontvangen van een autorisatiewijziging vanuit individuele of bulkflows.
  • Bepalen welke leerling geïnformeerd moet worden.
  • Aanmaken van een systeembericht met veilige contextomschrijving en, waar codegedreven beschikbaar, een route naar de relevante leerlingcontext.
  • Correct omgaan met leerlingen die op dat moment in een actieve oefenrun zitten.
  • Afleiden van ongelezenstatus en headerbadge volgens het berichtendomein.
  • Vastleggen dat de communicatie bij de autorisatiewijziging hoort.

3.2 Buiten scope

  • Toekennen of intrekken van de autorisatie zelf.
  • Opstellen van een privébericht door de docent.
  • Aanmaken van relatie-uitnodigingen.
  • Tonen van de volledige mailbox of het openen van het systeembericht.
  • Tonen van systeemnotificaties op de frontpage.

3.3 DRY-afbakening

  • De docent-leerlingrelatie zelf blijft bronhoudend in het generieke relatiedomein.
  • De leerlingzijde van zichtbaarheid en starten van oefeningen blijft bronhoudend in het leerlingdomein.
  • Systeemberichten worden functioneel gebruikt als communicatiekanaal, maar de mailbox- en leesstatusregels blijven bronhoudend in het generieke berichtendomein.
  • Collaboratorrechten geven geen automatische toegang tot leerlingen, resultaten, geschiedenis of live meekijken.
  • Niveau-autorisaties zijn gescheiden van rollen, relaties en profielinstellingen.
  • Historische resultaten worden niet herschreven door autorisatiewijzigingen.
  • Samenvattingen, lijsten en aantallen zijn afgeleide readmodelwaarden en vormen geen tweede bron van waarheid.

4. Pre-condities

IDVoorwaarde
PRE-001De gebruiker is succesvol ingelogd.
PRE-002De gebruiker heeft een actieve docentrol.
PRE-003De OefenHub-sessiecontext is server-side opgebouwd.
PRE-004De docentcontext en relevante niveaucontext zijn beschikbaar.
PRE-005De betrokken leerling valt binnen een actieve docent-leerlingrelatie wanneer een leerlingmutatie wordt uitgevoerd.
PRE-006De backend kan actuele autorisatiegegevens ophalen voordat een wijziging wordt verwerkt.

5. Post-condities

IDResultaat
POST-001De autorisatie- of communicatiehandeling is uitgevoerd of veilig geblokkeerd.
POST-002De docent heeft geen gegevens buiten de eigen docentcontext gewijzigd of gezien.
POST-003Alle uitgevoerde mutaties zijn herleidbaar vastgelegd waar dat voor deze flow geldt.
POST-004Afgeleide leerlingtoegang kan na de mutatie opnieuw correct worden bepaald.
POST-005Vervolgcommunicatie of vervolgtoegang wordt in de daarvoor bedoelde usecases afgehandeld.

6. Trigger

Een niveau-autorisatie is door een docent toegevoegd of ingetrokken via een individuele of bulkflow.

7. Normale processtroom

StapActorScherm / componentActieSysteemresponsData / regel
1SysteemAutorisatieflowOntvangt succesvolle autorisatiewijzigingStart communicatieafhandelingStudentUserId, TeacherLevelId, wijzigingstype
2SysteemCommunicatieserviceControleert of leerling intern account bestaatBepaalt ontvangerUsers.Id
3SysteemBerichtensjabloonBepaalt onderwerp en typeGebruikt systeemberichttemplateGeen vrije docenttekst
4SysteemContextserviceBepaalt veilige berichtcontextGebruikt tekstuele context of bestaande veilige routeGeen losse ActionUrl
5SysteemDatabaseMaakt systeembericht aanBericht staat ongelezen in mailboxSystemMessages.RecipientUserId
6SysteemRealtime/badgeBepaalt of directe badge/notify zichtbaar mag zijnHoudt rekening met actieve oefenrunLeerling mag niet gestoord worden tijdens oefening
7FrontendHeader/mailboxToont ongelezenstatus wanneer toegestaanBadge wordt afgeleid uit berichtstatusReadmodel uit berichtendomein
8LeerlingBerichtenoverzichtKan bericht op een volgend moment openenVervolggedrag hoort bij generiek berichtenUC-GEN-MSG-003

8. Alternatieve en exceptionele processtromen

IDVanaf stapSituatieSysteemgedragPopup / meldingDatamutatie
ALT-0012Ontvanger bestaat niet of is geanonimiseerdSysteem maakt geen gebruikersgericht systeembericht en logt de situatie waar nodig technisch.Niet van toepassingGeen SystemMessage
ALT-0023Geen specifiek sjabloon beschikbaarSysteem gebruikt generieke autorisatiewijzigingscommunicatie of blokkeert volgens sjabloonregels.Niet van toepassingGeen of SystemMessage
ALT-0034Er is geen klikbare vervolgcontext nodigSysteem maakt een informatief systeembericht zonder losse URL of niet-ondersteunde domeinlink.Niet van toepassingSystemMessage
ALT-0046Leerling zit actief in een oefenrunSysteem creëert het bericht, maar directe verstoring of popup wordt uitgesteld of verborgen volgens leerling/oefenregels.Niet van toepassingSystemMessage
ALT-0055Berichtaanmaak faalt na autorisatiemutatieSysteem logt de fout en maakt de autorisatiemutatie niet ongedaan tenzij de transactiegrens dit vereist.Niet van toepassingAfhankelijk van transactiegrens
ALT-0068Leerling opent bericht na ingetrokken of gewijzigde contextBericht blijft bestaan; vervolgactie wordt veilig herbeoordeeld.Niet van toepassingReadAtUtc mogelijk via berichtenusecase

9. Business rules

IDRegel
BR-001Communicatie over niveau-autorisatie verloopt via systeemberichten, niet via privéberichten.
BR-002Deze usecase voert geen autorisatiewijziging uit maar communiceert het resultaat daarvan.
BR-003Een systeembericht vereist een bestaande interne ontvanger.
BR-004Tijdens een actieve oefenrun mag zichtbare notificatie worden beperkt zonder de ongelezenstatus te verliezen.
BR-005Het openen of lezen van het systeembericht wijzigt de autorisatie niet.
BR-006De inhoudelijke bron voor systeemberichttemplates ligt in het generieke berichtendomein en templatebeheer.
BR-007Wanneer het bericht een route of contextactie toont, moet de frontend de toegang bij openen opnieuw server-side controleren.
BR-008Communicatie mag geen informatie over andere docenten of andere docentcontexten lekken.
BR-009Autorisatiebeheer is altijd docentcontextgebonden en mag geen informatie uit andere docentcontexten lekken.
BR-010Alle autorisatiekritieke beslissingen worden server-side genomen.
BR-011Een wijziging in niveau-autorisatie is geen wijziging van leerlingrol, accountstatus of relatie.
BR-012De actuele toestand na een mutatie is leidend boven eerder geladen clientstate.

10. Datavalidatie

Veld / objectValidatie
DocentrolMoet actief zijn op het moment van de handeling.
DocentcontextWordt server-side bepaald uit sessie, rollen, relaties en niveaucontext.
StudentUserIdMoet binnen de actieve docent-leerlingcontext vallen wanneer een leerling wordt gewijzigd.
TeacherLevelIdMoet bestaan, actief zijn en binnen de toegestane docentcontext vallen.
TeacherStudentLevelAccessMag niet leiden tot dubbele actieve autorisaties voor dezelfde context.
BulkselectieMag alleen geldige, dedupliceerde leerlingen bevatten.
CommunicatiecontextMag geen gegevens over andere docenten of andere autorisatiecontexten bevatten.
RouteparametersMogen geen wijziging afdwingen zonder server-side hercontrole.

11. Datamutaties en events

StapTypeEntiteit / eventMutatie
5CreateSystemMessagesSysteembericht wordt aangemaakt voor de leerling.
6EventAuthorizationChangeMessageCreatedCommunicatie over autorisatiewijziging is aangemaakt.

12. Geen datamutaties

EntiteitReden
TeacherStudentLevelAccessDe autorisatie is al in een eerdere usecase gewijzigd.
PrivateMessageThreadsEr wordt geen privéberichtthread aangemaakt.
UserRelationshipsRelaties worden niet aangepast.
ExerciseRunsOefenruns worden niet gewijzigd.
SystemNotificationsSysteemnotificaties zijn een ander domein dan mailbox-systeemberichten.

13. State diagram

Deze usecase wijzigt de niveau-autorisatie niet. De relevante toestand is de communicatieafhandeling rond een reeds uitgevoerde autorisatiewijziging.

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

16.1 Systeembericht na autorisatiewijziging

16.2 Geen geldige ontvanger

17. Popupverwijzingen

PopupKeyMomentDoel
Niet van toepassingGehele usecaseDeze flow gebruikt geen domeinspecifieke popupregister-popup. Routeguard-, validatie-, lege-staat- en niet-beschikbaarafhandeling verlopen via componentmelding of bestaande generieke foutafhandeling.

18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification

DoeldocumentAfleiding
Functioneel OntwerpLegt vast hoe docenten niveau-autorisaties voor gekoppelde leerlingen beheren binnen de eigen docentcontext.
Technisch OntwerpTechnisch Ontwerp: autorisatie en contextcontrole, technische rolflows, relatiebeheer en readmodels en tellers beschrijven de technische uitwerking. Vertaalt de server-side validaties, transacties, idempotentie en communicatiekoppeling naar services en databasebewerkingen.
Software Requirements SpecificationLeidt requirements af voor contextcontrole, autorisatiemutaties, auditbaarheid, communicatie en afscherming van andere docentcontexten.
Database-informatieBepaalt aanscherpingen rond TeacherStudentLevelAccess, SystemMessages en afgeleide leerlingtoegang.
OntwerpbronnenRaakt business rules, autorisatiematrix, command-register, event-register en usecase-matrices voor muterende autorisatie- en communicatieflows.

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
REQ-UC-DOC-LLN-008-001SRS-AUTH-001
SRS-MSG-001
SRS-CAT-001
SRS-LRN-009
SRS-TCH-003
AC-AUTH-001
AC-MSG-001
AC-CAT-001
AC-LRN-009
AC-TCH-003
Leerlingen via systeemberichten kunnen informeren over niveau-autorisatiewijzigingen
REQ-UC-DOC-LLN-008-002SRS-AUTH-001
SRS-MSG-001
SRS-TCH-001
AC-AUTH-001
AC-MSG-001
AC-TCH-001
Voor autorisatiewijzigingscommunicatie geen privéberichtthread vereisen
REQ-UC-DOC-LLN-008-003SRS-MSG-002
SRS-SHR-002
SRS-SHR-005
SRS-TCH-001
AC-MSG-002
AC-SHR-002
AC-SHR-005
AC-TCH-001
Alleen systeemberichten aanmaken voor bestaande interne ontvangers
REQ-UC-DOC-LLN-008-004SRS-MSG-001
SRS-LRN-009
SRS-TCH-001
AC-MSG-001
AC-LRN-009
AC-TCH-001
Directe verstoring tijdens actieve oefenruns kunnen beperken zonder het systeembericht te verliezen
REQ-UC-DOC-LLN-008-005SRS-AUTH-001
SRS-MSG-007
SRS-TCH-001
AC-AUTH-001
AC-MSG-007
AC-TCH-001
Bij openen van een bericht de vervolgcontext server-side opnieuw controleren
REQ-UC-DOC-LLN-008-006SRS-TCH-001
AC-TCH-001
Voorkomen dat communicatie gegevens over andere docentcontexten lekt