Szerepkörök listázása
A munkaterület minden szerepköre, elöl a beépítettek, azzal együtt, hány ember és kulcs rendelkezik az egyes szerepkörökkel.
A valódi hívást futtatja le a munkaterületén, a saját kulcsával.
GET /roles
A munkaterület minden szerepköre, elöl a beépítettek, azzal együtt, hány ember és kulcs rendelkezik az egyes szerepkörökkel.
Két tengely, és nem ugyanaz a kérdés
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"A SZEREPKÖR azt mondja meg, mit TEHET valaki ebben a munkaterületen: leveleket olvashat, küldhet, sablonokat szerkeszthet, domaint adhat hozzá. A HOZZÁFÉRÉS azt mondja meg, mely CÍMEKEN teheti ezt, és a szomszédos /members/{userId}/addresses útvonalon található member (olvassa a címet és a nevében küld) vagy viewer (csak olvassa) formában. Mindkettőnek egyetértésben kell lennie, mielőtt egy üzenet elmegy: egy emails:send jogosultságú szerepkör hozzáférések nélkül semmiről nem küldhet, és a munkaterület minden címe viewer hozzáféréssel ugyancsak semmiről nem küldhet.
Minden munkaterület ugyanazzal a hat szerepkörrel indul. Az Owner, Admin, Member és Viewer egy létrát alkot. Mindegyik rendelkezik mindazzal, amivel a következő, így valaki lefokozása szűkíti a hozzáférését, nem cseréli egy másik szeletre. A Developer és a Billing nem fokai ennek a létrának: a Developer integrációkat épít (kulcsok, webhookok, sablonok, küldés), és a munkaterület leveleiből semmit nem olvas, a Billing pedig a csomagot és a számlákat látja, semmi mást. Mindkettő szigorúan az Admin részhalmaza. Az első olvasáskor jönnek létre, nem a munkaterület létrehozásakor, így egy e funkció előtt készült munkaterület abban a pillanatban megkapja őket, amint valami lekérdezi. A builtin azt nevezi meg, melyik kezdeti sablonból származik egy sor, és csak ennyit: a hat szerepkör kiindulópont, amelyet a munkaterületnek alakítania kell, és az Owner kivételével mindegyik átnevezhető, újrajogosítható és törölhető. Az editable és deletable alapján ágazz el, ne a név alapján: egy átnevezett szerepkör továbbra is helyesen válaszol erre a kettőre, a neve viszont már semmit nem árul el.
Az Owner az egyetlen kivétel, és minden irányban kivétel: editable: false, deletable: false, és célként elutasításra kerül a PATCH /members/{userId} hívásnál. Azt a fiókot írja le, amelyhez a munkaterület kötve van, és minden jogosultsággal rendelkezik, a későbbi kiadásokban hozzáadottakkal is, ezért a listája számított, nem tárolt. Valaki mást tulajdonossá tenni munkaterület-átadás; itt nincs végpont, amely ezt elvégezné.
A másik öt mindent elfogad: új jogosultságlistát, új leírást, új nevet, DELETE kérést. Kezdeti alapértelmezések, nem rögzített elemek: egy munkaterületnek, amely soha nem épít integrációt, meg kell tudnia szabadulni a Developer szerepkörtől, és egy olyannak, ahol a „Member” szűkebbet jelent, ki kell tudnia mondani ezt a saját szavaival. Csak a tulajdonos utasít el, és mindent egyetlen kóddal utasít el: role_immutable, 409, param: "roleId" értékkel, akár nevet, akár jogosultságlistát tartalmazott a PATCH. Önmagában egyetlen átnevezés sincs már elutasítva, így nincs kezelendő param: "name" megváltoztathatatlanság; az egyetlen 409, amelyet egy név még kiválthat, a role_name_taken, ha a munkaterületen már egy másik szerepkör viseli.
A hat fölött egy munkaterület legfeljebb 24 saját szerepkört hozhat létre. A plafon csak ezeket számolja, így egy kezdeti szerepkör törlése nem ad alatta több helyet. A jogosultságok beérkezéskor KIBONTÁSRA kerülnek, nem szó szerint tárolódnak (egyedül a templates:write templates:read és templates:write formában tárolódik), ezért a listát a válaszból olvasd vissza, ne feltételezd, hogy az, amit elküldtél.
A szerepkör egyben egy API kulcs plafonja is. Egy hozzá kiállított kulcs key.scopes ∩ role.permissions műveleteket végezhet, többet nem, kérésenként a határon feloldva, így egy szerepkör szerkesztése már a kulcsai következő hívásánál megváltoztatja, mit tehetnek, és egy szerepkör nélküli kulcsnak egyáltalán nincs plafonja. A Hatókörök oldal ezt teljes egészében leírja.
Példa
roles:read szükséges. Cursor nélküli. A boríték tartalmazza a hasMore és nextCursor mezőket, így a kliens ugyanannak a listakódnak adhatja át, mint minden más gyűjteményt, és soha nincs második oldal.
curl "$OE/roles" -H "$AUTH"{ "object": "list", "data": [ { "object": "role", "id": "role_1c94e05d3862c1f0a44b7f3a", "name": "Owner", "description": "The person the workspace belongs to. Holds everything, including additions.", "permissions": ["emails:send", "emails:read", "…", "workspace:manage"], "builtin": "owner", "editable": false, "deletable": false, "members": 0, "apiKeys": 2, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" }, { "object": "role", "id": "role_c40a95f21cc65d31c2a89e07", "name": "Viewer", "description": "Reads the mail on the addresses they hold, and changes nothing.", "permissions": [ "emails:read", "drafts:read", "threads:read", "labels:read", "contacts:read", "calendar:read", "templates:read", "rules:read", "connections:read", "settings:read" ], "builtin": "viewer", "editable": true, "deletable": true, "members": 3, "apiKeys": 1, "createdAt": "2026-08-01T09:00:00.000Z", "updatedAt": "2026-08-01T09:00:00.000Z" } ], "hasMore": false, "nextCursor": null}Beépített rang, majd név szerint rendezve (owner, admin, member, viewer, developer, billing, majd a többi ábécésorrendben), nem legújabb elöl, mint az API többi része. Egy jogosultsági mátrixot létraként olvasnak, és createdAt szerint rendezve a legszélesebb szerepkör minden héten más sorba kerülne.
Ennek a listának az olvasása HOZZA LÉTRE a hat szerepkört egy olyan munkaterületen, amelynek még soha nem volt egy sem. A létrehozás egy egyedi indexen ütközik, és másodszorra semmit nem csinál, így a hívás idempotens, és csak az első ír, ezért tud a POST /members mindig létező roleId-t megnevezni.
EGYSZER hoz létre. A munkaterület rögzíti, hogy a kezdeti létrehozás megtörtént, így ez az olvasás feltölt egy a funkciónál régebbi munkaterületet, majd soha többé nem ír, és ettől végleges egy kezdeti szerepkör törlése. Egy korábbi build minden olvasáskor újra beszúrta a hiányzó sablonsort, így egy törölt Billing a következő oldalbetöltéskor új id-vel visszajött; ez már nem így van.
A members és az apiKeys mutatja, mit kellene áthelyezni, mielőtt a szerepkör törölhető, ezzel a kliens még a törlés felkínálása előtt figyelmeztethet, nem a 409 után. A tulajdonosi sor általában members: 0 értéket mutat: a tulajdonos nem tagja a saját munkaterületének, ő az a fiók, amelyhez a munkaterület kötve van.
Pontosan azért van 24 egyéni szerepkörös kemény plafon, hogy ez egyetlen válasz lehessen. Egy negyven szerepkörös munkaterületen ránézésre nem lehet megválaszolni, hogy „ki küldhet billing@ nevében”, pedig ez az egyetlen kérdés, amelynek megválaszolhatóvá tételéért a funkció létezik.