Eigenaarschap van resources in een SaaS: persoon, organisatie of werkruimte

In een SaaS waarin iemand in meerdere organisaties of werkruimten kan werken, geeft ‘wie heeft deze resource aangemaakt?’ niet automatisch antwoord op ‘van wie is deze?’. Dat verschil bepaalt wie de resource kan bekijken, wijzigen of overdragen, en wie deze kan behouden wanneer iemand een team verlaat. Als je dit pas laat oplost, raken de regels vaak verspreid over queries, controllers en achtergrondtaken.

Eigenaarschap van resources in een SaaS voor meerdere gebruikers is een domeinbeslissing: het bepaalt welke entiteit de primaire relatie met een resource heeft en welke gevolgen die relatie heeft. Het is geen synoniem voor authenticatie, lidmaatschap of rechten. Door dit expliciet te modelleren, kunnen product, data en code dezelfde consistente regel hanteren.

Identiteit, lidmaatschap en eigenaarschap zijn verschillende relaties

Een gebruiker vertegenwoordigt een identiteit waarmee iemand kan inloggen. Een lidmaatschap geeft aan dat die identiteit deelneemt aan een organisatie of werkruimte, mogelijk met een rol of status. Eigenaarschap geeft aan welke entiteit volgens de productregels verantwoordelijk is voor een resource. Iemand kan lid zijn van meerdere werkruimten en tegelijk een document aanmaken dat bij een van die werkruimten hoort.

Het is ook verstandig om auteurschap apart te houden. Het veld created_by kan vastleggen wie de oorspronkelijke handeling heeft uitgevoerd, maar mag op zichzelf niet bepalend zijn voor het eigenaarschap. Als de gebruiker die de registratie heeft aangemaakt de organisatie verlaat, kan de resource nog steeds van die organisatie zijn. Omgekeerd kan iemand een resource overnemen die oorspronkelijk door een ander is aangemaakt.

Leg de antwoorden op drie vragen vast: wie is de eigenaar, wie mag de resource gebruiken en wie heeft elke relevante handeling uitgevoerd? Als hetzelfde veld of dezelfde relatie al deze vragen moet beantwoorden, vermengt het model waarschijnlijk verschillende begrippen.

Kiezen tussen persoonlijk, organisatorisch of gedeeld eigenaarschap

• Persoonlijk: de resource is eigendom van een gebruiker. Dit past wanneer de levenscyclus ervan die persoon volgt en niet een team, zoals bij een privévoorkeur. Bepaal wat er gebeurt als het account wordt gedeactiveerd of verwijderd.
• Organisatorisch: de resource is eigendom van een organisatie of werkruimte. Dit is geschikt wanneer de resource beschikbaar moet blijven voor het team, ook als de samenstelling verandert. Het lidmaatschap van de gebruiker verleent toegang, maar maakt die gebruiker niet tot individuele eigenaar.
• Gedeeld: meerdere entiteiten kunnen een eigendoms- of verantwoordelijkheidsrelatie hebben. Gebruik dit alleen als het domein daadwerkelijk mede-eigenaarschap vereist. Als meerdere personen de resource moeten kunnen bekijken of bewerken, gaat het doorgaans om toegang via lidmaatschappen of rechten, niet om meerdere eigenaren.

De keuze moet aansluiten op de levenscyclus van de resource en de bedrijfsregels, niet op een voorkeur voor een eenvoudigere tabel. Vraag wie de resource mag behouden, over verwijdering mag beslissen en ervoor verantwoordelijk is wanneer het team verandert. Maak ook onderscheid tussen ‘werkruimte’ en ‘organisatie’: als de werkruimte een echte onderverdeling is met een eigen levenscyclus en grenzen, kan die de juiste eigenaar zijn; is het slechts een weergave of navigatiecontext, dan misschien niet.

Het domein weergeven zonder de eigenaar af te leiden

In een eenvoudig model kan een tabel voor resources een expliciete eigenaar bevatten, bijvoorbeeld owner_type en owner_id, of aparte verwijzingen zoals user_id en organization_id. De eerste optie kan ondersteuning voor meerdere typen eigenaren vereenvoudigen, maar vereist validatie van verwijzingen en aandacht voor de beperkingen van referentiële integriteit bij polymorfe relaties. Met aparte verwijzingen zijn de koppelingen explicieter, maar moet je ongeldige combinaties voorkomen.

Een andere mogelijkheid is een gemeenschappelijke entiteit, bijvoorbeeld workspace, als het domein zowel persoonlijke accounts als teams daadwerkelijk onder die entiteit schaart. Introduceer die niet alleen om verschillen te verbergen: de entiteit moet een eigen betekenis en stabiele regels hebben. Stel bij elk ontwerp beperkingen in die voorkomen dat een resource tegelijk aan onverenigbare eigenaren is gekoppeld, of aan geen enkele eigenaar wanneer eigenaarschap verplicht is.

