Tudásbázis
Szerepkörök és jogosultsági szintek
A szerepkör megmondja, ki mit tehet; a címhozzáférés megmondja, mivel teheti.
Részletek
- Személyenként két engedély, és mindkettőnek egyet kell értenie, mielőtt bármi történne. A SZEREPKÖR, amelyet a Beállítások → Tagok alatt állítasz, azt mondja meg, mit TEHET az illető a munkaterületen: levelet olvasni, küldeni, sablont szerkeszteni, domaint hozzáadni, API-kulcsot létrehozni. A CÍMHOZZÁFÉRÉS, amelyet a címsoron lévő Megosztás vezérlőből állítasz, azt mondja meg, MELY CÍMEKKEL teheti mindezt, csak olvasásra vagy olvasásra és küldésre. Aki küldést tartalmazó szerepkört kapott, de címet nem, az semmiről nem tud küldeni; aki a munkaterület minden címét megkapta csak olvasásra, az szintén egyikről sem tud küldeni.
- Hat szerepkör létezik anélkül, hogy bárki létrehozná őket, és minden munkaterületen ugyanaz a hat, tehát az „Admin” itt ugyanazt jelenti, mint a dokumentációban és az API-n. Az Owner, az Admin, a Member és a Viewer egy létra: mindegyik tartalmazza mindazt, amit a következő, tehát a visszaminősítés szűkíti azt, amit valaki elér, nem pedig egy másik szeletre cseréli. A Developer és a Billing nem fokai ennek a létrának. A Developer integrációkat épít: API-kulcsokat, webhookokat, sablonokat és küldést birtokol, miközben a munkaterület leveleiből semmit nem olvas, a Billing pedig látja a csomagot és a számlákat, tudja módosítani a csomagot és a rajtuk lévő fizetési adatokat, és olvassa a postafiók-beállításokat anélkül, hogy bármelyiket írhatná. A jogosultságaik szerkeszthetők: az a munkaterület, amely inkább nem szeretné, hogy a tagjai sablont írjanak, kiveszi a pipát, és a változás azon a következő kérésen érvényesül, amelyet bárki tesz, aki KIFEJEZETTEN azt a szerepkört birtokolja. Akinek a szerepkörét még mindig egy szerepkörök előtti címhozzáférés vonja maga után, az a szállított alapértékeket tartja, amíg nem kap kifejezetten szerepkört. Ahogy a nevük is szerkeszthető: az a munkaterület, amely Ops és On-call néven fut, átnevezi őket, és magát írja le, ami éppen a lényeg.
- Az Owner minden irányban kivétel: nem szerkeszthető, nem törölhető, nem kiosztható. Azt a fiókot írja le, amelyre a munkaterület kulcsolva van, és minden jogosultságot birtokol, azokat is, amelyek egy későbbi kiadásban kerülnek be, ezért számolódik a listája ahelyett, hogy tárolva lenne. A munkaterület átadása másnak átruházás, nem szerepkör-változtatás, és itt semmi nincs, ami ilyet végezne.
- Ezeken túl a munkaterület sajátokat ír, összesen 24-ig, ugyanabból a csoportosított mátrixból pipálva ki a jogosultságokat. A pipálás maga után von: a „sablonok szerkesztése” mellé a „sablonok olvasása” is tárolódik, mert az a szerepkör, amely olyan sablont szerkeszthet, amelyet meg sem nyithat, inkább elfelejtett jelölőnégyzet, mint bárki által szándékolt házirend. Az olyan szerepkör törlése, amelyet emberek vagy API-kulcsok birtokolnak, megkérdezi, hová kerüljenek át, és tippelés helyett elutasít. Az a kulcs, amelynek eltűnt a szerepköre, egyáltalán nem kapna felső korlátot, ami tágabb, mint az imént megszűnt szerepkör.
- Az API-kulcs kiadható egy szerepkörre, és a szerepkör felső korlát, nem második engedély: amit a kulcs tehet, az a saját hatókörei és a szerepkör jogosultságainak metszete, minden kérésnél feloldva. Az a kulcs, amelyet küldéssel hoztak létre, de Viewer korlátozza, nem tud küldeni, a szerepkör szűkítése pedig élőben vonja vissza anélkül, hogy a kulcsot cserélni kellene. Az asszisztensre ugyanez a lista vonatkozik, és az MCP-kiszolgáló a hívó jogosultságaiból építi fel a kliens eszközeit, tehát egy Viewer kliensében egyáltalán nincs küldőeszköz, és minden korlátozott eszköz újraellenőrzi magát belépéskor, mert egy munkamenet a lista felépítése után is válthat postafiókot.