SDK
Tagok
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` és `revokeAddress`.
Minden metódus
const people = await openemail.members.list()const member = await openemail.members.get(people[0]!.userId) const sam = await openemail.members.add({ email: '[email protected]', roleId: support.id, addressIds: ['2b81de07-…'], access: 'member',}) await openemail.members.update(sam.userId, { roleId: viewerRoleId }) await openemail.members.grantAddress(sam.userId, { addressId: 'c40a95f2-…', access: 'viewer',})await openemail.members.revokeAddress(sam.userId, 'c40a95f2-…') await openemail.members.remove(sam.userId)Személyenként két jogosultság, és nem szabad őket összemosni. A role azt mondja meg, mit tehetnek; az addresses azt, hogy mivel tehetik. Mindkettőnek egyet kell értenie: az emails:send jogot tartalmazó szerepkör access: "viewer" beállítással az invoices@ címen olyan valaki, aki küldhet levelet, de erről a címről nem.
Minden metódus a userId értéket várja, nem az e-mail-címet. Az add az egyetlen kivétel, és épp ez a kivétel oka: a hívójának e-mail-címe van, felhasználói azonosítója még nincs, és pont ez a hívás első fele.
Az implied: true azt jelenti, hogy a szerepkört senki nem választotta ki. Címeik vannak, szerepkörsoruk nincs, így a rendszer a legtágabb jogosultságukból következtette ki. Kezeld úgy, mint a „még nincs eldöntve” állapotot; a következtetést az update teszi döntéssé. Addig a címhozzáférésük bővítése csendben bővíti azt is, amit tehetnek.
A munkaterület tulajdonosa az első sor, isOwner: true jelöléssel, miközben az add, az update és a remove továbbra is member_is_owner hibával utasítja el. A meg nem osztott munkaterület egy tagot jelent, nem nullát, ezért a licencek számolásakor hagyd ki az isOwner sort.
A remove mindkét tengelyt elviszi: a szerepkört ÉS a munkaterület minden címjogosultságát, majd jelenti az addressesRevoked értéket. A revokeAddress a szűkebb hívás: annak való, aki csapatot váltott, nem annak, aki elment.
Paraméterek
emailstringkötelező- Kit hívsz meg; levágva és kisbetűsítve. Még nem kell fiók hozzá: mindenkit meg lehet hívni, a szerepkör és a jogosultságok az elfogadáskor kerülnek a helyükre. Aki már a munkaterület tagja, az `member_is_owner` (422).
roleIdstringkötelező- A szerepkör, amelyet kapni fognak, 1–128 karakter, és ennek a munkaterületnek a szerepköre kell legyen: ismeretlen azonosító esetén `role_not_found` (404). A tulajdonosi szerepkört nem lehet kiosztani, ilyenkor `role_immutable` (409) a válasz, mert valakit tulajdonossá tenni munkaterület-átruházás, és arra itt nincs hívás.
addressIdsstring[]- Ugyanebben a hívásban átadandó címek, legfeljebb 64 azonosító, egyenként 1–128 karakter; olyan azonosítót, amely nem e munkaterület címe, elutasít a rendszer. Előbb a szerepkör íródik ki, a jogosultságok egyesével követik, így egy rossz azonosító után a tag a kértnél kevesebb címmel jön létre. A megoldás ugyanannak a törzsnek az újraküldése, mivel mindkét írás upsert.
access'member' | 'viewer'- Mit tehetnek az `addressIds` minden azonosítójával: a `member` olvassa a címet és küldhet róla, a `viewer` csak olvassa. Alapértéke `member`, az a szint, amelyet a konzol és a régebbi megosztási útvonal mindig is használt, így ugyanaz a hívás ugyanazt jelenti szkriptből és képernyőről; vegyes jogosultságot úgy adj, hogy utána a `grantAddress`-t hívod meg az eltérőekre.
Válasz
object'member'- Mindig `member`. Az eltávolítás ugyanezzel az értékkel válaszol, mellette a `userId`, a `deleted: true` és az `addressesRevoked`, az alábbi többi mező nélkül.
userIdstring- A fiókazonosítójuk, és az a kulcs, amelyet minden más taghívás az útvonalban vár: get, update, remove és mindkét címhívás. A hozzáadás az egyetlen hívás, amely e-mail-címmel működik, mert aki kollégát vesz fel, a címét ismeri, nem az azonosítóját.
emailstring- A fiókjukon szereplő e-mail-cím, pontosan úgy visszaadva, ahogy azt a sor tárolja. Ez az erőforrás soha nem írja, és az `add` kisbetűsítése a kereséshez küldött címre vonatkozik, nem arra, ami visszajön. A tulajdonos után a taglista ez alapján rendeződik, nem a csatlakozás ideje szerint, mert a listát azért olvassák, hogy egy embert megtaláljanak, nem azért, hogy lássák, mi változott.
namestring | null- A megjelenített nevük a fiókjukból, ahol az oszlop NOT NULL. A típusban szereplő null védekezés, nem olyan állapot, amelyet ez az API valaha is előállított volna. Hozzájuk tartozik, nem a munkaterülethez, így ezen az erőforráson semmi nem állíthatja be.
imagestring | null- Az avatarjuk a fiókjukból, és null, ha nem állítottak be ilyet.
role.idstring | null- A birtokolt szerepkör azonosítója, vagy null, ha senki nem választotta ki. Lásd az `implied` mezőt. Az itteni null az egyetlen eset, amikor a `role` következtetést jelent, nem valakinek a döntését.
role.namestring- A szerepkör neve. Következtetett tagnál annak a beépített sablonnak a neve, amelyre a hozzáférésük feloldódott, nem pedig e munkaterület egyik sora.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- Melyik beépített szerepkörről van szó, vagy null egyedi szerepkörnél. Az `owner` kizárólag a tulajdonos saját során jelenik meg, az `isOwner: true` mellett; ennek a szerepkörnek a kiosztása bárkinek `role_immutable` (409) hibával elutasításra kerül.
isOwnerboolean- Pontosan egy soron igaz: azon a fiókon, amelyre a munkaterület kulcsolva van. Minden jogosultságot birtokolnak, bármit is mond a szerepkörsoruk, a rendezésben elsők, és az `add`, az `update` és a `remove` mind `member_is_owner` hibával utasítja el őket. A licencek számolásakor hagyd ki őket.
impliedboolean- Igaz, ha ennek a személynek vannak címjogosultságai, de nincs tagsora, így a szerepköre következtetett, nem választott: bármely `member` jogosultság a beépített Member szerepkörre oldódik fel, egyébként Viewer lesz. A tulajdonosnál soha nem igaz. Jelenítsd meg „hozzáférésből következik” felirattal. Amíg egy PATCH döntéssé nem teszi a következtetést, a címhozzáférésük bővítése csendben bővíti azt is, amit tehetnek.
permissionsPermission[]- A szerepkör jogosultságai a tagra lapítva, így egyetlen olvasás megválaszolja a „szabad neki?” kérdést a szerepkör lekérése nélkül. Következtetett tagnál ezek a beépített SABLONBÓL jönnek, nem e munkaterület szerepkörsorából, így a beépített Member szerepkör szerkesztése nem változtat azon, amit egy következtetett tag birtokol.
addressesMemberAddress[]- A nekik adott címek, cím szerint rendezve, mindegyik a saját hozzáférési szintjével. Üres annál, akinek van szerepköre, de nincs jogosultsága; így néz ki egy új tag, amíg nem kap címet, és ez a helyes hiba addig, amíg még azon gondolkodsz, mit lásson.
addresses[].addressIdstring- A cím azonosítója, és ezt várja a `grantAddress` és a `revokeAddress`. Olyan azonosítót, amely nem e munkaterület címe, mindkettő elutasít, ahelyett hogy meg nem történt visszavonást jelentene.
addresses[].addressstring- A teljes cím kisbetűsítve, a helyi részéből és a domainjéből újraépítve.
addresses[].access'member' | 'viewer'- Mit tehetnek ezzel az egy címmel: a `member` olvassa és küldhet róla, a `viewer` csak olvassa. Küldés csak akkor történik, ha ez és a szerepkör is engedi, így az `emails:send` jogú szerepkör `viewer` jogosultság fölött semmiről nem küld; a tárolt oszlop neve `role`, itt azért kapott másik nevet, hogy egy objektum ne hordozzon két, két különböző szótárból vett `role` mezőt.
createdAtstring | null- Mikor íródott a tagsori bejegyzésük, ISO-8601, és null, ha egyáltalán nincs tagsor. Ez a null ugyanazt a kört írja le, mint az `implied: true`: azok, akiknek a szerepkörök létrejötte előttről vannak címeik, és azóta sem adott nekik senki szerepkört.