सदस्य
`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address`, और उनके साथ के invitation मेथड।
हर मेथड
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]हर व्यक्ति के दो grants होते हैं, और इन्हें एक में नहीं मिलाना चाहिए। role बताता है कि वह क्या कर सकता है। addresses बताता है कि किस पर। दोनों का सहमत होना ज़रूरी है: invoices@ पर access: "viewer" के साथ emails:send वाली भूमिका ऐसा व्यक्ति है जो मेल भेज सकता है पर उस पते से नहीं भेज सकता। अपवाद addresses:all वाली भूमिका है, जो addresses में जो भी सूचीबद्ध हो, हर पते तक पहुँचती है, क्योंकि उस Array में सिर्फ़ सीधे grants होते हैं। इसलिए addresses को किसी की पूरी पहुँच मानने से पहले permissions जाँचें।
किसी एक व्यक्ति के बारे में हर कॉल उसका userId पहले argument के रूप में लेती है, उसका ईमेल नहीं, इसलिए इसे list या list_all से पढ़ें, जैसा नमूना करता है। add अकेला अपवाद है, क्योंकि यह एक पते को आमंत्रित करता है: व्यक्ति के पास userId तभी होता है जब वह स्वीकार करे, और तब तक list_invitations आमंत्रण का पीछा करता है। रिक्वेस्ट बॉडी के फ़ील्ड API के camelCase नाम बनाए रखते हैं (roleId:, addressIds:, addressId:), keywords या एक Hash के रूप में दिए जाते हैं।
list एक OpenEmail::Page लौटाता है, list_all हर सदस्य एक Array में लौटाता है, और iterate हर सदस्य को block में yield करता है या block के बिना एक Enumerator लौटाता है। सदस्य Symbol कुंजियों वाले Hash के रूप में लौटता है, और role उसके अंदर एक Hash है, इसलिए member.dig(:role, :name) भूमिका का नाम पढ़ता है।
implied: true का अर्थ है कि role किसी ने चुनी ही नहीं। उनके पास पते हैं और कोई member पंक्ति नहीं, इसलिए role उनके सबसे चौड़े grant से अनुमानित की गई। इसे “अभी तय नहीं” मानें, और update ही वह है जो अनुमान को निर्णय में बदलता है। तब तक, उनकी पता-पहुँच चौड़ी करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।
वर्कस्पेस का मालिक पहली पंक्ति है, isOwner: true से चिह्नित, जबकि add, update और remove फिर भी उसे member_is_owner के साथ अस्वीकार करते हैं, एक 422 जो OpenEmail::ValidationError के रूप में raise होता है। जो वर्कस्पेस साझा नहीं किया गया वह शून्य नहीं, एक सदस्य बताता है, इसलिए seats गिनते समय isOwner को बाहर रखें: client.members.list_all.count { |member| !member[:isOwner] }।
remove दोनों धुरियाँ हटाता है, भूमिका “और” इस वर्कस्पेस पर हर पता grant, और addressesRevoked बताता है। revoke_address संकरा वाला है, उस व्यक्ति के लिए जिसकी टीम बदली, न कि जो चला गया।
पैरामीटर
emailStringआवश्यक- किसे आमंत्रित करना है, trim और lower-case करके। उनका अकाउंट होना अभी ज़रूरी नहीं: आमंत्रण सबको जाता है, और role तथा grant तब लगते हैं जब वे स्वीकार करते हैं। जो पहले से वर्कस्पेस में है, वह `member_is_owner` (422) है।
roleIdStringआवश्यक- वह भूमिका जो उसके पास होगी, 1 से 128 वर्ण, और यह इसी वर्कस्पेस की भूमिका होनी चाहिए: अज्ञात id `role_not_found` (404) है, जो `OpenEmail::NotFoundError` के रूप में raise होता है। मालिक की भूमिका किसी को नहीं दी जा सकती और `role_immutable` (409) लौटाती है, क्योंकि किसी को मालिक बनाना वर्कस्पेस का हस्तांतरण है और उसके लिए यहाँ कोई कॉल नहीं है।
addressIdsArray<String>- वे पते जो आमंत्रण साथ ले जाता है, अधिकतम 64 id, हर एक 1 से 128 वर्ण की, जो आमंत्रण स्वीकार होने पर दिए जाते हैं। कुछ भी लिखे जाने से पहले हर id जाँची जाती है, इसलिए ऐसी id जो इस वर्कस्पेस का पता नहीं है, पूरी कॉल को 422 `member_not_found` के साथ अस्वीकार करवा देती है और कुछ नहीं भेजा जाता। उसी पते को दस मिनट के भीतर फिर से आमंत्रित करना 409 `invitation_too_soon` है।
accessString- `addressIds` की हर id के साथ वह क्या कर सकता है: `member` पता पढ़ता है और उससे भेजता है, `viewer` सिर्फ़ पढ़ता है। डिफ़ॉल्ट `member` है, वही स्तर जो console और पुराना sharing रास्ता हमेशा इस्तेमाल करते आए हैं, ताकि एक ही कॉल का मतलब स्क्रिप्ट से और स्क्रीन से एक ही हो। मिला-जुला देने के लिए बाद में अलग वालों के लिए `grant_address` कॉल करें।
प्रतिक्रिया
objectString- हमेशा `member`। हटाने पर वही मान, उनका `userId`, `deleted: true` और `addressesRevoked` लौटते हैं, और नीचे के बाकी फ़ील्ड कोई नहीं।
userIdString- उनकी खाता id, और वह हैंडल जिसे सदस्यों वाली हर दूसरी कॉल पहले argument के रूप में लेती है: `get`, `update`, `remove` और दोनों पता कॉल। किसी को जोड़ना अकेली कॉल है जो इसकी जगह ईमेल से काम करती है, क्योंकि जो कोई सहकर्मी को जोड़ रहा है वह उसका पता जानता है, id नहीं।
emailString- उनके अकाउंट पर मौजूद ईमेल, जैसा वह पंक्ति उसे रखती है। यह resource इसे कभी लिखता नहीं, और `add` पर होने वाली lower-casing उस पते पर लागू होती है जो आप खोज के लिए भेजते हैं, न कि उस पर जो लौटता है। मालिक के बाद, सदस्यों की सूची इसी से क्रमित होती है, न कि इससे कि लोग कब जुड़े, क्योंकि यह सूची यह देखने के लिए नहीं कि क्या बदला, बल्कि एक व्यक्ति ढूँढने के लिए पढ़ी जाती है।
nameString or nil- उनका display name, उनके खाते से लिया गया, जहाँ कॉलम में हमेशा कोई मान होता है। टाइप में nil एहतियातन है, ऐसी स्थिति नहीं जो यह API बनाते देखा गया हो। यह वर्कस्पेस का नहीं, उनका है, इसलिए इस resource पर कुछ भी इसे सेट नहीं कर सकता।
imageString or nil- उनका avatar, उनके खाते से लिया गया, और nil जब उन्होंने कोई सेट न किया हो।
role.idString or nil- उनके पास मौजूद भूमिका की id, `member.dig(:role, :id)` के रूप में पढ़ी जाती है, या nil जब किसी ने उसे चुना न हो। `implied` देखें। यहाँ nil अकेला मामला है जहाँ `role` किसी के लिए गए फ़ैसले के बजाय एक अनुमान बताता है।
role.nameString- भूमिका का नाम। अनुमानित सदस्य के लिए यह उस built-in template का नाम है जिससे उनकी पहुँच मेल खाती है, इस वर्कस्पेस की कोई पंक्ति नहीं।
role.builtinString or nil- भूमिका कौन-सी built-in है, `owner`, `admin`, `member`, `viewer`, `developer` या `billing`, या कस्टम भूमिका के लिए nil। `owner` सिर्फ़ मालिक की अपनी पंक्ति पर, `isOwner: true` के साथ दिखता है। वह भूमिका किसी को देना `role_immutable` (409) के साथ अस्वीकार होता है।
isOwnerBoolean- ठीक एक पंक्ति पर true: वह अकाउंट जिस पर वर्कस्पेस टिका है। उनकी role पंक्ति जो भी कहे, उनके पास हर अनुमति होती है, वे सबसे पहले क्रमित होते हैं, और `add`, `update` तथा `remove` तीनों उन्हें `member_is_owner` के साथ मना कर देते हैं। सीटें गिनते समय उन्हें छोड़ दें।
impliedBoolean- तब true जब इस व्यक्ति के पास पता grants हों और सदस्य पंक्ति न हो, यानी उनकी भूमिका चुनी नहीं गई बल्कि अनुमानित है: `member` का कोई भी grant उसे built-in Member बनाता है, वरना Viewer। मालिक के लिए कभी true नहीं। इसे “पहुँच से निहित” के रूप में दिखाएँ। जब तक कोई `update` इस अनुमान को फ़ैसले में न बदल दे, उनकी पता पहुँच बढ़ाना चुपचाप यह भी बढ़ा देता है कि वे क्या कर सकते हैं।
permissionsArray<String>- भूमिका की अनुमतियाँ सदस्य पर समतल की गईं, ताकि एक read भूमिका लाए बिना “क्या वे कर सकते हैं?” का जवाब दे दे। अनुमानित सदस्य के लिए ये इस वर्कस्पेस की भूमिका पंक्ति से नहीं, built-in “template” से आती हैं, इसलिए built-in Member भूमिका संपादित करने से यह नहीं बदलता कि अनुमानित सदस्य के पास क्या है।
addressesArray<Hash>- उन्हें दिए गए पते, पते के क्रम में, हर एक अपने पहुँच स्तर के साथ। जिसके पास role है और कोई grant नहीं, उसके लिए खाली। नया सदस्य पता मिलने तक ऐसा ही दिखता है, और जब तक आप तय कर रहे हैं कि उन्हें क्या दिखना चाहिए, यही सही विफलता है।
addresses[].addressIdString- पते की id, और वही जो `grant_address` और `revoke_address` लेते हैं। जो id इस वर्कस्पेस का पता नहीं है वह दोनों पर अस्वीकार होती है, ऐसी वापसी बताने के बजाय जो कभी हुई ही नहीं।
addresses[].addressString- पूरा पता, lower-case में, उसके local भाग और उसके डोमेन से दोबारा बनाया हुआ।
addresses[].accessString- इस एक पते के साथ वे क्या कर सकते हैं: `member` इसे पढ़ता है और इससे भेजता है, `viewer` सिर्फ़ पढ़ता है। send होने से पहले इसे और भूमिका दोनों को अनुमति देनी होती है, इसलिए `viewer` grant पर `emails:send` वाली भूमिका किसी पते से नहीं भेजती। सहेजे गए कॉलम का नाम `role` है, और यहाँ इसका नाम बदला गया है ताकि एक Hash में दो शब्दावलियों से आई दो `role` कुंजियाँ न हों।
createdAtString or nil- उनकी सदस्य पंक्ति कब लिखी गई, ISO 8601 String के रूप में, और nil जब कोई सदस्य पंक्ति है ही नहीं। वह nil उसी आबादी को बताता है जिसे `implied: true`: वे लोग जिनके पास भूमिकाओं के आने से पहले से पते हैं और जिन्हें तब से किसी ने भूमिका नहीं दी।
आमंत्रण
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 एक आमंत्रण के साथ जवाब देता है, और ये वे कॉल हैं जो उसका पीछा करती हैं। list_invitations उन आमंत्रणों का एक OpenEmail::Page लौटाता है जिन्हें अभी किसी ने स्वीकार नहीं किया, list_all_invitations उन सबको एक Array में लौटाता है, और iterate_invitations हर एक को block में yield करता है या एक Enumerator लौटाता है। resend_invitation नए लिंक और चौदह और दिनों के साथ उसे फिर भेजता है, और revoke_invitation उसे वापस लेता है। इंतज़ार कर रहा आमंत्रण स्वीकार होने तक कुछ नहीं देता।
resend_invitation दस मिनट के भीतर उसी पते को दूसरी बार 409 invitation_too_soon के साथ अस्वीकार करता है, और revoke_invitation पहले से स्वीकार हुए आमंत्रण को 409 invitation_accepted के साथ अस्वीकार करता है। दोनों OpenEmail::ConflictError के रूप में raise होते हैं, इसलिए conflict? true है और code उन्हें अलग बताता है।