SDK

Anëtarët

`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` dhe `revokeAddress`.

Të gjitha metodat

members.ts

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)

Dy dhënie të drejtash për person dhe nuk duhen përmbledhur në një. role është çfarë mund të bëjnë; addresses është mbi çfarë mund ta bëjnë. Të dyja duhet të pajtohen: një rol që mban emails:send me access: "viewer" mbi invoices@ është dikush që mund të dërgojë mail dhe nuk mund ta dërgojë nga ajo adresë.

Çdo metodë merr userId, jo email-in. add është i vetmi përjashtim, dhe ai është edhe arsyeja e përjashtimit: thirrësi i saj ka një adresë email-i dhe ende asnjë id përdoruesi, që është e gjithë gjysma e parë e asaj që bën ajo thirrje.

implied: true do të thotë se askush nuk e zgjodhi rolin. Ata mbajnë adresa dhe asnjë rresht roli, pra ai u nxor nga dhënia më e gjerë që kanë. Trajtojeni si "ende e pavendosur", dhe update është ajo që e kthen nxjerrjen në vendim. Deri atëherë, zgjerimi i aksesit të tyre mbi adresat zgjeron në heshtje atë që mund të bëjnë.

Pronari i hapësirës së punës është rreshti i parë, i shënuar me isOwner: true, ndërsa add, update dhe remove e refuzojnë gjithsesi me member_is_owner. Një hapësirë pune e pandarë raporton një anëtar dhe jo asnjë, prandaj përjashtoni isOwner kur numëroni vendet.

remove merr të dyja boshtet, rolin DHE çdo dhënie adrese në këtë hapësirë pune, dhe raporton addressesRevoked. revokeAddress është ajo e ngushta, për dikë që ndërroi ekip dhe jo për dikë që iku.

Parametrat

emailstringe detyrueshme: Kë të ftoni, i pastruar nga hapësirat dhe me shkronja të vogla. Nuk ka nevojë të ketë ende llogari: të gjithë ftohen, dhe roli e dhëniet zbarkojnë kur ata pranojnë. Dikush që është tashmë në hapësirën e punës është `member_is_owner` (422).
roleIdstringe detyrueshme: Roli që do të mbajnë, nga 1 deri në 128 karaktere, dhe duhet të jetë një rol i kësaj hapësire pune: një id e panjohur është `role_not_found` (404). Roli i pronarit nuk mund t'i jepet askujt dhe kthehet si `role_immutable` (409), sepse ta bësh dikë pronar është një transferim i hapësirës së punës dhe këtu nuk ka thirrje për këtë.
addressIdsstring[]: Adresat për t'ia dorëzuar në të njëjtën thirrje, më së shumti 64 id nga 1 deri në 128 karaktere secila; një id që nuk është adresë e kësaj hapësire pune refuzohet. Roli shkruhet i pari dhe dhëniet vijnë një nga një, kështu që një id e gabuar e lë anëtarin të krijuar me më pak adresa se sa kërkuat. Ridërgimi i të njëjtit trup është zgjidhja, meqë të dyja shkrimet bëjnë upsert.
access'member' | 'viewer': Çfarë mund të bëjnë me secilën id te `addressIds`: `member` e lexon adresën dhe dërgon si ajo, `viewer` vetëm e lexon. Parazgjedhja është `member`, niveli që kanë përdorur gjithnjë konsola dhe rruga e vjetër e ndarjes, kështu që e njëjta thirrje do të thotë e njëjta gjë nga një skript dhe nga një ekran; jepni një përzierje duke thirrur `grantAddress` më pas për ato që ndryshojnë.

Përgjigjja

