SDK
सदस्य
`members.list`, `get`, `add`, `update`, `remove`, `grantAddress` और `revokeAddress`।
हर method
const people = await openemail.members.list()const member = await openemail.members.get(people[0]!.userId) const sam = await openemail.members.add({ email: '[email protected]', roleId: support.id, addressIds: ['2b81de07-…'], access: 'member',}) await openemail.members.update(sam.userId, { roleId: viewerRoleId }) await openemail.members.grantAddress(sam.userId, { addressId: 'c40a95f2-…', access: 'viewer',})await openemail.members.revokeAddress(sam.userId, 'c40a95f2-…') await openemail.members.remove(sam.userId)हर व्यक्ति पर दो grant होते हैं और उन्हें एक में मिलाना नहीं चाहिए। role बताता है कि वे क्या कर सकते हैं; addresses बताता है कि किस पर। दोनों का सहमत होना ज़रूरी है: emails:send रखने वाली role के साथ invoices@ पर access: "viewer" का मतलब है ऐसा व्यक्ति जो मेल भेज सकता है पर उस पते से नहीं भेज सकता।
हर method userId लेता है, ईमेल नहीं। add अकेला अपवाद है, और यही अपवाद की वजह भी है: उसके कॉल करने वाले के पास ईमेल पता है और अभी कोई user id नहीं, और वही उस कॉल का पहला आधा काम है।
implied: true का अर्थ है कि role किसी ने चुनी ही नहीं। उनके पास पते हैं और कोई member पंक्ति नहीं, इसलिए role उनके सबसे चौड़े grant से अनुमानित की गई। इसे “अभी तय नहीं” मानें, और update ही वह है जो अनुमान को निर्णय में बदलता है। तब तक, उनकी पता-पहुँच चौड़ी करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।
वर्कस्पेस का मालिक पहली पंक्ति होता है, isOwner: true से चिह्नित, जबकि add, update और remove फिर भी उसे member_is_owner के साथ मना कर देते हैं। बिना साझा किया गया वर्कस्पेस शून्य नहीं बल्कि एक सदस्य बताता है, इसलिए सीटें गिनते समय isOwner को छोड़ दें।
remove दोनों अक्ष लेता है — role और इस वर्कस्पेस पर हर पता grant — और addressesRevoked बताता है। revokeAddress संकरा वाला है, उस व्यक्ति के लिए जिसने टीम बदली, न कि उसके लिए जो चला गया।
पैरामीटर
emailstringआवश्यक- किसे आमंत्रित करना है, trim और lower-case करके। उनका अकाउंट होना अभी ज़रूरी नहीं: आमंत्रण सबको जाता है, और role तथा grant तब लगते हैं जब वे स्वीकार करते हैं। जो पहले से वर्कस्पेस में है, वह `member_is_owner` (422) है।
roleIdstringआवश्यक- वह role जो उनके पास होगी, 1 से 128 वर्ण, और वह इसी वर्कस्पेस की role होनी चाहिए: अनजान id `role_not_found` (404) है। owner role बाँटी नहीं जा सकती और `role_immutable` (409) लौटती है, क्योंकि किसी को owner बनाना वर्कस्पेस हस्तांतरण है और यहाँ उसके लिए कोई कॉल नहीं है।
addressIdsstring[]- उसी कॉल में सौंपे जाने वाले पते, अधिकतम 64 id, हर एक 1 से 128 वर्ण की; ऐसी id जो इस वर्कस्पेस का पता नहीं है, अस्वीकार कर दी जाती है। पहले role लिखी जाती है और फिर grant एक-एक करके, इसलिए एक खराब id के बाद सदस्य आपके माँगे से कम पतों के साथ बन जाता है। वही body दोबारा POST करना इसका इलाज है, क्योंकि दोनों लेखन upsert हैं।
access'member' | 'viewer'- `addressIds` की हर id के साथ वे क्या कर सकते हैं: `member` पता पढ़ता है और उससे भेजता है, `viewer` केवल पढ़ता है। डिफ़ॉल्ट `member` है, वही स्तर जो कंसोल और पुराना साझाकरण रास्ता हमेशा इस्तेमाल करते आए हैं, ताकि एक ही कॉल का अर्थ स्क्रिप्ट से और स्क्रीन से एक ही रहे; मिला-जुला grant चाहिए तो जो अलग हैं उनके लिए बाद में `grantAddress` कॉल करें।
रिस्पॉन्स
object'member'- हमेशा `member`। हटाने पर वही मान, उनका `userId`, `deleted: true` और `addressesRevoked` लौटते हैं, और नीचे के बाकी फ़ील्ड कोई नहीं।
userIdstring- उनकी अकाउंट id, और वही handle जो बाकी हर member कॉल path में लेता है: get, update, remove और दोनों पता कॉल। किसी को जोड़ना अकेला ऐसा कॉल है जो इसके बजाय ईमेल से चलता है, क्योंकि जो सहकर्मी को जोड़ रहा है उसे उसका पता पता होता है, id नहीं।
emailstring- उनके अकाउंट पर मौजूद ईमेल, जैसा वह पंक्ति उसे रखती है। यह resource इसे कभी लिखता नहीं, और `add` पर होने वाली lower-casing उस पते पर लागू होती है जो आप खोज के लिए भेजते हैं, न कि उस पर जो लौटता है। मालिक के बाद, सदस्यों की सूची इसी से क्रमित होती है, न कि इससे कि लोग कब जुड़े, क्योंकि यह सूची यह देखने के लिए नहीं कि क्या बदला, बल्कि एक व्यक्ति ढूँढने के लिए पढ़ी जाती है।
namestring | null- उनका प्रदर्शित नाम, उनके अकाउंट से लिया गया, जहाँ वह column NOT NULL है। type में मौजूद null एहतियात है, न कि ऐसी स्थिति जो इस API में देखी गई हो। यह वर्कस्पेस का नहीं उनका अपना है, इसलिए इस resource पर कुछ भी इसे सेट नहीं कर सकता।
imagestring | null- उनका avatar, उनके अकाउंट से लिया गया, और जब उन्होंने कोई सेट नहीं किया तो null।
role.idstring | null- उनके पास जो role है उसकी id, या null जब किसी ने उसे चुना ही नहीं। देखें `implied`। यहाँ null वही एक स्थिति है जहाँ `role` किसी के लिए गए निर्णय के बजाय एक अनुमान बताता है।
role.namestring- role का नाम। implied सदस्य के लिए यह उस अंतर्निहित template का नाम है जिस पर उनकी पहुँच हल हुई, न कि इस वर्कस्पेस की कोई पंक्ति।
role.builtin'owner' | 'admin' | 'member' | 'viewer' | 'developer' | 'billing' | null- role कौन-सी अंतर्निहित है, या कस्टम के लिए null। `owner` केवल मालिक की अपनी पंक्ति पर आता है, `isOwner: true` के साथ; वह role किसी को देना `role_immutable` (409) के साथ अस्वीकार होता है।
isOwnerboolean- ठीक एक पंक्ति पर true — वह अकाउंट जिस पर वर्कस्पेस टिका है। उनकी role पंक्ति जो भी कहे, उनके पास हर अनुमति होती है, वे सबसे पहले क्रमित होते हैं, और `add`, `update` तथा `remove` तीनों उन्हें `member_is_owner` के साथ मना कर देते हैं। सीटें गिनते समय उन्हें छोड़ दें।
impliedboolean- true तब, जब इस व्यक्ति के पास पता grant हैं और कोई member पंक्ति नहीं, यानी उनकी role चुनी नहीं बल्कि अनुमानित की गई: `member` का कोई भी grant अंतर्निहित Member पर हल होता है, अन्यथा Viewer। मालिक के लिए यह कभी true नहीं। इसे "पहुँच से अनुमानित" के रूप में दिखाएँ। जब तक कोई PATCH अनुमान को निर्णय में नहीं बदलता, उनकी पता-पहुँच चौड़ी करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।
permissionsPermission[]- role की अनुमतियाँ सदस्य पर सपाट कर दी जाती हैं, ताकि एक ही read "क्या वे कर सकते हैं?" का उत्तर role लाए बिना दे दे। implied सदस्य के लिए ये इस वर्कस्पेस की role पंक्ति से नहीं बल्कि अंतर्निहित TEMPLATE से आती हैं, इसलिए अंतर्निहित Member role बदलने से implied सदस्य के पास जो है वह नहीं बदलता।
addressesMemberAddress[]- उन्हें दिए गए पते, पते के क्रम में, हर एक अपने पहुँच स्तर के साथ। जिसके पास role है और कोई grant नहीं, उसके लिए खाली — नया सदस्य पता मिलने तक ऐसा ही दिखता है, और जब तक आप तय कर रहे हैं कि उन्हें क्या दिखना चाहिए, यही सही विफलता है।
addresses[].addressIdstring- पते की id, और वही जो `grantAddress` और `revokeAddress` लेते हैं। ऐसी id जो इस वर्कस्पेस का पता नहीं है, दोनों पर अस्वीकार की जाती है, न कि ऐसा निरसन बताया जाता है जो हुआ ही नहीं।
addresses[].addressstring- पूरा पता, lower-case में, उसके local भाग और उसके डोमेन से दोबारा बनाया हुआ।
addresses[].access'member' | 'viewer'- इस एक पते के साथ वे क्या कर सकते हैं: `member` इसे पढ़ता है और इससे भेजता है, `viewer` केवल पढ़ता है। भेजने से पहले इसे और role दोनों को अनुमति देनी होती है, इसलिए `viewer` grant पर `emails:send` रखने वाली role किसी भी पते से नहीं भेजती; संग्रहीत column का नाम `role` है, और यहाँ उसका नाम बदला गया है ताकि एक object दो अलग शब्दावलियों से लिए गए दो `role` न ढोए।
createdAtstring | null- उनकी member पंक्ति कब लिखी गई, ISO-8601, और जब member पंक्ति है ही नहीं तो null। वह null उसी समूह का वर्णन करता है जिसका `implied: true`: वे लोग जिनके पास role के अस्तित्व में आने से पहले के पते हैं और जिन्हें तब से किसी ने role नहीं दी।