Kennisbank
Rollen en rechtenniveaus
Een rol zegt wat iemand mag doen; een adrestoekenning zegt waarop diegene dat mag doen.
Details
- Twee toekenningen per persoon, en allebei moeten het eens zijn voordat er iets gebeurt. De ROL, ingesteld in Instellingen → Leden, zegt wat iemand in de werkruimte mag DOEN: post lezen, post versturen, sjablonen bewerken, een domein toevoegen, een API-sleutel slaan. De ADRESTOEKENNING, ingesteld via de knop Delen op de adresregel, zegt op welke ADRESSEN diegene dat mag doen, als alleen-lezen of als lezen-en-versturen. Wie een rol met versturen erin heeft en geen adressen, kan vanaf niets versturen; wie elk adres in de werkruimte onder een alleen-lezen-toekenning heeft, kan vanaf geen enkel adres versturen.
- Zes rollen bestaan zonder dat iemand ze aanmaakt, en elke werkruimte heeft dezelfde zes, dus “Admin” betekent hier hetzelfde als in de documentatie en op de API. Owner, Admin, Member en Viewer vormen een ladder: elke rol bevat alles wat de volgende heeft, dus iemand degraderen versmalt wat diegene kan bereiken in plaats van het te ruilen voor een andere snede. Developer en Billing zijn geen treden op die ladder. Developer bouwt integraties, met API-sleutels, webhooks, sjablonen en versturen, zonder ook maar iets van de post van de werkruimte te lezen, en Billing ziet het plan en de facturen, kan het plan en de betaalgegevens erop wijzigen, en leest mailboxinstellingen zonder er een te kunnen schrijven. Hun rechten zijn bewerkbaar: een werkruimte die liever niet heeft dat haar leden sjablonen schrijven, vinkt dat uit, en de wijziging landt bij het volgende verzoek van iedereen die die rol EXPLICIET heeft. Wie zijn rol nog altijd ontleent aan een adrestoekenning van voordat rollen bestonden, houdt de meegeleverde standaardwaarden tot hij er ronduit een krijgt. Hun namen zijn dat ook: een werkruimte die op Ops en On-call draait, hernoemt ze en beschrijft daarmee zichzelf, en dat is precies de bedoeling.
- Owner is in elke richting de uitzondering: niet bewerkbaar, niet verwijderbaar, niet toewijsbaar. De rol beschrijft het account waarop de werkruimte is gesleuteld en bevat elk recht, ook rechten die in een latere release worden toegevoegd, en daarom wordt haar lijst berekend in plaats van opgeslagen. De werkruimte aan iemand anders geven is een overdracht in plaats van een rolwijziging, en er is hier niets dat er een uitvoert.
- Daarbovenop schrijft een werkruimte haar eigen rollen, tot in totaal 24, door rechten aan te vinken in dezelfde gegroepeerde matrix. Aanvinken impliceert: “sjablonen bewerken” slaat “sjablonen lezen” ernaast op, want een rol die een sjabloon mag bewerken dat ze niet kan openen is een vinkje dat iemand vergeten is in plaats van beleid dat iemand bedoelt. Een rol verwijderen die mensen of API-sleutels hebben, vraagt waar ze naartoe moeten en weigert in plaats van te gokken. Een sleutel waarvan de rol verdween zou terugvallen op helemaal geen plafond, wat ruimer is dan de rol die net wegging.
- Een API-sleutel kan tegen een rol worden uitgegeven, en de rol is een plafond in plaats van een tweede toekenning: wat de sleutel mag doen, is de doorsnede van zijn eigen scopes met de rechten van de rol, bij elk verzoek opnieuw bepaald. Een sleutel die met versturen is aangemaakt en door Viewer wordt afgetopt, kan niet versturen, en een rol versmallen trekt dat live in zonder dat de sleutel geroteerd hoeft te worden. De assistent wordt aan dezelfde lijst gehouden, en de MCP-server bouwt de tools van een client op uit de rechten van de aanroeper, zodat de client van een viewer helemaal geen verstuurtool bevat, en elke afgeschermde tool controleert bij binnenkomst opnieuw, want een sessie kan van mailbox wisselen nadat de lijst is opgebouwd.