Relatiebeheer

6.1 Doel

Relatiebeheer is het overkoepelende domein voor accountkoppelingen tussen gebruikers.

Relaties bepalen binnen OefenHub onder meer:

• welke gebruikers elkaar mogen benaderen;
• wanneer privéberichten toegestaan zijn;
• wanneer leerlingen oefeningen met vrienden mogen delen;
• wanneer ouders/voogden kinderen mogen bekijken;
• wanneer ouders/voogden resultaten, geschiedenis en live-voortgang mogen raadplegen;
• wanneer docenten leerlingen mogen begeleiden;
• wanneer docenten niveauautorisaties mogen toekennen;
• wanneer docenten met elkaar aan onderwijsinhoud mogen samenwerken;
• wanneer beheerders onderling als beheercontext kunnen communiceren.

Een relatie is dus geen vrijblijvende sociale koppeling. Iedere relatietype heeft een eigen functionele betekenis, eigen autorisatiegevolgen, eigen uitnodigingsregels en eigen ontkoppelgedrag.

6.2 Domeinafbakening

Relatiebeheer beschrijft de relatie tussen accounts en rolcontexten. Het domein raakt meerdere andere domeinen, maar vervangt die niet.

Onderwerp	Afbakening
Relaties	Worden vastgelegd in UserRelationships en bepalen zichtbaarheid en toegestane vervolgacties.
Relatie-uitnodigingen	Worden vastgelegd in RelationshipInvitations en leiden pas na acceptatie tot een actieve relatie.
Relatiehistorie	Wordt vastgelegd via RelationshipEvents of een gelijkwaardige audit-/historybron.
Systeemberichten	Worden gebruikt om ontvangen uitnodigingen, acceptaties, afwijzingen en ontkoppelingen aan gebruikers te communiceren.
Privéberichten	Zijn toegestaan op basis van bestaande relatiecontexten, maar worden inhoudelijk uitgewerkt in het berichtendomein.
Oefeningen delen	Gebruikt vriendschap als voorwaarde, maar de gedeelde oefening zelf hoort bij het oefenrun- en delingsdomein.
Docentniveauautorisaties	Vereisen een docent-leerlingrelatie, maar de autorisatie zelf hoort bij docentstructuur en leerlingtoegang.
Ouder-/voogdinzage	Vereist een actieve ouder-/voogdrelatie, maar resultaten en live meekijken worden in de bijbehorende domeinen uitgewerkt.

6.3 Kernobjecten

Object	Betekenis
RelationshipTypes	Definieert toegestane relatietypen zoals Friendship, TeacherStudent, GuardianStudent, TeacherTeacher en AdminAdmin.
RelationshipInvitations	Registreert uitnodigingen voordat een relatie actief wordt.
UserRelationships	Registreert actieve of historisch gedeactiveerde relaties tussen twee gebruikers binnen een relatietype en rol-context-combinatie.
RelationshipEvents	Registreert audit- en gebeurtenisinformatie rond uitnodigingen en relaties.
SystemMessages	Worden gebruikt om gebruikers te informeren of een inkomende uitnodiging als klikbare ingang aan te bieden.

Deze objecten worden bewust gescheiden. Een uitnodiging is geen relatie, een relatie-event is geen systeembericht en een systeembericht is geen autorisatiebron.

6.4 Relatietypen

Relatietype	Partijen	Primair doel	Belangrijke grens
Vriendschap	Leerling - leerling	Oefeningen delen en ondersteunende privéberichten.	Alleen tussen leerlingrolcontexten.
Ouder-/voogdrelatie	Leerling - ouder/voogd	Resultaten, geschiedenis en live meekijken door ouder/voogd.	Ouder/voogd kan geen oefeningen namens het kind uitvoeren.
Docentrelatie	Leerling - docent	Leerling begeleiden en niveauautorisaties toekennen.	Docent ziet alleen gegevens binnen eigen docentcontext.
Docent-docentrelatie	Docent - docent	Samenwerking aan onderwijsinhoud op niveau-laag.	Geeft geen leerling-, resultaat-, geschiedenis- of live-meekijktoegang.
Beheerder-beheerderrelatie	Beheerder - beheerder	Directe beheercontext en communicatie tussen beheerders.	Systeemrelatie; geen vriendschap en geen oefeningdelingsrelatie.

