Python

सदस्य

`members.list`, `list_all`, `iterate`, `get`, `add`, `update`, `remove`, `grant_address`, `revoke_address`, और उनके साथ आमंत्रण के methods।

हर मेथड

members.py

from openemail import openemail roles = openemail.roles.list_all()support = next(role for role in roles if role['name'] == 'Support')viewer = next(role for role in roles if role['builtin'] == 'viewer') invitation = openemail.members.add({    'email': '[email protected]',    'roleId': support['id'],    'addressIds': ['2b81de07-…'],    'access': 'member',}) people = openemail.members.list_all()sam = next(person for person in people if person['email'] == '[email protected]')member = openemail.members.get(sam['userId']) openemail.members.update(sam['userId'], {'roleId': viewer['id']}) openemail.members.grant_address(sam['userId'], {    'addressId': 'c40a95f2-…',    'access': 'viewer',})openemail.members.revoke_address(sam['userId'], 'c40a95f2-…') openemail.members.remove(sam['userId'])

हर व्यक्ति पर दो grant होते हैं और उन्हें एक में मिलाना नहीं चाहिए। role बताता है कि वे क्या कर सकते हैं; addresses बताता है कि किस पर। दोनों का सहमत होना ज़रूरी है: emails:send रखने वाली role के साथ invoices@ पर 'access': 'viewer' का मतलब है ऐसा व्यक्ति जो मेल भेज सकता है पर उस पते से नहीं भेज सकता। अपवाद वह role है जिसमें addresses:all हो, जो addresses में चाहे जो हो, हर पते तक पहुँचती है, क्योंकि उस array में सिर्फ़ सीधे दिए गए grant होते हैं, इसलिए उसे किसी की पूरी पहुँच समझने से पहले permissions जाँच लें।

हर method userId लेता है, ईमेल नहीं। add अकेला अपवाद है, क्योंकि वह एक पते को आमंत्रित करता है: व्यक्ति के पास userId तभी होती है जब वह स्वीकार कर ले, और तब तक list_invitations आमंत्रण पर नज़र रखता है।

'implied': True का अर्थ है कि role किसी ने चुनी ही नहीं। उनके पास पते हैं और कोई member पंक्ति नहीं, इसलिए role उनके सबसे चौड़े grant से अनुमानित की गई। इसे “अभी तय नहीं” मानें, और update ही वह है जो अनुमान को निर्णय में बदलता है। तब तक, उनकी पता-पहुँच चौड़ी करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।

वर्कस्पेस का मालिक पहली पंक्ति होता है, 'isOwner': True से चिह्नित, जबकि add, update और remove फिर भी उसे member_is_owner के साथ मना कर देते हैं। बिना साझा किया गया वर्कस्पेस शून्य नहीं बल्कि एक सदस्य बताता है, इसलिए सीटें गिनते समय isOwner को छोड़ दें।

remove दोनों अक्ष लेता है (role और इस वर्कस्पेस पर हर पता grant) और addressesRevoked बताता है। revoke_address संकरा वाला है, उस व्यक्ति के लिए जिसने टीम बदली, न कि उसके लिए जो चला गया।

पैरामीटर

emailstrआवश्यक: किसे आमंत्रित करना है, trim और lower-case करके। उनका अकाउंट होना अभी ज़रूरी नहीं: आमंत्रण सबको जाता है, और role तथा grant तब लगते हैं जब वे स्वीकार करते हैं। जो पहले से वर्कस्पेस में है, वह `member_is_owner` (422) है।
roleIdstrआवश्यक: वह role जो उनके पास होगी, 1 से 128 वर्ण, और वह इसी वर्कस्पेस की role होनी चाहिए: अनजान id `role_not_found` (404) है। owner role बाँटी नहीं जा सकती और `role_immutable` (409) लौटती है, क्योंकि किसी को owner बनाना वर्कस्पेस हस्तांतरण है और यहाँ उसके लिए कोई कॉल नहीं है।
addressIdslist[str]: वे पते जो आमंत्रण साथ ले जाता है, अधिकतम 64 id, हर एक 1 से 128 वर्ण की, जो आमंत्रण स्वीकार होने पर दिए जाते हैं। कुछ भी लिखे जाने से पहले हर id जाँची जाती है, इसलिए ऐसी id जो इस वर्कस्पेस का पता नहीं है, पूरी कॉल को 422 `member_not_found` के साथ अस्वीकार करवा देती है और कुछ नहीं भेजा जाता। उसी पते को दस मिनट के भीतर फिर से आमंत्रित करना 409 `invitation_too_soon` है।
accessLiteral['member', 'viewer']: `addressIds` की हर id के साथ वे क्या कर सकते हैं: `member` पता पढ़ता है और उससे भेजता है, `viewer` केवल पढ़ता है। डिफ़ॉल्ट `member` है, वही स्तर जो कंसोल और पुराना साझाकरण रास्ता हमेशा इस्तेमाल करते आए हैं, ताकि एक ही कॉल का अर्थ स्क्रिप्ट से और स्क्रीन से एक ही रहे; मिला-जुला grant चाहिए तो जो अलग हैं उनके लिए बाद में `grant_address` कॉल करें।

