Anëtarë
`members->list`, `listAll`, `iterate`, `get`, `add`, `update`, `remove`, `grantAddress`, `revokeAddress`, `grantDomain`, `revokeDomain` dhe metodat e ftesave pranë tyre.
Çdo metodë
$supportRoleId = 'role_8b1f4c2e9a7d3b60e5f1a2c4';$viewerRoleId = 'role_2c7e9a1f4b8d3e60c5a7f1b9'; $invitation = $client->members->add([ 'email' => '[email protected]', 'roleId' => $supportRoleId, 'addressIds' => ['2b81de07-9c3f-4a61-b8e2-5d07f4c19a36'], 'access' => 'member',]);echo $invitation['id'], ' ', $invitation['expiresAt'], PHP_EOL; foreach ($client->members->listAll() as $person) { echo $person['email'], ' ', $person['userId'], PHP_EOL;} $samId = 'q7Vd3kX9mT2pLw8RzN4bYc6HfJ1sGa5E';$member = $client->members->get($samId);echo $member['role']['name'], $member['implied'] ? ' (implied)' : '', PHP_EOL; $client->members->update($samId, ['roleId' => $viewerRoleId]); $addressId = 'c40a95f2-1e7b-4d38-a6c9-82f05b3d7e14';$client->members->grantAddress($samId, ['addressId' => $addressId, 'access' => 'viewer']);$client->members->revokeAddress($samId, $addressId); $removed = $client->members->remove($samId);echo $removed['addressesRevoked'], PHP_EOL;Dy dhënie të drejtash për person, dhe nuk duhen bashkuar në një. role është çfarë mund të bëjnë. addresses dhe domains janë mbi çfarë mund ta bëjnë. Të dyja duhet të pajtohen: një rol që mban emails:send me access të vendosur në 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 listAll 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ë listInvitations e ndjek ftesën. Trupi i add, update, grantAddress dhe grantDomain është një array i vetëm me çelësa sipas emrave camelCase të API-së (roleId, addressIds, addressId).
list kthen një OpenEmail\Result\Page, listAll i kthen të gjithë anëtarët në një array të vetëm, dhe iterate kthen një Generator që jep anëtarët një nga një. Një anëtar kthehet si array me çelësa në camelCase, dhe role është një array brenda tij, ndaj $member['role']['name'] lexon emrin e rolit.
Kur implied është true, askush nuk e ka zgjedhur rolin. Ata mbajnë adresa ose domene dhe asnjë rresht roli, pra roli 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ë, me isOwner true, ndërsa add, update dhe remove e refuzojnë prapëseprapë me member_is_owner, një 422 i hedhur si ValidationException. Një hapësirë pune e pandarë me të tjerë raporton një anëtar dhe jo asnjë, ndaj përjashtoni isOwner kur numëroni vendet: count(array_filter($client->members->listAll(), fn(array $member): bool => !$member['isOwner'])).
remove i heq të dy boshtet, rolin DHE çdo dhënie adrese dhe domeni në këtë hapësirë pune, dhe raporton në addressesRevoked sa dhënie hoqi, përfshirë ato të domeneve. revokeAddress është ai i ngushti, për dikë që ndërroi ekip dhe jo për dikë që u largua, dhe revokeDomain bën të njëjtën gjë për një domen të tërë.
add, update, remove dhe katër thirrjet e dhënies dhe të heqjes i kërkojnë një token-i aksesi OAuth një kod verifikimi, kurse një çelësi API kurrë. Derisa token-i të ketë një të tillë, ato hedhin një PermissionException me isStepUpRequired() true. add dhe grantDomain kërkojnë edhe një plan që përfshin një ekip, dhe në një plan që nuk e përfshin hedhin një PermissionException me errorCode të vendosur në plan_required.
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 zbatohen kur ata pranojnë. Dikush që është tashmë në hapësirën e punës është `member_is_owner` (422). Një adresë që hyn me një fjalëkalim të vetin nuk mund të ftohet dhe kthehet me `mailbox_login` (403), ndaj ftoni në vend të saj emailin e vetë personit.
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ë hedhur si `NotFoundException`. 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- 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`.
domainIdsarray- Domene të tëra që mbart ftesa, deri në 64 id, të dhëna kur ajo pranohet. Një dhënie domeni arrin çdo adresë të atij domeni, përfshirë ato që krijohen më vonë. Një id që nuk është domen në këtë hapësirë pune jep 422 `member_not_found`, njësoj si një adresë.
accessstring- Çfarë mund të bëjë personi me çdo id te `addressIds` dhe `domainIds`: `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 `grantAddress` 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` të vendosur në 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 katër thirrjet e dhënies dhe të heqjes. 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 null- Emri i shfaqur i personit, i marrë nga llogaria e tij, ku kolona mban gjithmonë një vlerë. null-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 null- Avatari i tyre, marrë nga llogaria e tyre, dhe null kur nuk kanë caktuar asnjë.
role.idstring or null- Id-ja e rolit që mban personi, e lexuar si `$member['role']['id']`, ose null kur nuk e zgjodhi askush. Shihni `implied`. Një null 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 null- Cili rol i integruar është roli, `owner`, `admin`, `member`, `viewer`, `developer` ose `billing`, ose null 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).
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 ose domenesh 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- 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- Adresat që u janë dhënë, të renditura sipas adresës, secila një array 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[].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ë array i vetëm të mos mbartë dy çelësa `role` të marrë nga dy fjalorë.
domainsarray- Domenet e tëra që i janë dhënë personit, secili me `domainId`, `domain` dhe `access`. Një dhënie domeni arrin çdo adresë në të, përfshirë ato që krijohen më vonë, ndaj lexojeni krahas `addresses` para se të vendosni që dikush nuk mund të arrijë një adresë. `grantDomain` dhe `revokeDomain` marrin `domainId`.
createdAtstring or null- Kur u shkrua rreshti i anëtarit të personit, si string ISO 8601, dhe null kur nuk ka fare rresht anëtari. Ai null përshkruan të njëjtin grup si `implied` true: njerëz që mbajnë dhënie që nga koha para roleve dhe të cilëve askush nuk u ka dhënë një rol që atëherë.
Ftesat
$waiting = $client->members->listAllInvitations(); foreach ($waiting as $invitation) { if ($invitation['expired']) { $client->members->resendInvitation($invitation['id']); }} $client->members->revokeInvitation('winv_6bb640f5b99e47deb758f1f5');add përgjigjet me një ftesë, dhe këto janë thirrjet që e ndjekin. listInvitations kthen një OpenEmail\Result\Page me ato që ende s’i ka pranuar askush, listAllInvitations i kthen të gjitha në një array të vetëm, dhe iterateInvitations kthen një Generator që i jep një nga një. resendInvitation e dërgon sërish një ftesë me një lidhje të re dhe katërmbëdhjetë ditë më shumë, dhe revokeInvitation e tërheq. Një ftesë në pritje nuk jep asgjë derisa të pranohet.
Një ftesë është një array me id, email, role, addresses, domains, expiresAt, expired, lastSentAt dhe createdAt. delivered dhe deliveryError tregojnë si shkoi emaili i fundit i ftesës, ndaj një skript mund ta dallojë një ftesë që u shkrua nga një që i mbërriti dikujt.
resendInvitation e refuzon të njëjtën adresë dy herë brenda dhjetë minutash me 409 invitation_too_soon, dhe revokeInvitation refuzon një ftesë që u pranua më parë me 409 invitation_accepted. Të dyja hidhen si ConflictException, ndaj isConflict() është true dhe errorCode i dallon.