6.5 Algemene modelregels

Relaties worden opgeslagen per relatietype en per rol-context-combinatie.

Daardoor kunnen dezelfde twee natuurlijke personen meerdere actieve relaties met elkaar hebben wanneer die functioneel verschillen.

Voorbeeld:

• persoon A is ouder/voogd van leerling B;
• persoon A is daarnaast docent van leerling B;
• dit zijn twee afzonderlijke relaties;
• acties op de ouder-/voogdrelatie mogen de docentrelatie niet wijzigen;
• acties op de docentrelatie mogen de ouder-/voogdrelatie niet wijzigen.

Voor dezelfde twee gebruikers mag niet meer dan één gelijktijdig actieve relatie bestaan met exact dezelfde combinatie van:

• relatietype;
• eerste gebruiker;
• eerste rolcontext;
• tweede gebruiker;
• tweede rolcontext.

Spiegelbeeldrelaties moeten door applicatielogica of normalisatie eenduidig worden behandeld, zodat dezelfde relatie niet dubbel actief kan ontstaan.

6.6 Aanvullende relatiegrenzen

Relatiebeheer kent geen aparte blokkeerfunctie. Wanneer een gebruiker een relatie beëindigt, ontstaat daardoor geen afzonderlijke blokkeerstatus, blokkadelijst of permanent contactverbod binnen het relatiedomein. Herstel van contact verloopt uitsluitend via de normale uitnodigingsflow en vereist opnieuw acceptatie door de ontvangende partij.

OefenHub hanteert geen functioneel hard maximum op het aantal relaties per gebruiker of per relatietype. Beperkingen ontstaan alleen uit expliciete domeinregels, zoals toegestane rolcontext, accountstatus, bestaande identieke relatie, conflicterende uitnodiging, featurebeschikbaarheid of autorisatie. Overzichten kunnen voor leesbaarheid wel zoeken, filteren, pagineren of lazy loading gebruiken; dat is presentatiegedrag en geen functionele relatiegrens.

Openstaande uitnodigingen en actieve relaties moeten server-side worden gecontroleerd op conflicten. Hieronder vallen ten minste identieke uitnodigingen, spiegelbeeldige uitnodigingen en combinaties die tot twee actieve relaties met dezelfde relatietype- en rolcontextcombinatie zouden kunnen leiden. Conflicten worden veilig geweigerd of naar de bestaande toestand verwezen zonder verborgen account-, rol- of relatiegegevens van derden prijs te geven.

Beheerders kunnen binnen een expliciete beheercontext een relatie geforceerd ontkoppelen wanneer dit nodig is voor support, privacy, misbruikafhandeling of correctie. Deze actie is geen hard delete: de relatie wordt soft gedeactiveerd, de reden is verplicht, actor, rolcontext en tijdstip worden auditbaar vastgelegd en beide betrokken partijen ontvangen systeemcommunicatie over de ontkoppeling, tenzij een partij door accountstatus of anonimisering niet meer regulier bereikbaar is.

6.7 Relatie-uitnodigingen

Handmatige relaties ontstaan via een uitnodigingsproces. Een uitnodiging maakt nooit direct een actieve relatie aan.

De normale lifecycle is:

1. uitnodiging wordt aangemaakt met status Pending;
2. ontvanger ontvangt een systeembericht of gelijkwaardige notificatie;
3. ontvanger accepteert of wijst af;
4. bij acceptatie ontstaat een actieve UserRelationships-relatie;
5. bij afwijzing ontstaat geen relatie;
6. de uitnodiging blijft historisch beschikbaar;
7. de gebeurtenis wordt auditbaar via RelationshipEvents.

De relevante uitnodigingsstatussen zijn:

