Uzskaitīt lomas
Katra darbvietas loma, iebūvētās pirmās, ar to, cik cilvēku un atslēgu katru tur.
Izpilda īstu izsaukumu pret jūsu darbvietu, ar jūsu paša atslēgu.
GET /roles
Katra darbvietas loma, iebūvētās pirmās, ar to, cik cilvēku un atslēgu katru tur.
Divas asis, un tie nav viens un tas pats jautājums
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"LOMA nosaka, ko kāds drīkst DARĪT šajā darbvietā: lasīt pastu, sūtīt to, rediģēt veidnes, pievienot domēnu. PIEŠĶĪRUMS nosaka, ar kurām ADRESĒM viņš to drīkst darīt, un tas dzīvo blakus, /members/{userId}/addresses, kā member (lasa adresi un sūta kā tā) vai viewer (tikai lasa). Abiem jāsakrīt, pirms ziņojums aiziet: loma ar emails:send un bez piešķīrumiem var sūtīt no nekurienes, un katra darbvietas adrese zem viewer piešķīruma arī var sūtīt no nekurienes.
Katra darbvieta tiek sākotnēji aizpildīta ar tām pašām sešām lomām. Owner, Admin, Member un Viewer veido kāpnes. Katra tur visu, ko tur nākamā, tāpēc kāda pazemināšana sašaurina viņa piekļuvi, nevis apmaina to pret citu šķēli. Developer un Billing nav pakāpieni uz tām: Developer būvē integrācijas (atslēgas, webhook izsaukumus, veidnes, sūtīšanu) un nelasa nevienu darbvietas vēstuli, bet Billing redz plānu un rēķinus un neko citu. Abas ietilpst stingri Admin iekšienē. Tās tiek izveidotas pirmajā nolasīšanā, nevis darbvietas izveides brīdī, tāpēc darbvieta, kas izveidota pirms šīs funkcijas, tās iegūst brīdī, kad kaut kas tās pieprasa. builtin nosauc, no kuras sagataves rinda nākusi, un tas ir viss, ko tas nosauc: šīs sešas ir sākumpunkts, ko darbvietai ir paredzēts veidot pēc sevis, un katru no tām, izņemot Owner, var pārdēvēt, pārdefinēt un izdzēst. Zarojiet pēc editable un deletable, nevis pēc nosaukuma: loma, ko kāds pārdēvējis, uz šiem diviem joprojām atbild pareizi, bet tās nosaukums vairs neko nepasaka.
Owner ir vienīgais izņēmums, un tas ir izņēmums visos virzienos: editable: false, deletable: false un atteikts kā mērķis PATCH /members/{userId} izsaukumā. Tā apraksta kontu, uz kuru piesaistīta darbvieta, un tur visas atļaujas, ieskaitot vēlākā laidienā pievienotās, tāpēc tās saraksts tiek aprēķināts, nevis glabāts. Padarīt kādu citu par īpašnieku nozīmē darbvietas nodošanu; galapunkta, kas to veiktu, šeit nav.
Pārējās piecas pieņem visu: jaunu atļauju sarakstu, jaunu aprakstu, jaunu nosaukumu, DELETE. Tās ir sākotnējie noklusējumi, nevis nekustami elementi: darbvietai, kas nekad nebūvē integrācijas, ir jāspēj atbrīvoties no Developer, un tai, kur “Member” nozīmē kaut ko šaurāku, ir jāspēj to pateikt saviem vārdiem. Atsaka tikai īpašnieks, un viņš atsaka visu ar vienu kodu: role_immutable, 409 ar param: "roleId", neatkarīgi no tā, vai PATCH nesa nosaukumu vai atļauju sarakstu. Neviena pārdēvēšana vairs netiek atteikta atsevišķi, tāpēc nav nekāda param: "name" nemainīguma, ar ko jārēķinās; vienīgais 409, ko nosaukums joprojām var izraisīt, ir role_name_taken, kad kāda cita darbvietas loma jau atsaucas uz to.
Papildus šīm sešām darbvieta var uzrakstīt līdz 24 savām lomām. Griesti skaita tikai tās, tāpēc sākotnēji izveidotas lomas dzēšana zem tiem vietu nedod. Atļaujas ievadē tiek IZVĒRSTAS, nevis uztvertas burtiski (templates:write vien tiek glabāts kā templates:read un templates:write), tāpēc lasiet sarakstu atpakaļ no atbildes, nevis pieņemiet, ka tas ir tas pats, ko nosūtījāt.
Loma ir arī griesti API atslēgai. Atslēga, kas izdota pret kādu lomu, drīkst key.scopes ∩ role.permissions un ne vairāk; tas tiek izrēķināts katram pieprasījumam uz robežas, tāpēc lomas rediģēšana maina to, ko tās atslēgas drīkst, jau ar nākamo izsaukumu, un atslēgai bez lomas griestu nav vispār. Tvērumu lapā ir viss par to.
Piemērs
Nepieciešams roles:read. Bez cursor. Aploksne nes hasMore un nextCursor, lai klients to varētu padot tam pašam saraksta kodam kā katru citu kolekciju, un otrās lappuses nekad nav.
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}Kārtots pēc iebūvētā ranga, tad pēc nosaukuma (owner, admin, member, viewer, developer, billing, tad pārējie alfabētiski), nevis no jaunākā kā pārējā API. Atļauju matricu lasa kā kāpnes, un kārtošana pēc createdAt katru nedēļu liek plašāko lomu citā rindā.
Tieši šī saraksta lasīšana SĀKOTNĒJI IZVEIDO tās sešas darbvietā, kurai nekad nav bijis nevienas. Sākotnējā izveide konfliktē ar unikālo indeksu un otrreiz neko nedara, tāpēc izsaukums ir idempotents un raksta tikai pirmais — un tieši tāpēc POST /members vienmēr var nosaukt roleId, kas pastāv.
Tas notiek VIENREIZ. Darbvieta atzīmē, ka sākotnējā izveide ir notikusi, tāpēc šī nolasīšana aizpilda darbvietu, kas vecāka par šo funkciju, un pēc tam vairs nekad neraksta — un tas ir tas, kas padara sākotnēji izveidotas lomas dzēšanu neatgriezenisku. Agrāka versija katrā nolasīšanā no jauna ievietoja jebkuru trūkstošo sagataves rindu, tāpēc izdzēsts Billing nākamajā lapas ielādē atgriezās ar jaunu id; tagad vairs ne.
members un apiKeys ir tas, kas būtu jāpārvieto, pirms lomu var izdzēst, un tas ļauj klientam brīdināt pirms dzēšanas piedāvāšanas, nevis pēc 409. Īpašnieka rindā parasti ir members: 0: īpašnieks nav savas darbvietas dalībnieks, viņš ir konts, uz kuru tā piesaistīta.
Pielāgoto lomu skaitam ir stingri griesti — 24 —, tieši tāpēc, lai šī varētu būt viena atbilde. Darbvieta ar četrdesmit lomām nevar, vienkārši paskatoties, atbildēt uz jautājumu “kurš drīkst sūtīt kā billing@”, un tas ir vienīgais jautājums, uz kuru šī funkcija pastāv, lai varētu atbildēt.