In een WooCommerce-winkel met meerdere operationele profielen volstaat «toegang tot het dashboard geven» niet om te bepalen wie wat mag doen. Een supportmedewerker moet misschien bestellingen kunnen bekijken, maar geen terugbetalingen kunnen uitvoeren; iemand van het catalogusteam kan producten bewerken, maar geen wijzigingen publiceren. En een bedrijfsregel — bijvoorbeeld beperken welke bestellingen elk team kan zien — komt mogelijk niet overeen met een standaardrecht.
Rollen en rechten ontwerpen in WooCommerce vereist dat je die niveaus van elkaar onderscheidt, acties en resources specificeert en zowel toegestane als geweigerde handelingen controleert. Het doel is om minimale toegang te verlenen waarmee mensen hun werk kunnen doen, zonder legitieme taken te blokkeren of afhankelijk te zijn van geïmproviseerde regels.
Rollen, capabilities en bedrijfsregels van elkaar onderscheiden
Een rol groepeert rechten voor een bepaald type gebruiker. Een capability geeft een actie aan die het systeem kan toestaan, zoals producten bewerken of bepaalde WooCommerce-opties beheren. De rol bepaalt welke capabilities een gebruiker heeft; de rol mag niet worden gebruikt als vervanging voor elke afzonderlijke regel.
De beschikbare capabilities zijn afhankelijk van WordPress, WooCommerce en de geïnstalleerde extensies. Namen die je kunt tegenkomen zijn onder meer manage_woocommerce, view_woocommerce_reports en capabilities die bij producten of bestellingen horen. Leid het effect ervan niet alleen af uit de naam: controleer hoe de installatie ze gebruikt en welke bewerkingen ze mogelijk maken.
Een bedrijfsregel voegt context toe die een algemeen recht niet noodzakelijk weergeeft. Bijvoorbeeld: een medewerker toestaan bestellingen van het eigen team te bekijken, maar niet die van andere teams. Het recht om bestellingen te bewerken bepaalt op zichzelf niet deze beperking per resource. Verwar toegangsbeperkingen ook niet met workflowcontroles, zoals goedkeuring vereisen voordat een status wordt gewijzigd.
Breng acties en resources in kaart voordat je rechten toewijst
Begin met het beschrijven van het daadwerkelijke werk van elk profiel. Identificeer voor elke actie de betrokken resource en de relevante context. Vermijd vage categorieën zoals «de winkel beheren»: die maken het moeilijk om rechten te controleren en verhullen vaak onnodige toegang.
- Support: bestellingen bekijken, toegestane informatie bijwerken, notities toevoegen of volgens het afgesproken proces een retour starten.
- Catalogus: producten aanmaken en bewerken, afbeeldingen of categorieën beheren en, indien van toepassing, wijzigingen publiceren.
- Beheer: instellingen, gebruikers en financiële handelingen beheren die onder de eigen verantwoordelijkheid vallen.
Deze voorbeelden zijn uitgangspunten, geen universele rechtenverdeling. Een bruikbare matrix vermeldt het profiel, de actie, het type resource, de gegevensomvang, de voorwaarden en het verwachte resultaat. Geef ook aan of een actie bekijken, aanmaken, bewerken, publiceren, verwijderen of exporteren toestaat, of een onomkeerbare bewerking uitvoert.
Bijvoorbeeld: bij «bestellingen bekijken» moet duidelijk zijn of het om alle bestellingen gaat, alleen de toegewezen bestellingen, volledige persoonsgegevens of een beperkte weergave. Bij «product bewerken» moet worden aangegeven of dit ook het wijzigen van de prijs, voorraad, zichtbaarheid of publicatiestatus omvat. Duidelijkheid voorkomt dat twee teams hetzelfde recht verschillend interpreteren.
Stel een matrix op die rekening houdt met risico's en context
Markeer voor elke combinatie van profiel en actie of de actie is toegestaan, geweigerd of aan een voorwaarde is gebonden. Voeg een zakelijke reden toe en vermeld wie verantwoordelijk is voor het goedkeuren van de toegang. Neem gevoelige bewerkingen op: terugbetalingen, prijswijzigingen, export van persoonsgegevens, verwijdering van records en aanpassingen van betalings- of belastinginstellingen.
Een minimale matrix moet antwoord geven op de volgende vragen:
- Welke actie is nodig om het proces te voltooien?
- Op welk type resource is de actie van toepassing en welke records vallen binnen de scope?
- Geldt er een voorwaarde, zoals lidmaatschap van een team of vereiste goedkeuring?
- Wat is de impact van een fout of misbruik van het recht?
- Hoe wordt de toegang gecontroleerd en ingetrokken wanneer de functie verandert?
Houd rekening met functiescheiding wanneer één persoon een risicovolle handeling niet zowel mag starten als goedkeuren. Als WooCommerce of de geïnstalleerde extensies deze scheiding niet bieden, leg de beperking dan vast en onderzoek een expliciete oplossing; ga er niet van uit dat je dit oplost door simpelweg een andere rol aan te maken.
Bepaal waar je elke regel implementeert
Controleer eerst of een bestaande capability de vereiste actie goed weergeeft. Als dat zo is, wijs die dan via een onderhoudbare tool of methode toe aan de juiste rol en test het resultaat in het dashboard en op de relevante operationele routes. Controleer ook de rechten die door andere extensies worden verleend: effectieve rollen kunnen capabilities uit verschillende bronnen combineren.
Als de regel een nieuwe capability vereist of afhankelijk is van specifieke gegevens — bijvoorbeeld het team dat aan een bestelling is toegewezen — implementeer die dan in een eigen extensie of een onderhoudbaar component, niet via geïmproviseerde wijzigingen aan het thema. Een thema bepaalt de presentatie; autorisatie daaraan koppelen kan ertoe leiden dat de regel verdwijnt wanneer het thema wordt gewijzigd of moeilijk te vinden en te testen is.
De implementatie moet de toegang controleren op het punt waar de bewerking wordt uitgevoerd, niet alleen knoppen verbergen. Een optie verbergen verbetert de interface, maar voorkomt op zichzelf niet dat een direct verzoek een beveiligde actie bereikt. Controleer bij regels voor resources bovendien of de gebruiker op dat specifieke record mag handelen. Houd de controle van de algemene capability gescheiden van de controle van de scope van de resource.
Vermijd het toekennen van ruime capabilities om een integratie te compenseren die niet werkt zoals verwacht. Bepaal voordat je rechten uitbreidt welke controle faalt, welk component die uitvoert en of de bewerking toegestaan zou moeten zijn. Een ruime uitzondering kan meer schermen of acties beschikbaar maken dan bedoeld.
Test verleende rechten en weigeringen
Tests moeten het gedrag aantonen en niet alleen bevestigen dat een rol in de configuratie voorkomt. Maak testgevallen voor de relevante profielen en controleer toegestane en verboden acties en contextuele grenzen. Als een actie afhankelijk is van de status van een bestelling, het team of een andere voorwaarde, test dan zowel een geval waarin aan de voorwaarde wordt voldaan als een geval waarin dat niet zo is.
- Een supportgebruiker bekijkt een bestelling waarvoor diegene bevoegd is en kan geen bestelling buiten de eigen scope bekijken.
- Een catalogusprofiel bewerkt de beoogde velden, maar krijgt zonder toestemming geen toegang tot bestel- of winkelinstellingen.
- Een persoon zonder rechten kan de bewerking niet uitvoeren via een URL of direct verzoek, ook al ziet diegene de knop niet.
- Gevoelige bewerkingen leveren het verwachte resultaat op en omzeilen geen goedkeuringen of vastgelegde beperkingen.
Voer de controles uit in een representatieve testomgeving, met accounts voor elk profiel en gegevens die de relevante grenzen weerspiegelen. Herhaal de testgevallen na updates van WooCommerce, WordPress of extensies die betrokken zijn bij bestellingen, producten en rollen. Leg het verwachte en waargenomen resultaat vast, zodat toekomstige wijzigingen niet per ongeluk opnieuw toegang verlenen.
Controleer de operationele impact en audit wijzigingen
Een te restrictief recht kan het werk ook verstoren: het kan bijvoorbeeld voorkomen dat support een bestelling vindt of dat het catalogusteam een urgente correctie publiceert. Spreek vóór het doorvoeren van wijzigingen af hoe tijdelijke toegang wordt aangevraagd, wie die goedkeurt en hoe deze wordt ingetrokken. Controleer volledige workflows met de mensen die de taken uitvoeren, niet alleen afzonderlijke schermen.
Documenteer welke rol elke capability verleent, welke aanvullende regels de toegang beperken en welk component deze implementeert. Houd een wijzigingslogboek bij van rollen en rechten, met verantwoordelijke, reden en datum, en controleer periodiek welke accounts geen toegang meer nodig hebben. Onderzoek bij een onverwachte weigering de effectieve capability, de regels voor de resource, de betrokken extensies en de context van het verzoek voordat je een ruimer recht verleent.
Een solide configuratie van rollen en rechten in WooCommerce begint met toetsbare acties, houdt bedrijfsregels op een onderhoudbare plek en toont met tests aan wie wat kan doen. Zo bescherm je de winkel zonder dat elk operationeel incident leidt tot een permanente uitbreiding van de toegang.