Status	Betekenis
Pending	Uitnodiging staat open en is nog verwerkbaar.
Accepted	Uitnodiging is geaccepteerd en heeft tot een actieve relatie geleid.
Rejected	Uitnodiging is afgewezen en heeft geen relatie aangemaakt.
Expired	Uitnodiging is verlopen en is niet meer accepteerbaar.

Accepted, Rejected en Expired verdwijnen uit openstaande overzichten, maar blijven historisch herleidbaar.

6.8 Uitnodigingen naar onbekend e-mailadres

Een uitnodiging mag naar een e-mailadres worden verstuurd dat nog niet aan een OefenHub-account gekoppeld is.

In dat geval geldt:

• de uitnodiger krijgt eerst duidelijke feedback dat het e-mailadres nog niet bekend is;
• de uitnodiger moet expliciet bevestigen dat een externe OefenHub-uitnodigingsmail mag worden verstuurd en dat de naam van de uitnodiger in die mail wordt gedeeld;
• vóór het zichtbaar/openstaand vastleggen controleert OefenHub synchroon of de mailvoorbereiding bruikbaar is: actieve template, afzenderconfiguratie en placeholderrendering;
• pas na succesvolle mailvoorbereiding en interne queue-/jobplanning wordt ToEmail vastgelegd, blijft ToUserId leeg zolang geen intern account bestaat en wordt de uitnodiging tijdelijk Pending;
• bij een technische fout in mailvoorbereiding, mailqueue of jobplanning toont OefenHub een veilige foutmelding en blijft er geen zichtbaar openstaand extern relatieverzoek achter;
• bij registratie met hetzelfde genormaliseerde en door de identity provider geverifieerde e-mailadres worden alle geldige pending externe uitnodigingen voor dat e-mailadres aan het nieuwe account gekoppeld;
• dit koppelen is alleen toegestaan zolang de uitnodiging nog geldig is, nog Pending is, niet is ingetrokken/geweigerd/geaccepteerd en nog niet aan een andere gebruiker is gekoppeld;
• koppelen of claimen accepteert de relatie nooit automatisch.

Voor uitnodigingen naar onbekende e-mailadressen geldt een registratiekoppelingstermijn van 7 dagen.

Voor de uitnodiger betekent een succesvolle bevestiging niet dat de ontvanger de e-mail al heeft gelezen of ontvangen. Het betekent dat OefenHub de externe uitnodiging als relatieverzoek heeft vastgelegd en de uitnodigingsmail veilig intern heeft klaargezet voor verzending. De latere SMTP-verwerking en retries horen bij maildelivery; de functionele relatieverzoekstatus blijft leidend.

De SMTP-beveiligingsvorm is omgevingsconfiguratie. OefenHub moet zowel implicit SSL/SMTPS als STARTTLS kunnen gebruiken, zodat dezelfde SMTP-omgeving als externe identity-componenten configureerbaar blijft zonder functionele verschillen voor de gebruiker.

Pas wanneer OefenHub na provisioning over een intern Users.Id beschikt, kan een systeembericht voor de ontvanger worden aangemaakt.

6.9 Inkomende uitnodigingen

De primaire ingang voor ontvangen relatie-uitnodigingen is een systeembericht met een domeinverwijzing naar de uitnodiging.

Inkomende uitnodigingen worden niet als aparte inkomende lijst op de pagina Relaties verzameld.

Dit voorkomt dat de relatiepagina twee verschillende waarheden toont voor dezelfde uitnodigingsflow:

• verzonden openstaande uitnodigingen staan op de relatiepagina;
• ontvangen uitnodigingen worden via systeemberichten aangeboden.

Het openen van een systeembericht verwerkt de uitnodiging niet automatisch. Acceptatie of afwijzing blijft een bewuste actie binnen de relatieflow.

6.10 Accepteren en afwijzen

Bij acceptatie controleert OefenHub server-side of:

• de uitnodiging nog Pending is;
• de uitnodiging bij de ingelogde gebruiker hoort;
• het relatietype nog actief en toegestaan is;
• de doelrol beschikbaar of activeerbaar is;
• er geen actieve identieke relatie bestaat;
• er geen conflicterende relatie- of uitnodigingstoestand bestaat.

Bij succesvolle acceptatie:

• wordt de uitnodiging Accepted;
• ontstaat een actieve UserRelationships-relatie;
• wordt de ontstane relatie aan de uitnodiging gekoppeld;
• ontvangt de uitnodiger een systeembericht of gelijkwaardige notificatie;
• wordt een relatie-event vastgelegd.

Bij afwijzing:

• wordt de uitnodiging Rejected;
• ontstaat geen actieve relatie;
• ontvangt de uitnodiger een systeembericht of gelijkwaardige notificatie;
• wordt een relatie-event vastgelegd.

Accepteren gebeurt direct, tenzij de gebruiker eerst bewust een ontbrekende doelrol moet kiezen of activeren. Afwijzen vraagt altijd een expliciete gebruikershandeling of bevestiging. Een normale afwijzing vraagt geen vrije toelichting of reden, tenzij een specifieke beheer- of supportflow dat expliciet vereist. Bij rol-incompatibele onboardingafsluiting legt OefenHub wel een functionele reden vast, zodat duidelijk is welke gekozen rol niet paste bij het relatieverzoek.

6.11 Openstaande uitnodigingen op de relatiepagina

De relatiepagina toont alleen openstaande uitnodigingen die door de huidige gebruiker zijn verstuurd en binnen de actieve rolcontext zichtbaar horen te blijven.

Een openstaande uitnodiging telt alleen mee wanneer:

• de uitnodiging door de huidige gebruiker is verstuurd;
• de uitnodiging nog Pending is;
• de uitnodiging zichtbaar hoort te blijven in het openstaande uitnodigingenoverzicht;
• de uitnodiging bij de actuele rolcontext hoort.

Afgehandelde, afgewezen, geaccepteerde, verlopen of opgeruimde uitnodigingen blijven historisch herleidbaar, maar worden niet als openstaand item getoond.

Een verzonden openstaande uitnodiging kan door de uitnodigende gebruiker worden ingetrokken zolang de uitnodiging nog Pending is. Intrekken is een destructieve actie en vereist altijd een expliciete bevestiging. Na intrekken verdwijnt de uitnodiging uit het openstaande overzicht en kan de ontvanger de uitnodiging niet meer accepteren.

Een verzonden openstaande uitnodiging kan worden herinnerd zolang de uitnodiging nog Pending is en de herinnercooldown is verstreken. De cooldown wordt beheerbaar vastgelegd in admin.SystemSettings met de sleutel RelationshipInvitationReminderCooldownHours en start met een standaardwaarde van 24 uur. Zolang de cooldown niet is verstreken, blijft de herinneractie zichtbaar maar niet uitvoerbaar en toont de pagina waarom de gebruiker nog moet wachten. Een herinnering hergebruikt de oorspronkelijke notificatiepoging niet: bestaande OefenHub-gebruikers krijgen een nieuw systeembericht, externe e-mailadressen krijgen een nieuwe mailaanvraag.

6.12 Relatiepagina

De pagina Relaties is een gebruikergebonden overzichts- en mutatiepagina binnen de profielcontext.

De pagina toont afhankelijk van rolcontext en beschikbare relaties onder meer:

• vrienden;
• ouders/voogden;
• docenten;
• openstaande door de gebruiker verstuurde uitnodigingen;
• samenvattingsaantallen;
• toegestane vervolgacties;
• lege toestanden;
• bevestigingsmodals voor ontkoppelen of ontkoppelverzoeken.

De pagina toont uitsluitend relaties en uitnodigingen die bij de ingelogde gebruiker horen. Een gebruiker mag via deze pagina geen relaties van andere gebruikers bekijken, ook niet wanneer er een familie-, docent- of vriendschapscontext bestaat.