प्रतिक्रिया

objectLiteral['member']: हमेशा `member`। हटाने पर वही मान, उनका `userId`, `'deleted': True` और `addressesRevoked` लौटते हैं, और नीचे के बाकी फ़ील्ड कोई नहीं।
userIdstr: उनकी अकाउंट id, और वही handle जो बाकी हर member कॉल path में लेता है: get, update, remove और दोनों पता कॉल। किसी को जोड़ना अकेला ऐसा कॉल है जो इसके बजाय ईमेल से चलता है, क्योंकि जो सहकर्मी को जोड़ रहा है उसे उसका पता पता होता है, id नहीं।
emailstr: उनके अकाउंट पर मौजूद ईमेल, जैसा वह पंक्ति उसे रखती है। यह resource इसे कभी लिखता नहीं, और `add` पर होने वाली lower-casing उस पते पर लागू होती है जो आप खोज के लिए भेजते हैं, न कि उस पर जो लौटता है। मालिक के बाद, सदस्यों की सूची इसी से क्रमित होती है, न कि इससे कि लोग कब जुड़े, क्योंकि यह सूची यह देखने के लिए नहीं कि क्या बदला, बल्कि एक व्यक्ति ढूँढने के लिए पढ़ी जाती है।
namestr | None: उनका प्रदर्शित नाम, उनके अकाउंट से लिया गया, जहाँ वह column NOT NULL है। type में मौजूद `None` एहतियात है, न कि ऐसी स्थिति जो इस API में देखी गई हो। यह वर्कस्पेस का नहीं उनका अपना है, इसलिए इस resource पर कुछ भी इसे सेट नहीं कर सकता।
imagestr | None: उनका avatar, उनके अकाउंट से लिया गया, और जब उन्होंने कोई सेट नहीं किया तो null।
role.idstr | None: उनके पास जो role है उसकी id, या null जब किसी ने उसे चुना ही नहीं। देखें `implied`। यहाँ null वही एक स्थिति है जहाँ `role` किसी के लिए गए निर्णय के बजाय एक अनुमान बताता है।
role.namestr: role का नाम। implied सदस्य के लिए यह उस अंतर्निहित template का नाम है जिस पर उनकी पहुँच हल हुई, न कि इस वर्कस्पेस की कोई पंक्ति।
role.builtinLiteral['owner', 'admin', 'member', 'viewer', 'developer', 'billing'] | None: role कौन-सी अंतर्निहित है, या कस्टम के लिए null। `owner` केवल मालिक की अपनी पंक्ति पर आता है, `'isOwner': True` के साथ; वह role किसी को देना `role_immutable` (409) के साथ अस्वीकार होता है।
isOwnerbool: ठीक एक पंक्ति पर true: वह अकाउंट जिस पर वर्कस्पेस टिका है। उनकी role पंक्ति जो भी कहे, उनके पास हर अनुमति होती है, वे सबसे पहले क्रमित होते हैं, और `add`, `update` तथा `remove` तीनों उन्हें `member_is_owner` के साथ मना कर देते हैं। सीटें गिनते समय उन्हें छोड़ दें।
impliedbool: true तब, जब इस व्यक्ति के पास पता grant हैं और कोई member पंक्ति नहीं, यानी उनकी role चुनी नहीं बल्कि अनुमानित की गई: `member` का कोई भी grant अंतर्निहित Member पर हल होता है, अन्यथा Viewer। मालिक के लिए यह कभी true नहीं। इसे "पहुँच से अनुमानित" के रूप में दिखाएँ। जब तक कोई PATCH अनुमान को निर्णय में नहीं बदलता, उनकी पता-पहुँच चौड़ी करना चुपचाप यह भी चौड़ा कर देता है कि वे क्या कर सकते हैं।
permissionslist[Permission]: role की अनुमतियाँ सदस्य पर सपाट कर दी जाती हैं, ताकि एक ही read "क्या वे कर सकते हैं?" का उत्तर role लाए बिना दे दे। implied सदस्य के लिए ये इस वर्कस्पेस की role पंक्ति से नहीं बल्कि अंतर्निहित TEMPLATE से आती हैं, इसलिए अंतर्निहित Member role बदलने से implied सदस्य के पास जो है वह नहीं बदलता।
addresseslist[MemberAddressResource]: उन्हें दिए गए पते, पते के क्रम में, हर एक अपने पहुँच स्तर के साथ। जिसके पास role है और कोई grant नहीं, उसके लिए खाली। नया सदस्य पता मिलने तक ऐसा ही दिखता है, और जब तक आप तय कर रहे हैं कि उन्हें क्या दिखना चाहिए, यही सही विफलता है।
addresses[].addressIdstr: पते की id, और वही जो `grant_address` और `revoke_address` लेते हैं। ऐसी id जो इस वर्कस्पेस का पता नहीं है, दोनों पर अस्वीकार की जाती है, न कि ऐसा निरसन बताया जाता है जो हुआ ही नहीं।
addresses[].addressstr: पूरा पता, lower-case में, उसके local भाग और उसके डोमेन से दोबारा बनाया हुआ।
addresses[].accessLiteral['member', 'viewer']: इस एक पते के साथ वे क्या कर सकते हैं: `member` इसे पढ़ता है और इससे भेजता है, `viewer` केवल पढ़ता है। भेजने से पहले इसे और role दोनों को अनुमति देनी होती है, इसलिए `viewer` grant पर `emails:send` रखने वाली role किसी भी पते से नहीं भेजती; संग्रहीत column का नाम `role` है, और यहाँ उसका नाम बदला गया है ताकि एक object दो अलग शब्दावलियों से लिए गए दो `role` न ढोए।
createdAtstr | None: उनकी member पंक्ति कब लिखी गई, ISO-8601, और जब member पंक्ति है ही नहीं तो null। वह null उसी समूह का वर्णन करता है जिसका `'implied': True`: वे लोग जिनके पास role के अस्तित्व में आने से पहले के पते हैं और जिन्हें तब से किसी ने role नहीं दी।

