सदस्य
`members->list`, `listAll`, `iterate`, `get`, `add`, `update`, `remove`, `grantAddress`, `revokeAddress`, `grantDomain`, `revokeDomain` और उनके साथ के invitation मेथड।
हर मेथड
$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;हर व्यक्ति के लिए दो अनुमतियाँ, और इन्हें एक में नहीं मिलाना चाहिए। role बताता है कि वे क्या कर सकते हैं। addresses और domains बताते हैं कि वे यह किस पर कर सकते हैं। दोनों का सहमत होना ज़रूरी है: invoices@ पर access के viewer होने के साथ emails:send वाली भूमिका का व्यक्ति मेल भेज सकता है, पर उस पते से नहीं भेज सकता। अपवाद addresses:all वाली भूमिका है, जो हर पते तक पहुँचती है चाहे addresses में कुछ भी हो, क्योंकि उस array में सिर्फ़ सीधी अनुमतियाँ होती हैं। इसलिए addresses को किसी की पूरी पहुँच मानने से पहले permissions जाँचें।
किसी एक व्यक्ति से जुड़ी हर कॉल उसका userId पहले आर्ग्युमेंट के रूप में लेती है, उसका ईमेल नहीं, इसलिए उसे नमूने की तरह list या listAll से पढ़ें। add अकेला अपवाद है, क्योंकि यह एक पते को आमंत्रित करता है: व्यक्ति के पास userId तभी होता है जब वह स्वीकार कर ले, और तब तक listInvitations आमंत्रण पर नज़र रखता है। add, update, grantAddress और grantDomain की बॉडी API के camelCase नामों (roleId, addressIds, addressId) वाला एक array है।
list एक OpenEmail\Result\Page लौटाता है, listAll हर सदस्य एक array में लौटाता है, और iterate एक Generator लौटाता है जो एक बार में एक सदस्य yield करता है। सदस्य camelCase कुंजियों वाले array के रूप में लौटता है, और role उसके भीतर एक array है, इसलिए $member['role']['name'] भूमिका का नाम पढ़ता है।
implied true का मतलब है कि किसी ने भूमिका नहीं चुनी। उनके पास पते या डोमेन हैं और भूमिका की कोई पंक्ति नहीं, इसलिए यह उनकी सबसे व्यापक अनुमति से अनुमानित की गई। इसे “अभी तय नहीं” मानें, और update ही अनुमान को फ़ैसले में बदलता है। तब तक, उनकी पते की पहुँच बढ़ाने से वे क्या कर सकते हैं यह भी चुपचाप बढ़ जाता है।
वर्कस्पेस का मालिक पहली पंक्ति है, isOwner true के साथ, जबकि add, update और remove फिर भी उसे member_is_owner के साथ अस्वीकार करते हैं, जो ValidationException के रूप में throw होने वाला 422 है। साझा न किया गया वर्कस्पेस कोई नहीं के बजाय एक सदस्य बताता है, इसलिए seats गिनते समय isOwner को बाहर रखें: count(array_filter($client->members->listAll(), fn(array $member): bool => !$member['isOwner']))।
remove दोनों धुरियाँ हटाता है, भूमिका “और” इस वर्कस्पेस पर पते और डोमेन की हर अनुमति, और addressesRevoked में बताता है कि उसने डोमेन समेत कितनी अनुमतियाँ वापस लीं। revokeAddress सीमित वाला है, उस व्यक्ति के लिए जिसने टीम बदली, न कि जो चला गया, और revokeDomain पूरे डोमेन के लिए यही करता है।
add, update, remove और अनुमति देने व वापस लेने वाली चार कॉल OAuth access टोकन से सत्यापन कोड माँगती हैं, और API कुंजी से कभी नहीं। जब तक टोकन के पास कोड न हो, वे ऐसा PermissionException throw करती हैं जिसका isStepUpRequired() true होता है। add और grantDomain को टीम वाला plan भी चाहिए, और जिस plan में टीम नहीं है उस पर वे errorCode में plan_required वाला PermissionException throw करते हैं।
पैरामीटर
emailstringआवश्यक- किसे आमंत्रित करना है, trim और lowercase किया हुआ। उसका अभी खाता होना ज़रूरी नहीं: हर किसी को आमंत्रित किया जाता है, और भूमिका व अनुमतियाँ स्वीकार करने पर लागू होती हैं। वर्कस्पेस में पहले से मौजूद व्यक्ति `member_is_owner` (422) है। जो पता अपने पासवर्ड से साइन इन करता है उसे आमंत्रित नहीं किया जा सकता और वह `mailbox_login` (403) लौटाता है, इसलिए इसके बजाय उस व्यक्ति का अपना ईमेल आमंत्रित करें।
roleIdstringआवश्यक- वह भूमिका जो उनके पास होगी, 1 से 128 अक्षर, और यह इस वर्कस्पेस की भूमिका होनी चाहिए: अज्ञात id `role_not_found` (404) है, जो `NotFoundException` के रूप में throw होता है। मालिक की भूमिका नहीं दी जा सकती और `role_immutable` (409) लौटाती है, क्योंकि किसी को मालिक बनाना वर्कस्पेस का हस्तांतरण है और उसके लिए यहाँ कोई कॉल नहीं है।
addressIdsarray- वे पते जो आमंत्रण साथ ले जाता है, अधिकतम 64 id, हर एक 1 से 128 वर्ण की, जो आमंत्रण स्वीकार होने पर दिए जाते हैं। कुछ भी लिखे जाने से पहले हर id जाँची जाती है, इसलिए ऐसी id जो इस वर्कस्पेस का पता नहीं है, पूरी कॉल को 422 `member_not_found` के साथ अस्वीकार करवा देती है और कुछ नहीं भेजा जाता। उसी पते को दस मिनट के भीतर फिर से आमंत्रित करना 409 `invitation_too_soon` है।
domainIdsarray- आमंत्रण में शामिल पूरे डोमेन, अधिकतम 64 id, जो स्वीकार होने पर दिए जाते हैं। डोमेन की अनुमति उस डोमेन के हर पते तक पहुँचती है, बाद में बने पतों समेत। जो id इस वर्कस्पेस का डोमेन नहीं है वह, पते की तरह, 422 `member_not_found` है।
accessstring- वे `addressIds` और `domainIds` की हर id के साथ क्या कर सकते हैं: `member` पता पढ़ता है और उससे भेजता है, `viewer` सिर्फ़ पढ़ता है। डिफ़ॉल्ट `member` है, वह स्तर जिसे console और पुराना sharing तरीक़ा हमेशा से इस्तेमाल करते आए हैं, इसलिए एक ही कॉल का मतलब स्क्रिप्ट से और स्क्रीन से एक ही होता है। मिला-जुला स्तर देने के लिए, जो अलग हों उनके लिए बाद में `grantAddress` कॉल करें।
प्रतिक्रिया
objectstring- हमेशा `member`। हटाने पर इसी मान, उनके `userId`, true पर सेट `deleted` और `addressesRevoked` के साथ जवाब आता है, और नीचे के बाकी फ़ील्ड में से कोई नहीं।
userIdstring- उनके खाते की id, और वह handle जिसे सदस्य की हर दूसरी कॉल पहले आर्ग्युमेंट के रूप में लेती है: `get`, `update`, `remove` और अनुमति देने व वापस लेने वाली चार कॉल। किसी को जोड़ना अकेली कॉल है जो इसके बजाय ईमेल से काम करती है, क्योंकि सहकर्मी को जोड़ने वाला उसका पता जानता है, उसकी id नहीं।
emailstring- उनके अकाउंट पर मौजूद ईमेल, जैसा वह पंक्ति उसे रखती है। यह resource इसे कभी लिखता नहीं, और `add` पर होने वाली lower-casing उस पते पर लागू होती है जो आप खोज के लिए भेजते हैं, न कि उस पर जो लौटता है। मालिक के बाद, सदस्यों की सूची इसी से क्रमित होती है, न कि इससे कि लोग कब जुड़े, क्योंकि यह सूची यह देखने के लिए नहीं कि क्या बदला, बल्कि एक व्यक्ति ढूँढने के लिए पढ़ी जाती है।
namestring or null- उनका display name, उनके खाते से लिया गया, जहाँ column में हमेशा एक मान होता है। टाइप में null सावधानी के लिए है, न कि कोई ऐसी स्थिति जो यह API देता हुआ देखा गया हो। यह वर्कस्पेस का नहीं, उनका अपना है, इसलिए इस resource पर कुछ भी इसे सेट नहीं कर सकता।
imagestring or null- उनका avatar, उनके अकाउंट से लिया गया, और जब उन्होंने कोई सेट नहीं किया तो null।
role.idstring or null- उनके पास जो भूमिका है उसकी id, जिसे `$member['role']['id']` के रूप में पढ़ा जाता है, या null जब किसी ने उसे नहीं चुना। `implied` देखें। यहाँ null अकेला ऐसा मामला है जहाँ `role` किसी के फ़ैसले के बजाय एक अनुमान बताता है।
role.namestring- भूमिका का नाम। अनुमानित सदस्य के लिए यह उस built-in template का नाम है जिससे उनकी पहुँच मेल खाती है, इस वर्कस्पेस की कोई पंक्ति नहीं।
role.builtinstring or null- भूमिका कौन-सी built-in है, `owner`, `admin`, `member`, `viewer`, `developer` या `billing`, या custom भूमिका के लिए null। `owner` सिर्फ़ मालिक की अपनी पंक्ति पर, `isOwner` true के साथ दिखता है। यह भूमिका किसी को सौंपना `role_immutable` (409) के साथ अस्वीकार होता है।
isOwnerbool- ठीक एक पंक्ति पर true: वह अकाउंट जिस पर वर्कस्पेस टिका है। उनकी role पंक्ति जो भी कहे, उनके पास हर अनुमति होती है, वे सबसे पहले क्रमित होते हैं, और `add`, `update` तथा `remove` तीनों उन्हें `member_is_owner` के साथ मना कर देते हैं। सीटें गिनते समय उन्हें छोड़ दें।
impliedbool- true तब, जब इस व्यक्ति के पास पते या डोमेन की अनुमतियाँ हों और सदस्य की कोई पंक्ति न हो, यानी उसकी भूमिका चुनी नहीं गई बल्कि अनुमानित की गई: `member` की कोई भी अनुमति इसे built-in Member बनाती है, वरना Viewer। मालिक के लिए कभी true नहीं। इसे “पहुँच से अनुमानित” के रूप में दिखाएँ। जब तक कोई `update` अनुमान को फ़ैसले में न बदले, उनकी पते की पहुँच बढ़ाने से वे क्या कर सकते हैं यह भी चुपचाप बढ़ जाता है।
permissionsarray- भूमिका की अनुमतियाँ सदस्य पर समतल की गईं, ताकि एक read भूमिका लाए बिना “क्या वे कर सकते हैं?” का जवाब दे दे। अनुमानित सदस्य के लिए ये इस वर्कस्पेस की भूमिका पंक्ति से नहीं, built-in “template” से आती हैं, इसलिए built-in Member भूमिका संपादित करने से यह नहीं बदलता कि अनुमानित सदस्य के पास क्या है।
addressesarray- उन्हें दिए गए पते, पते के अनुसार क्रमबद्ध, हर एक अपने access स्तर के साथ एक array। भूमिका वाले पर बिना अनुमति वाले व्यक्ति के लिए ख़ाली, जो किसी पते की अनुमति मिलने तक नया सदस्य ऐसा ही दिखता है, और जब आप अभी तय कर रहे हों कि उन्हें क्या दिखना चाहिए, तब यही सही विफलता है।
addresses[].addressIdstring- पते की id, और वही जो `grantAddress` और `revokeAddress` लेते हैं। ऐसी id जो इस वर्कस्पेस का पता नहीं है, दोनों पर अस्वीकार की जाती है, न कि ऐसा निरसन बताया जाता है जो हुआ ही नहीं।
addresses[].addressstring- पूरा पता, lower-case में, उसके local भाग और उसके डोमेन से दोबारा बनाया हुआ।
addresses[].accessstring- वे इस एक पते के साथ क्या कर सकते हैं: `member` उसे पढ़ता है और उससे भेजता है, `viewer` सिर्फ़ पढ़ता है। send होने से पहले यह और भूमिका दोनों को उसकी अनुमति देनी होती है, इसलिए `viewer` अनुमति के ऊपर `emails:send` वाली भूमिका कहीं से नहीं भेजती। सहेजे गए column का नाम `role` है, और यहाँ इसका नाम बदला गया है ताकि एक array में दो शब्दावलियों से आई दो `role` कुंजियाँ न हों।
domainsarray- उन्हें दिए गए पूरे डोमेन, हर एक `domainId`, `domain` और `access` के साथ। डोमेन की अनुमति उसके हर पते तक पहुँचती है, बाद में बने पतों समेत, इसलिए यह तय करने से पहले कि कोई किसी पते तक नहीं पहुँच सकता, इसे `addresses` के साथ पढ़ें। `grantDomain` और `revokeDomain` `domainId` लेते हैं।
createdAtstring or null- उनकी सदस्य पंक्ति कब लिखी गई, ISO 8601 स्ट्रिंग के रूप में, और जब कोई सदस्य पंक्ति ही न हो तो null। यह null वही समूह बताता है जो `implied` true बताता है: वे लोग जिनके पास भूमिकाओं के आने से पहले की अनुमतियाँ हैं और जिन्हें तब से किसी ने भूमिका नहीं दी।
आमंत्रण
$waiting = $client->members->listAllInvitations(); foreach ($waiting as $invitation) { if ($invitation['expired']) { $client->members->resendInvitation($invitation['id']); }} $client->members->revokeInvitation('winv_6bb640f5b99e47deb758f1f5');add एक आमंत्रण के साथ जवाब देता है, और ये वे कॉल हैं जो उसके बाद आती हैं। listInvitations उन आमंत्रणों का एक OpenEmail\Result\Page लौटाता है जिन्हें अभी किसी ने स्वीकार नहीं किया, listAllInvitations उन सबको एक array में लौटाता है, और iterateInvitations एक Generator लौटाता है जो एक बार में एक yield करता है। resendInvitation नए link और चौदह और दिनों के साथ उसे फिर भेजता है, और revokeInvitation उसे वापस लेता है। इंतज़ार कर रहा आमंत्रण स्वीकार होने तक कुछ नहीं देता।
आमंत्रण id, email, role, addresses, domains, expiresAt, expired, lastSentAt और createdAt वाला एक array है। delivered और deliveryError बताते हैं कि आख़िरी आमंत्रण ईमेल का क्या हुआ, ताकि स्क्रिप्ट लिखे गए आमंत्रण और किसी तक पहुँचे आमंत्रण में फ़र्क़ कर सके।
resendInvitation दस मिनट के भीतर उसी पते को दूसरी बार 409 invitation_too_soon के साथ अस्वीकार करता है, और revokeInvitation पहले ही स्वीकार हो चुके आमंत्रण को 409 invitation_accepted के साथ अस्वीकार करता है। दोनों ConflictException के रूप में throw होते हैं, इसलिए isConflict() true होता है और errorCode उन्हें अलग बताता है।