Alle namen, aantallen, datums, badges, relatieaantallen en uitnodigingswaarden zijn dynamische waarden en mogen niet uit mockups worden overgenomen.

6.13 Vriendschappen

Een vriendschap is uitsluitend bedoeld voor leerling-leerlingrelaties.

Het primaire doel is:

• oefeningen delen;
• gedeelde oefeningen ontvangen;
• ondersteunende privéberichten binnen de relatiecontext.

OefenHub is geen algemeen sociaal platform. Vriendschap heeft binnen OefenHub alleen functionele betekenis voor toegestane communicatie en oefeningdeling.

Een vrienduitnodiging mag alleen vanuit actieve leerlingcontext worden gestart. De uitnodiging eindigt met Status = Pending; de vriendschap ontstaat pas na acceptatie door de ontvanger.

Wanneer een vriendschap wordt beëindigd:

• wordt de relatie soft gedeactiveerd;
• toekomstige oefeningdeling op basis van die relatie stopt;
• toekomstige privéberichttoegang kan vervallen volgens de berichtenregels;
• reeds gedeelde oefeningen en afgeronde runs worden niet verwijderd;
• historie en relatie-events blijven beschikbaar.

6.14 Ouder-/voogdrelaties

Een ouder-/voogdrelatie verbindt een leerling met een gebruiker in ouder-/voogdrolcontext.

Deze relatie is de primaire autorisatiebron voor ouder-/voogdfunctionaliteit.

Een actieve ouder-/voogdrelatie is vereist voor:

• kinderenoverzicht;
• kindinformatie;
• resultatenoverzicht;
• geschiedenis;
• resultaatdetail;
• PDF-export;
• online-overzicht;
• live meekijken.

De ouder-/voogdrelatie geeft geen recht om:

• oefeningen namens het kind te starten;
• oefeningen namens het kind te hervatten;
• antwoorden te geven;
• scores of voortgang te wijzigen;
• oefeningen opnieuw te maken;
• oefeningen te delen;
• resultaatdata te corrigeren.

Na ontkoppeling vervalt reguliere ouder-/voogdinzage direct voor nieuwe raadpleeg-, detail-, export- en liveacties. Historische oefenruns, resultaten, auditregels en PDF-brondata blijven bestaan, maar worden niet meer aan de ontkoppelde ouder/voogd getoond.

6.15 Docentrelaties

Een docentrelatie verbindt een leerling met een gebruiker in docentrolcontext.

De docentrelatie is voorwaarde voor docentgerichte leerlingbegeleiding, maar niet hetzelfde als niveauautorisatie.

Een docent-leerlingrelatie maakt onder voorwaarden mogelijk:

• leerling in docentcontext bekijken;
• leerling aan een niveau koppelen;
• leerling van een niveau ontkoppelen;
• resultaten binnen docentcontext raadplegen;
• geschiedenis binnen docentcontext raadplegen;
• live meekijken binnen docent- en niveauautorisatiegrenzen.

Bij beëindiging van een docentrelatie worden de aan die relatie gekoppelde niveauautorisaties beëindigd of ingetrokken volgens de docentstructuurregels.

De leerling mag een docentrelatie niet zomaar direct verbreken wanneer daarvoor een verzoekflow geldt. Directe ontkoppeling en ontkoppelverzoek worden per relatietype en rolcontext bepaald.

6.16 Docent-docentrelaties

Een docent-docentrelatie verbindt twee gebruikers in docentrolcontext.

Het doel is samenwerking aan onderwijsinhoud, vooral op niveau-laag.

Een docent-docentrelatie kan nodig zijn voor:

• collaborators op een niveau;
• samenwerken aan categorieën en oefeningen binnen dat niveau;
• eigenaarschapsoverdracht naar een geldige collaborator;
• docentgerichte privécommunicatie waar toegestaan.

Een docent-docentrelatie geeft nadrukkelijk geen toegang tot:

• leerlingen van de andere docent;
• resultaten van leerlingen van de andere docent;
• geschiedenis van leerlingen van de andere docent;
• live meekijken met leerlingen van de andere docent.