object'member': Gjithmonë `member`. Një heqje përgjigjet me të njëjtën vlerë, me `userId` e tyre, me `deleted: true` dhe me `addressesRevoked`, dhe me asnjë nga fushat e tjera më poshtë.
userIdstring: Id-ja e llogarisë së tyre, dhe identifikuesi që merr te shtegu çdo thirrje tjetër për anëtarët: get, update, remove dhe të dyja thirrjet për adresat. Shtimi i dikujt është e vetmja thirrje që punon nga një email, sepse kushdo që shton një koleg e di adresën e tij dhe jo id-në.
emailstring: Email-i te llogaria e tyre, i kthyer ashtu siç e ruan ai rresht. Ky burim nuk e shkruan kurrë, dhe kthimi në shkronja të vogla te `add` zbatohet mbi adresën që dërgoni për kërkimin dhe jo mbi atë që kthehet. Pas pronarit, lista e anëtarëve renditet sipas tij dhe jo sipas kohës kur u bashkuan njerëzit, sepse lista lexohet për të gjetur një person dhe jo për të parë se çfarë ndryshoi.
namestring | null: Emri i tyre i shfaqur, marrë nga llogaria e tyre, ku kolona është NOT NULL. Null-i te tipi është mbrojtës dhe jo një gjendje që ky API është parë ta prodhojë. Ai u përket atyre dhe jo hapësirës së punës, pra asgjë mbi këtë burim nuk mund ta caktojë.
imagestring | null: Avatari i tyre, marrë nga llogaria e tyre, dhe null kur nuk kanë caktuar asnjë.
role.idstring | null: Id-ja e rolit që mbajnë, ose null kur nuk e zgjodhi askush. Shihni `implied`. Një null këtu është i vetmi rast ku `role` raporton një nxjerrje dhe jo një vendim që e mori dikush.
role.namestring: Emri i rolit. Për një anëtar të nënkuptuar ai është emri i template-it të integruar te i cili u zgjidh aksesi i tyre, jo një rresht i kësaj hapësire pune.
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null: Cili rol i integruar është, ose null për një të personalizuar. `owner` shfaqet vetëm te rreshti i vetë pronarit, krah `isOwner: true`; caktimi i atij roli te kushdo refuzohet me `role_immutable` (409).
isOwnerboolean: True te saktësisht një rresht, llogaria mbi të cilën është çelësuar hapësira e punës. Ata mbajnë çdo leje sido që të thotë rreshti i rolit të tyre, renditen të parët, dhe `add`, `update` e `remove` i refuzojnë të gjitha me `member_is_owner`. Përjashtojini kur numëroni vendet.
impliedboolean: True kur ky person ka dhënie adresash dhe asnjë rresht anëtari, pra roli i tij u nxor e nuk u zgjodh: çdo dhënie `member` zgjidhet te Member-i i integruar, përndryshe te Viewer. Kurrë true për pronarin. Shfaqeni si "e nënkuptuar nga aksesi". Derisa një PATCH ta kthejë nxjerrjen në vendim, zgjerimi i aksesit të tyre mbi adresat zgjeron në heshtje atë që mund të bëjnë.
permissionsPermission[]: Lejet e rolit të rrafshuara mbi anëtarin, kështu që një lexim i vetëm i përgjigjet pyetjes "a mundet?" pa marrë rolin. Për një anëtar të nënkuptuar ato vijnë nga TEMPLATE-i i integruar dhe jo nga rreshti i rolit të kësaj hapësire pune, pra ndryshimi i rolit të integruar Member nuk e ndryshon atë që mban një anëtar i nënkuptuar.
addressesMemberAddress[]: Adresat që u janë dhënë, të renditura sipas adresës, secila me nivelin e vet të aksesit. Bosh për dikë që mban një rol dhe asnjë dhënie, që është pamja e një anëtari të ri derisa t'i jepet një adresë, dhe është dështimi i duhur për të pasur ndërsa jeni ende duke vendosur se çfarë duhet të shohin.
addresses[].addressIdstring: Id-ja e adresës, dhe ajo që marrin `grantAddress` dhe `revokeAddress`. Një id që nuk është adresë e kësaj hapësire pune refuzohet te të dyja, në vend që të raportohet një revokim që nuk ndodhi kurrë.
addresses[].addressstring: Adresa e plotë, me shkronja të vogla, e rindërtuar nga local-part-i dhe domeni i saj.
addresses[].access'member' | 'viewer': Çfarë mund të bëjnë me këtë adresë të vetme: `member` e lexon dhe dërgon si ajo, `viewer` vetëm e lexon. Kjo dhe roli duhet ta lejojnë të dyja një dërgim para se ai të ndodhë, kështu që një rol që mban `emails:send` mbi një dhënie `viewer` dërgon nga asgjë; kolona e ruajtur quhet `role`, dhe këtu riemërtohet që një objekt i vetëm të mos mbajë dy `role` të marra nga dy fjalorë.
createdAtstring | null: Kur u shkrua rreshti i tyre i anëtarit, ISO-8601, dhe null kur nuk ka fare rresht anëtari. Ajo null përshkruan të njëjtën popullatë si `implied: true`: njerëz që mbajnë adresa nga koha para se të ekzistonin rolet dhe të cilëve askush nuk u ka dhënë që atëherë një rol.