Anëtarë
`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address`, dhe metodat e ftesave pranë tyre.
Çdo metodë
from openemail import openemail roles = openemail.roles.list_all()support = next(role for role in roles if role['name'] == 'Support')viewer = next(role for role in roles if role['builtin'] == 'viewer') invitation = openemail.members.add({ 'email': '[email protected]', 'roleId': support['id'], 'addressIds': ['2b81de07-…'], 'access': 'member',}) people = openemail.members.list_all()sam = next(person for person in people if person['email'] == '[email protected]')member = openemail.members.get(sam['userId']) openemail.members.update(sam['userId'], {'roleId': viewer['id']}) openemail.members.grant_address(sam['userId'], { 'addressId': 'c40a95f2-…', 'access': 'viewer',})openemail.members.revoke_address(sam['userId'], 'c40a95f2-…') 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ë. Përjashtim bën një rol që mban addresses:all, i cili arrin çdo adresë çfarëdo që të rendisë addresses, sepse ai varg mban vetëm dhënie të drejtpërdrejta, ndaj kontrolloni permissions para se ta lexoni si gjithë shtrirjen e dikujt.
Çdo metodë merr userId, jo email-in. add është i vetmi përjashtim, sepse fton një adresë: personi ka një userId vetëm pasi ta pranojë, dhe list_invitations e ndjek ftesën deri atëherë.
'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. revoke_address është ajo e ngushta, për dikë që ndërroi ekip dhe jo për dikë që iku.
Parametrat
emailstre 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).
roleIdstre 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ë.
addressIdslist[str]- Adresat që mbart ftesa, më së shumti 64 id nga 1 deri në 128 karaktere secila, që jepen kur ajo pranohet. Çdo id kontrollohet para se të shkruhet ndonjë gjë, kështu që një id që nuk është adresë e kësaj hapësire pune e refuzon të gjithë thirrjen me 422 `member_not_found` dhe nuk dërgohet asgjë. Ftesa e së njëjtës adresë sërish brenda dhjetë minutash është 409 `invitation_too_soon`.
accessLiteral['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 `grant_address` më pas për ato që ndryshojnë.
Përgjigje
objectLiteral['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ë.
userIdstr- 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ë.
emailstr- 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.
namestr | None- Emri i tyre i shfaqur, marrë nga llogaria e tyre, ku kolona është NOT NULL. `None`-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ë.
imagestr | None- Avatari i tyre, marrë nga llogaria e tyre, dhe null kur nuk kanë caktuar asnjë.
role.idstr | None- 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.namestr- 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.builtinLiteral['owner', 'admin', 'member', 'viewer', 'developer', 'billing'] | None- 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).
isOwnerbool- 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.
impliedbool- 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ë.
permissionslist[Permission]- 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.
addresseslist[MemberAddressResource]- 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[].addressIdstr- Id-ja e adresës, dhe ajo që marrin `grant_address` dhe `revoke_address`. 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[].addressstr- Adresa e plotë, me shkronja të vogla, e rindërtuar nga local-part-i dhe domeni i saj.
addresses[].accessLiteral['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ë.
createdAtstr | None- 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.
Ftesat
from openemail import openemail waiting = openemail.members.list_all_invitations() for invitation in waiting: if invitation['expired']: openemail.members.resend_invitation(invitation['id']) openemail.members.revoke_invitation('winv_6bb640f5b99e47deb758f1f5')add përgjigjet me një ftesë, dhe këto janë thirrjet që e ndjekin: list_invitations, list_all_invitations dhe iterate_invitations lexojnë ato që ende s’i ka pranuar askush, resend_invitation e dërgon sërish një me një lidhje të re dhe katërmbëdhjetë ditë më shumë, dhe revoke_invitation e tërheq. Një ftesë në pritje nuk jep asgjë derisa të pranohet.
resend_invitation e refuzon të njëjtën adresë dy herë brenda dhjetë minutash me 409 invitation_too_soon, dhe revoke_invitation refuzon një ftesë që u pranua më parë me 409 invitation_accepted.
Kodet e verifikimit
add, update, remove, grant_address dhe revoke_address i kërkojnë një tokeni qasjeje OAuth një kod verifikimi para se të ndryshojnë ndonjë gjë, ndërsa resend_invitation dhe revoke_invitation jo. Thirrja ngre një OpenEmailApiError me is_step_up_required të barabartë me True: kërkoni një kod me security.begin_step_up(), kontrolloni atë që ju jep personi me security.verify_step_up({'code': ...}), pastaj bëjeni thirrjen sërish. Një verifikim vlen për 60 minuta, dhe një çelësi API nuk i kërkohet kurrë.
Referencë
members.list()Referenca e plotëmembers.list_all()Referenca e plotëmembers.iterate()Referenca e plotëmembers.get()Referenca e plotëmembers.add()Referenca e plotëmembers.update()Referenca e plotëmembers.remove()Referenca e plotëmembers.grant_address()Referenca e plotëmembers.revoke_address()Referenca e plotëmembers.list_invitations()Referenca e plotëmembers.list_all_invitations()Referenca e plotëmembers.iterate_invitations()Referenca e plotëmembers.resend_invitation()Referenca e plotëmembers.revoke_invitation()Referenca e plotë