Bij beëindiging van een docent-docentrelatie worden actieve samenwerkingskoppelingen op niveau-laag tussen deze twee docenten administratief gedeactiveerd volgens de collaboratorregels. Historische eigendomsoverdrachten blijven geldig.

6.17 Beheerder-beheerderrelaties

Een beheerder-beheerderrelatie is een systeemrelatie tussen twee gebruikers met een actieve beheerdersrol.

Deze relatie ondersteunt:

• directe beheercontext;
• samenwerking tussen beheerders;
• privéberichten tussen beheerders zonder aparte vriendschap.

AdminAdmin is geen handmatige uitnodigingsrelatie en gebruikt geen acceptatieflow.

Zolang beide gebruikers een actieve beheerdersrol hebben:

• blijft de relatie functioneel actief;
• is de ontkoppelactie in de GUI uitgeschakeld;
• wordt toegelicht dat de koppeling automatisch actief blijft zolang beide partijen beheerder zijn.

Wanneer één van beide gebruikers geen beheerder meer is, blijft de relatie historisch bestaan maar kan de ontkoppelactie beschikbaar worden volgens de beheerregels. De relatie wordt niet automatisch omgezet naar vriendschap of een ander relatietype.

6.18 Ontkoppelen

Ontkoppelen is een administratieve deactivatie van een relatie en geen hard delete.

Direct ontkoppelen betekent:

• UserRelationships.IsActive = false;
• DeactivatedAtUtc wordt gevuld;
• DeactivatedByUserId wordt gevuld;
• waar relevant wordt een reden vastgelegd;
• er wordt een RelationshipEvents-regel vastgelegd;
• de andere partij wordt geïnformeerd via systeembericht of gelijkwaardige communicatie;
• toekomstige relatieafhankelijke toegang vervalt.

Een ontkoppelactie of ontkoppelverzoek opent altijd eerst een bevestigingsmodal.

Relatiehistorie, bestaande berichten, gedeelde oefeningen, historische runs, auditregels en relevante contextrecords worden niet fysiek verwijderd.

6.19 Direct ontkoppelen versus ontkoppelverzoek

Niet ieder relatietype mag door iedere betrokken gebruiker direct worden beëindigd.

Relatietype	Direct ontkoppelen	Ontkoppelverzoek
Vriendschap	Beide leerlingen mogen direct beëindigen na bevestiging.	Niet nodig voor de standaardflow.
Ouder-/voogdrelatie	Ouder/voogd mag direct beëindigen.	Leerling kan hoogstens een verzoek starten wanneer directe beëindiging niet is toegestaan.
Docentrelatie	Docent mag direct beëindigen.	Leerling kan hoogstens een verzoek starten wanneer directe beëindiging niet is toegestaan.
Docent-docentrelatie	Beide docenten mogen direct beëindigen.	Niet nodig voor de standaardflow.
Beheerder-beheerderrelatie	Geblokkeerd zolang beide gebruikers actief beheerder zijn.	Niet van toepassing zolang de systeemrelatie functioneel verplicht is.

Ontkoppelen mag alleen door een betrokken partij in een geldige rolcontext of door een expliciet geautoriseerde beheerflow.

6.20 Gevolgen van ontkoppeling

Ontkoppeling beëindigt toekomstige relatieafhankelijke toegang. De gevolgen verschillen per relatietype.

Relatietype	Belangrijkste gevolgen
Vriendschap	Toekomstig delen en relatiegebaseerde privécommunicatie kunnen vervallen. Reeds gedeelde oefeningen en afgeronde runs blijven bestaan.
Ouder-/voogdrelatie	Nieuwe ouder-/voogdinzage, PDF-export en live meekijken vervallen direct. Historische runs blijven bestaan.
Docentrelatie	Aan de docentrelatie gekoppelde niveauautorisaties vervallen of worden ingetrokken volgens docentstructuurregels.
Docent-docentrelatie	Actieve collaborator-koppelingen tussen de docenten worden gedeactiveerd.
Beheerder-beheerderrelatie	Communicatie- en beheercontext volgen de actuele beheerdersrolstatus en beheerregels.