आमंत्रण

invitations.py

from openemail import openemail waiting = openemail.members.list_all_invitations() for invitation in waiting:    if invitation['expired']:        openemail.members.resend_invitation(invitation['id']) openemail.members.revoke_invitation('winv_6bb640f5b99e47deb758f1f5')

add एक आमंत्रण के साथ जवाब देता है, और ये वे कॉल हैं जो उसके बाद आती हैं: list_invitations, list_all_invitations और iterate_invitations वे आमंत्रण पढ़ते हैं जिन्हें अभी किसी ने स्वीकार नहीं किया, resend_invitation किसी को नए लिंक और चौदह और दिनों के साथ फिर भेजता है, और revoke_invitation उसे वापस लेता है। प्रतीक्षा में पड़ा आमंत्रण स्वीकार होने तक कुछ नहीं देता।

resend_invitation एक ही पते को दस मिनट में दोबारा 409 invitation_too_soon के साथ मना करता है, और revoke_invitation पहले ही स्वीकार हो चुके आमंत्रण को 409 invitation_accepted के साथ मना करता है।

सत्यापन कोड

add, update, remove, grant_address और revoke_address कुछ भी बदलने से पहले OAuth एक्सेस टोकन से सत्यापन कोड माँगते हैं, और resend_invitation तथा revoke_invitation नहीं माँगते। कॉल एक OpenEmailApiError raise करती है जिसका is_step_up_required True होता है: security.begin_step_up() से कोड माँगें, व्यक्ति से मिला कोड security.verify_step_up({'code': ...}) से जाँचें, फिर कॉल दोबारा करें। एक सत्यापन 60 मिनट तक मान्य रहता है, और API कुंजी से कभी नहीं पूछा जाता।

कॉन्फ़िगरेशनएक्सेस टोकन, और उनसे माँगे जाने वाले सत्यापन कोड।

सदस्य

हर मेथड

पैरामीटर

प्रतिक्रिया

आमंत्रण

सत्यापन कोड

संदर्भ

आपका इनबॉक्स,
आपकी अपनी शर्तों पर।

सदस्य

हर मेथड

पैरामीटर

प्रतिक्रिया

आमंत्रण

सत्यापन कोड

संदर्भ

आपका इनबॉक्स,आपकी अपनी शर्तों पर।

आपका इनबॉक्स,
आपकी अपनी शर्तों पर।