Anëtarë
`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address` dhe metodat e ftesave pranë tyre.
Çdo metodë
support_role_id = "role_8b1f4c2e9a7d3b60e5f1a2c4"viewer_role_id = "role_2c7e9a1f4b8d3e60c5a7f1b9" invitation = client.members.add( email: "[email protected]", roleId: support_role_id, addressIds: ["2b81de07-9c3f-4a61-b8e2-5d07f4c19a36"], access: "member")puts invitation[:id], invitation[:expiresAt] people = client.members.list_allputs people.map { |person| "#{person[:email]} #{person[:userId]}" } sam_id = "q7Vd3kX9mT2pLw8RzN4bYc6HfJ1sGa5E"member = client.members.get(sam_id)puts member.dig(:role, :name), member[:implied] client.members.update(sam_id, roleId: viewer_role_id) address_id = "c40a95f2-1e7b-4d38-a6c9-82f05b3d7e14"client.members.grant_address(sam_id, addressId: address_id, access: "viewer")client.members.revoke_address(sam_id, address_id) removed = client.members.remove(sam_id)puts removed[:addressesRevoked]Dy dhënie të drejtash për person, dhe nuk duhen bashkuar 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ë postë 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ë listojë addresses, sepse ai Array mban vetëm dhënie të drejtpërdrejta. Ndaj kontrolloni permissions para se ta lexoni addresses si gjithë shtrirjen e dikujt.
Çdo thirrje për një person merr userId e tij si argumentin e parë, jo emailin, ndaj lexojeni nga list ose list_all siç bën shembulli. add është i vetmi përjashtim, sepse fton një adresë: personi ka një userId vetëm pasi pranon, dhe deri atëherë list_invitations e ndjek ftesën. Fushat e trupit të një kërkese ruajnë emrat camelCase të API-së (roleId:, addressIds:, addressId:), të dhëna si fjalë kyçe ose si një Hash i vetëm.
list kthen një OpenEmail::Page, list_all i kthen të gjithë anëtarët në një Array të vetëm, dhe iterate ia jep çdo anëtar një blloku ose kthen një Enumerator kur nuk ka bllok. Një anëtar kthehet si Hash me çelësa Symbol, dhe role është një Hash brenda tij, ndaj member.dig(:role, :name) lexon emrin e rolit.
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 isOwner: true, ndërsa add, update dhe remove e refuzojnë prapëseprapë me member_is_owner, një 422 i ngritur si OpenEmail::ValidationError. Një hapësirë pune e pandarë me të tjerë raporton një anëtar dhe jo asnjë, ndaj përjashtoni isOwner kur numëroni vendet: client.members.list_all.count { |member| !member[:isOwner] }.
remove i heq të dy boshtet, rolin DHE çdo dhënie adrese në këtë hapësirë pune, dhe raporton addressesRevoked. revoke_address është ai i ngushti, për dikë që ndërroi ekip dhe jo për dikë që u largua.
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ë mbajë personi, 1 deri në 128 karaktere, dhe duhet të jetë një rol në këtë hapësirë pune: një id e panjohur jep `role_not_found` (404), të ngritur si `OpenEmail::NotFoundError`. Roli i pronarit nuk mund të jepet dhe kthehet me `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ë.
addressIdsArray<String>- 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`.
accessString- Çfarë mund të bëjë personi me çdo id te `addressIds`: `member` e lexon adresën dhe dërgon në emër të saj, `viewer` vetëm e lexon. Parazgjedhja është `member`, niveli që kanë përdorur gjithmonë konsola dhe rruga e vjetër e ndarjes, ndaj e njëjta thirrje do të thotë të njëjtën gjë nga një skript dhe nga një ekran. Për një përzierje, thirrni më pas `grant_address` për ato që ndryshojnë.
Përgjigje
objectString- 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ë personit, dhe doreza që çdo thirrje tjetër për anëtarët e merr si argumentin e parë: `get`, `update`, `remove` dhe të dyja thirrjet e adresave. Shtimi i dikujt është e vetmja thirrje që punon me një email në vend të saj, 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 or nil- Emri i shfaqur i personit, i marrë nga llogaria e tij, ku kolona mban gjithmonë një vlerë. nil-i në tip është mbrojtës dhe jo një gjendje që kjo API është parë ta prodhojë. Ai i përket personit dhe jo hapësirës së punës, ndaj asgjë në këtë burim nuk mund ta caktojë.
imageString or nil- Avatari i personit, i marrë nga llogaria e tij, dhe nil kur nuk ka vendosur një të tillë.
role.idString or nil- Id-ja e rolit që mban personi, e lexuar si `member.dig(:role, :id)`, ose nil kur nuk e zgjodhi askush. Shihni `implied`. Një nil këtu është i vetmi rast kur `role` raporton një përfundim të nxjerrë dhe jo një vendim që e mori dikush.
role.nameString- Emri i rolit. Për një anëtar të nënkuptuar, është emri i shabllonit të integruar me të cilin përputhet aksesi i tij, jo një rresht në këtë hapësirë pune.
role.builtinString or nil- Cili rol i integruar është roli, `owner`, `admin`, `member`, `viewer`, `developer` ose `billing`, ose nil për një rol të personalizuar. `owner` shfaqet vetëm në rreshtin e vetë pronarit, bashkë me `isOwner: true`. Caktimi i atij roli për këdo 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 dhe nuk u zgjodh: çdo dhënie `member` e bën atë Member-in e integruar, përndryshe Viewer. Kurrë true për pronarin. Shfaqeni si “e nënkuptuar nga aksesi”. Derisa një `update` ta kthejë përfundimin në vendim, zgjerimi i aksesit të tij mbi adresat zgjeron në heshtje atë që mund të bëjë.
permissionsArray<String>- Lejet e rolit të rrafshuara mbi anëtarin, ndaj 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 SHABLLONI i integruar dhe jo nga rreshti i rolit të kësaj hapësire pune, ndaj ndryshimi i rolit të integruar Member nuk e ndryshon atë që mban një anëtar i nënkuptuar.
addressesArray<Hash>- 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 `grant_address` dhe `revoke_address`. Një id që nuk është adresë në këtë hapësirë 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[].accessString- Çfarë mund të bëjë personi me këtë adresë të vetme: `member` e lexon dhe dërgon në emër të saj, `viewer` vetëm e lexon. Si kjo, ashtu edhe roli duhet ta lejojnë një dërgim para se ai të ndodhë, ndaj një rol që mban `emails:send` mbi një dhënie `viewer` nuk dërgon nga asnjë adresë. Kolona e ruajtur quhet `role`, dhe këtu riemërtohet që një Hash i vetëm të mos mbartë dy çelësa `role` të marrë nga dy fjalorë.
createdAtString or nil- Kur u shkrua rreshti i anëtarit të personit, si String ISO 8601, dhe nil kur nuk ka fare rresht anëtari. Ai nil përshkruan të njëjtin grup si `implied: true`: njerëz që mbajnë adresa që nga koha para roleve dhe të cilëve askush nuk u ka dhënë një rol që atëherë.
Ftesat
waiting = client.members.list_all_invitations waiting.each do |invitation| client.members.resend_invitation(invitation[:id]) if invitation[:expired]end client.members.revoke_invitation("winv_6bb640f5b99e47deb758f1f5")add përgjigjet me një ftesë, dhe këto janë thirrjet që e ndjekin. list_invitations kthen një OpenEmail::Page me ato që ende s’i ka pranuar askush, list_all_invitations i kthen të gjitha në një Array të vetëm, dhe iterate_invitations ia jep secilën një blloku ose kthen një Enumerator. resend_invitation e dërgon sërish një ftesë 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. Të dyja ngrihen si OpenEmail::ConflictError, ndaj conflict? është true dhe code i dallon.