Ontkoppeling herschrijft geen historische berichten, oefenruns, gedeelde oefeningen, resultaten, PDF-brondata of auditrecords.

6.21 Relatie als autorisatiebron

Een relatie kan autorisatie mogelijk maken, maar is meestal niet de enige voorwaarde.

Voorbeelden:

• een ouder-/voogdrelatie is vereist voor ouder-/voogdinzage, maar iedere detail- en exportactie herhaalt de controle;
• een docent-leerlingrelatie is vereist voor docentniveauautorisatie, maar resultaatinzage blijft begrensd tot de eigen docentcontext;
• een docent-docentrelatie is nodig voor collaboration, maar collaboratorstatus op een concreet niveau bepaalt de bewerkcontext;
• een vriendschap is vereist voor delen, maar de deelactie controleert ook featurestatus en deelbaarheid van de oefening;
• een AdminAdmin-relatie ondersteunt beheerdercommunicatie, maar verleent geen extra leerling- of oefenrechten.

Een relatiekaart, knop of zichtbaar menu-item is nooit autorisatiebewijs. Iedere vervolgactie controleert server-side opnieuw actor, rolcontext, relatietype, relatie-/uitnodigingsstatus en relevante domeincontext.

6.22 Relatie-events en audit

RelationshipEvents vormen de gebeurtenissen- en auditlaag voor relatiebeheer.

Voorbeelden van eventtypes zijn:

• uitnodiging verzonden;
• uitnodiging geaccepteerd;
• uitnodiging afgewezen;
• uitnodiging verlopen;
• relatie geactiveerd;
• relatie gedeactiveerd;
• ontkoppelverzoek gestart;
• systeemrelatie aangemaakt;
• systeemrelatie niet langer verplicht;
• relatieactie geweigerd.

RelationshipEvents zijn geen vervanging voor systeemberichten. Systeemberichten informeren gebruikers; events maken de relatiegeschiedenis technisch en functioneel herleidbaar.

Events worden niet gebruikt om autorisatie zelfstandig te bepalen. De actuele relatie- en rolcontext blijft leidend.

6.23 Relatiebeheer en communicatie

Relatiebeheer raakt het communicatiegedrag binnen OefenHub.

Een relatie kan bepalen of een gebruiker:

• een privébericht mag sturen;
• een systeembericht ontvangt;
• een uitnodiging kan accepteren of afwijzen;
• geïnformeerd wordt over ontkoppeling;
• een gedeelde oefening kan ontvangen;
• relatieafhankelijke acties kan starten.

Privéberichten zelf blijven onderdeel van het berichtendomein. Een relatie bepaalt hoogstens of de communicatie toegestaan is; de inhoud, threadstructuur, readstate, retentie en verwijderregels horen bij berichten.

6.24 Lege toestanden en fouttoestanden

Lege toestanden zijn normaal wanneer de gebruiker wel toegang heeft tot de relatiepagina maar geen relaties of uitnodigingen heeft.

Voorbeelden:

• geen vrienden;
• geen ouders/voogden;
• geen docenten;
• geen openstaande verstuurde uitnodigingen;
• geen relaties binnen een bepaalde rolcontext.

Fouttoestanden ontstaan wanneer:

• de gebruiker een relatie van iemand anders probeert te openen;
• een uitnodiging al verwerkt of verlopen is;
• een relatie al ontkoppeld is;
• de rolcontext niet past bij de actie;
• een duplicate of conflicterende uitnodiging bestaat;
• het relatietype niet actief of niet toegestaan is;
• een gemanipuleerde route of request een niet-toegestane actie probeert uit te voeren.

Bij fouttoestanden wordt geen gedeeltelijke relatie- of persoonsgegevensset getoond buiten de toegestane context.

