नॉलेज बेस
Roles और अनुमति स्तर
role बताता है कि कोई क्या कर सकता है; address grant बताता है कि वह किस पर कर सकता है।
विवरण
- प्रति व्यक्ति दो grant, और कुछ भी होने से पहले दोनों का सहमत होना ज़रूरी है। ROLE, जो Settings → Members में तय होता है, बताता है कि वे workspace में क्या कर सकते हैं: मेल पढ़ना, भेजना, templates संपादित करना, domain जोड़ना, API key बनाना। address GRANT, जो address पंक्ति के Share नियंत्रण से तय होता है, बताता है कि वे यह किन ADDRESSES पर कर सकते हैं, केवल-पढ़ने या पढ़ने-और-भेजने के रूप में। जिसके role में भेजना है पर कोई address नहीं, वह किसी से नहीं भेज सकता; और जिसके पास workspace का हर address केवल-पढ़ने के grant पर है, वह भी किसी से नहीं भेज सकता।
- छह roles बिना किसी के बनाए मौजूद हैं, और हर workspace में वही छह हैं, इसलिए “Admin” का अर्थ यहाँ वही है जो दस्तावेज़ों में और API पर है। Owner, Admin, Member और Viewer एक सीढ़ी हैं: हर एक वह सब रखता है जो अगला रखता है, इसलिए किसी को नीचे करना उसकी पहुँच को किसी और हिस्से से बदलने के बजाय सँकरा करता है। Developer और Billing उस सीढ़ी के पायदान नहीं हैं। Developer एकीकरण बनाता है — API keys, webhooks, templates और भेजना उसके पास होता है जबकि वह workspace की कोई मेल नहीं पढ़ता — और Billing प्लान तथा invoices देखता है, उन पर प्लान और भुगतान विवरण बदल सकता है, और mailbox settings पढ़ता है पर लिख नहीं सकता। इनकी अनुमतियाँ संपादन-योग्य हैं: जो workspace चाहता हो कि उसके members templates न लिखें, वह उसका टिक हटा देता है, और बदलाव उस अगले अनुरोध पर लागू होता है जो वह role स्पष्ट रूप से रखने वाला कोई भी करता है। जिसका role अब भी roles से पहले बने किसी address grant से निहित है, वह तब तक भेजे गए डिफ़ॉल्ट रखता है जब तक उसे सीधे कोई role न दिया जाए। इनके नाम भी वैसे ही हैं: जो workspace Ops और On-call पर चलता है, वह इनके नाम बदलकर अपना ही वर्णन करता है, और यही इसका मक़सद है।
- Owner हर दिशा में अपवाद है: न संपादन-योग्य, न हटाने-योग्य, न सौंपने-योग्य। यह उस खाते का वर्णन करता है जिस पर workspace टिका है और इसमें हर अनुमति होती है, उन सहित जो बाद के किसी रिलीज़ में जुड़ें, इसीलिए इसकी सूची संग्रहित नहीं बल्कि गणना की हुई होती है। workspace किसी और को सौंपना role बदलना नहीं, हस्तांतरण है, और यहाँ ऐसा करने वाला कुछ नहीं है।
- इनके आगे, workspace उसी समूहबद्ध मैट्रिक्स में से अनुमतियाँ टिक करके अपने role लिखता है, कुल 24 तक। टिक करने से निहित भी होता है: “edit templates” अपने साथ “read templates” भी संग्रहित करता है, क्योंकि ऐसा role जो उस template को संपादित कर सके जिसे वह खोल नहीं सकता, किसी की भूली हुई checkbox है, न कि किसी की सोची हुई नीति। जिस role को लोग या API keys रखते हों, उसे हटाते समय पूछा जाता है कि उन्हें कहाँ ले जाएँ, और अनुमान लगाने के बजाय इनकार कर दिया जाता है। जिस key का role ग़ायब हो जाए, वह किसी भी सीमा के बिना रह जाती, जो अभी-अभी गए role से भी चौड़ा है।
- API key किसी role के विरुद्ध जारी की जा सकती है, और role दूसरा grant नहीं बल्कि एक छत है: key क्या कर सकती है, यह उसके अपने scopes और role की अनुमतियों का प्रतिच्छेद है, जो हर अनुरोध पर हल होता है। भेजने के साथ बनी और Viewer से सीमित key भेज नहीं सकती, और role को सँकरा करने से वह जीवित रूप से रद्द हो जाती है, बिना key बदले। assistant भी उसी सूची से बँधा है, और MCP server किसी client के tools कॉल करने वाले की अनुमतियों से बनाता है, इसलिए viewer के client में भेजने का tool होता ही नहीं, और हर सीमित tool भीतर आते समय दोबारा जाँच करता है क्योंकि सूची बनने के बाद कोई session mailbox बदल सकता है।