Modelleer lidmaatschappen apart, bijvoorbeeld met een relatie tussen gebruiker en organisatie die een status en rol bevat. De actieve context van de interface kan aangeven waar iemand op dat moment werkt, maar is geen afdoende autoriteit: valideer deze bij elke bewerking. Bereken de eigenaar ook niet als ‘degene die de resource heeft aangemaakt’ of als ‘de momenteel geselecteerde organisatie’.

Eigenaarschap toepassen op lees- en schrijfbewerkingen en automatische processen

Queries moeten de eigendomscontext meenemen en een passende toegangscontrole uitvoeren. Het is niet voldoende om een resource op basis van de identificatie op te halen en erop te vertrouwen dat de interface resources verbergt waartoe iemand geen toegang heeft. Centraliseer in een PHP-applicatie de contextresolutie en autorisatieregels in een herbruikbare laag, en voorkom dat je onvolledige voorwaarden in elke controller kopieert.

Valideer bij schrijfbewerkingen de toegestane eigenaar en het actuele lidmaatschap van de actor. Controleer ook of gerelateerde resources — zoals een doelmap — bij een compatibele context horen; anders kan een update koppelingen tussen verschillende contexten aanmaken. Maak voor administratieve bewerkingen expliciet onderscheid tussen uitzonderlijke autorisatie en de gewone regels, en registreer wie de bewerking heeft uitgevoerd en waarom.

Queues, geplande commando’s, webhooks en imports hebben niet altijd een interactieve gebruiker. Ze moeten een gevalideerde eigenaar- of contextidentificatie meekrijgen, in plaats van afhankelijk te zijn van een impliciete sessie. Het proces moet dezelfde contextregels toepassen als de webapplicatie. Als het met verhoogde rechten werkt, beperk en controleer die rechten dan.

Behandel overdracht als een domeinbewerking

De eigenaar wijzigen hoort geen algemene veldbewerking te zijn. Definieer precondities: wie de overdracht kan starten, welke relatie de ontvanger met de werkruimte moet hebben en wat er gebeurt bij een openstaande uitnodiging of een inactief account. Wanneer de bewerking meerdere relaties en bijbehorende effecten bijwerkt, moet deze atomair zijn.

Bepaal ook wat er gebeurt met afhankelijkheden, zoals bestanden, integraties, facturering of automatiseringen. Ga er niet van uit dat alles samen met de resource moet worden overgedragen: dat beleid hangt af van het product. Als niet alle wijzigingen in één transactie kunnen worden voltooid, ontwerp dan een herstelbaar proces met duidelijke statussen en idempotentie voor nieuwe pogingen.

Bewaar waar relevant een auditlog met de actor, de vorige eigenaar, de nieuwe eigenaar, het tijdstip en de reden. Zo kun je onderscheiden wie de wijziging heeft geautoriseerd van wie de technische handeling heeft uitgevoerd. Het oorspronkelijke auteurschap kan ongewijzigd blijven, ook als het eigenaarschap verandert.

Test de grenzen die modelfouten blootleggen

Automatiseer service- en integratietests om zowel toegestane als geweigerde toegang te verifiëren. Een nuttige testmatrix bevat een gebruiker in twee organisaties, eigen en andermans resources in beide organisaties, opgeschorte of ingetrokken lidmaatschappen, overdracht aan een niet-geschikte bestemming en toegang via bekende identificaties. Controleer de reacties en de effecten op de data; een knop verbergen is geen autorisatietest.

Test ook resources zonder geldige eigenaar, dubbele relaties en fouten tijdens een overdracht. Als het schema een eigenaar vereist, moeten databasebeperkingen die verwachting ondersteunen. Migraties moeten inconsistente historische records opsporen voordat je die beperkingen toevoegt. Controleer voor achtergrondtaken of de context behouden blijft en of een nieuwe poging geen wijzigingen dupliceert.

Checklist voordat je de SaaS uitbreidt

• Is voor elk type resource bepaald of deze toebehoort aan een persoon, organisatie of werkruimte?
• Zijn eigenaarschap, auteurschap, lidmaatschap, rol en actieve context van elkaar onderscheiden?
• Valideren lees- en schrijfqueries de eigenaar en het actuele lidmaatschap?
• Krijgen automatische taken een expliciete context mee en passen ze gelijkwaardige controles toe?
• Heeft de overdracht precondities, gedefinieerde effecten, auditing en een herstelstrategie?
• Zijn er tests voor gebruikers met meerdere werkruimten, vertrek, toegang tussen contexten en inconsistente data?

Als een antwoord afhangt van ongedocumenteerde conventies, is het verstandig die te verduidelijken voordat je meer typen resources of samenwerkingsflows toevoegt. Een expliciet model elimineert niet alle complexe gevallen, maar maakt beslissingen zichtbaar en controleerbaar in het schema, de queries en de tests.