6.25 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — relatiebeheer	Relatiebeheer, uitnodigingen en gedeelde oefeningen
Technisch Ontwerp — communicatie	Berichten, systeemberichten, notificaties en privéthreads
Usecases — relaties	Relaties
UC-GEN-REL-001 — Relaties bekijken	Relaties bekijken
UC-GEN-REL-002 — Vriend uitnodigen	Vriend uitnodigen
UC-GEN-REL-003 — Ouder/voogd uitnodigen	Ouder/voogd uitnodigen
UC-GEN-REL-004 — Relatie ontkoppelen	Relatie ontkoppelen
UC-GEN-REL-005 — Relatie-uitnodiging accepteren of afwijzen	Relatie-uitnodiging accepteren of afwijzen
Schermdocumentatie — relaties	Relaties
Database-informatie — relatiebeheer	Relatiebeheer
Database-informatie — docentstructuur en leerlingtoegang	Docentstructuur en leerlingtoegang
Database-informatie — communicatie en notificaties	Communicatie en notificaties
Ontwerpbron — business rules	Business rules
Ontwerpbron — statusmodellen	Statusmodellen
Ontwerpbron — event-register	Event-register
FO — rollen, context en autorisatie	Rollen, context en autorisatie
FO — berichten, communicatie en notificaties	Berichten, communicatie en notificaties
FO — gedeelde oefeningen	Gedeelde oefeningen
FO — docentfunctionaliteit	Docentfunctionaliteit
FO — ouder-/voogdfunctionaliteit	Ouder-/voogdfunctionaliteit
FO — live meekijken	Live meekijken

6.x Externe uitnodigingen na registratie en onboarding

Externe relatie-uitnodigingen naar nog onbekende e-mailadressen worden na registratie niet automatisch geaccepteerd. Registratie via een uitnodigingsmail betekent alleen dat de gebruiker OefenHub kan bereiken en dat pending uitnodigingen voor het geverifieerde e-mailadres aan het interne account kunnen worden gekoppeld.

Claimregels:

• OefenHub claimt pending externe uitnodigingen op basis van genormaliseerd, geverifieerd e-mailadres.
• Alle pending uitnodigingen voor dat e-mailadres worden geclaimd, niet alleen de uitnodiging waarvan de gebruiker toevallig de mail heeft geopend.
• De uitnodiging blijft Pending totdat de ontvanger expliciet accepteert of weigert.
• Uitnodigingen die niet passen bij de gekozen rol worden afgesloten met een expliciete rol-incompatibiliteitsreden en blijven niet openstaan.
• De uitnodiger krijgt pas definitieve functionele terugkoppeling bij acceptatie, weigering, intrekking of verlopen van de uitnodiging.

Tijdens eerste onboarding is de relatie-uitnodigingenstap verplicht wanneer er compatibele geclaimde uitnodigingen openstaan. De rolkeuzepagina informeert de gebruiker dat er uitnodigingen klaarstaan en dat een rolkeuze gevolgen kan hebben voor uitnodigingen die niet bij die rol passen.

Na afgeronde onboarding worden nieuwe uitnodigingen niet meer verplicht via de onboardingpagina afgehandeld. Zij worden dan via mailbox, systeemberichten of de relatiepagina zichtbaar gemaakt.

Herinneren na claimen

De herinnerfunctie kijkt altijd naar de actuele status van de uitnodiging op het moment van herinneren:

Actuele toestand	Reminder-kanaal
Extern, geen gekoppelde gebruiker	Nieuwe mailattempt met Purpose = Reminder.
Inmiddels gekoppeld aan bestaande OefenHub-gebruiker	Intern systeembericht.
Geaccepteerd, geweigerd, ingetrokken of verlopen	Herinneren is niet toegestaan.
Binnen cooldown	Herinneren is niet toegestaan; UI toont wanneer het weer kan.

De oorspronkelijke aanmaakwijze bepaalt dus niet blijvend het kanaal. Zodra een externe uitnodiging is geclaimd door een account, wordt een herinnering behandeld als interne OefenHub-notificatie.