उपयोगकर्ता, टीमें और भूमिकाएँ

Bird में लोगों की पहुँच भूमिका पर आधारित है: हर उपयोगकर्ता के पास आपके वर्कस्पेस पर एक भूमिका होती है, और हर भूमिका अनुमतियों का एक तय समूह है। इसके अलावा कुछ भी कॉन्फ़िगर करने की ज़रूरत नहीं है; सही भूमिका चुनें और अनुमतियाँ उसके साथ मिल जाती हैं।

भूमिकाएँ तय करती हैं कि डैशबोर्ड में लोग क्या कर सकते हैं। सेवाएँ क्या कर सकती हैं, यह API कुंजी के स्कोप तय करते हैं: अनुमतियों की शब्दावली वही है, पर ये भूमिका के बजाय हर कुंजी को अलग से दी जाती हैं।

वर्कस्पेस भूमिकाएँ

रोज़ के काम में आप जिन भूमिकाओं का उपयोग करते हैं, वे वर्कस्पेस पर होती हैं (वर्कस्पेस देखें): admin, developer और analyst। इन्हें डैशबोर्ड में Settings > Team में प्रबंधित करें।

हर अनुमति एक {scope, level} जोड़ी है, जिसमें level या तो read है या write (write में read शामिल है)। भूमिका इन जोड़ियों का एक नामित, तय समूह है:

व्यवहार में, एडमिन वर्कस्पेस चलाता है, जिसमें टीम और सेटिंग्स भी शामिल हैं। डेवलपर इंटीग्रेशन बना सकता है, डोमेन और वेबहुक प्रबंधित कर सकता है, और API कुंजियाँ बना सकता है। एनालिस्ट के पास केवल पढ़ने की पहुँच होती है।

दो पंक्तियों को ध्यान से देखना ज़रूरी है। ip_pools एडमिन के लिए भी केवल पढ़ने योग्य है, क्योंकि समर्पित IP खरीदने और पूल प्रबंधित करने के लिए संगठन-स्तर का org:ip_pools:write स्कोप चाहिए। WhatsApp अनुमतियाँ भी प्रबंधन को संदेश भेजने से अलग रखती हैं। डेवलपर whatsapp_management:write से टेम्पलेट और सेटिंग्स प्रबंधित कर सकता है, लेकिन whatsapp:read से संदेश केवल पढ़ सकता है; संदेश भेजने का अधिकार केवल एडमिन के पास रहता है। अन्य उत्पाद इसी {scope, level} मॉडल से स्कोप जोड़ते हैं।

किसी भी एंडपॉइंट से 403 मिलने का अर्थ है कि प्रमाणित प्रिंसिपल के पास वह {scope, level} नहीं है जो उस एंडपॉइंट को चाहिए। समाधान है भूमिका बदलना (व्यक्ति के लिए) या सही स्कोप वाली नई कुंजी बनाना (सेवा के लिए)।

संगठन भूमिकाएँ

आपके वर्कस्पेस के पीछे एक संगठन होता है, जिसके पास बिलिंग और पूरी सदस्य सूची होती है। इस स्तर को दो भूमिकाएँ प्रबंधित करती हैं:

• owner: सब कुछ। संगठन और वर्कस्पेस के सभी कार्यों पर पूरी पढ़ने और लिखने की पहुँच। एक संगठन में कई मालिक हो सकते हैं, और होने चाहिए। खाता बनाने वाला व्यक्ति शुरुआत में मालिक होता है।
• billing_admin: बिलिंग और संगठन सेटिंग्स (org:billing:write, org:settings:write), साथ ही संगठन की सदस्य सूची और वर्कस्पेस मेटाडेटा पढ़ने की पहुँच। वर्कस्पेस के भीतर के संसाधनों तक कोई पहुँच नहीं।

रोज़ के काम में इनकी ज़रूरत कम ही पड़ती है: ज़्यादातर साथियों को केवल वर्कस्पेस भूमिका चाहिए।

सदस्य और टीम

सदस्यता अपने-आप तय होती है: यदि किसी उपयोगकर्ता के पास संगठन भूमिका या वर्कस्पेस भूमिका है, तो वह आपके संगठन का "in" है। प्रबंधित करने के लिए कोई अलग सदस्यता रिकॉर्ड नहीं होता।

आप अपने वर्कस्पेस के लोगों को डैशबोर्ड में Settings > Team में प्रबंधित करते हैं, जिसके लिए वर्कस्पेस का members स्कोप चाहिए; वर्कस्पेस एडमिन किसी संगठन-स्तर की भूमिका के बिना यहाँ टीम प्रबंधित करता है। टीम प्रबंधन लोग करते हैं, इसलिए API कुंजियों को members स्कोप नहीं दिया जा सकता (देखें प्रमाणीकरण)।

किसी की वर्कस्पेस पहुँच हटाने से वह भूमिका हटती है, लेकिन उनकी कोई संगठन भूमिका नहीं बदलती। किसी को संगठन से हटाने पर उनके खाते की पूरी पहुँच रद्द हो जाती है। उनकी बनाई API कुंजियाँ काम करती रहती हैं, क्योंकि हर कुंजी अपने निर्माता से स्वतंत्र रूप से वर्कस्पेस की होती है।

आमंत्रण

Settings > Team से किसी ईमेल पते को एक भूमिका के साथ आमंत्रित करें, और बाकी काम Bird खुद संभालता है। इस बटन के पीछे एक स्मार्ट आमंत्रण है: एक ही प्रक्रिया उन सहकर्मियों को भी संभालती है जो पहले से आपके संगठन में हैं, और उन लोगों को भी जिन्होंने Bird के बारे में कभी नहीं सुना।

• पहले से संगठन के सदस्य: उन्हें दी गई भूमिका के साथ तुरंत वर्कस्पेस में जोड़ दिया जाता है। न कोई ईमेल, न कोई इंतज़ार; प्रतिक्रिया एक सदस्य ऑब्जेक्ट होती है।
• अभी सदस्य नहीं: Bird एक आमंत्रण बनाता है, उन्हें साइनअप लिंक ईमेल करता है, और प्रतिक्रिया pending स्थिति वाला एक आमंत्रण ऑब्जेक्ट होती है। लिंक 7 दिन तक मान्य रहता है; उसके बाद आमंत्रण की अवधि समाप्त हो जाती है और आपको उन्हें फिर से आमंत्रित करना होता है।

प्रतिक्रिया का type फ़ील्ड (team_member या invitation) बताता है कि इनमें से क्या हुआ। उसी ईमेल के लिए दूसरा लंबित आमंत्रण भेजने पर डुप्लिकेट नहीं बनता, बल्कि 409 लौटता है। आप किसी भी लंबित आमंत्रण को कभी भी उसी पेज से वापस ले सकते हैं।

एक owner किसी दूसरे owner या billing_admin को आमंत्रित कर सकता है। इस आमंत्रण के लिए org:members:write ज़रूरी है, जो केवल owners के पास होता है।

सुरक्षा नियम

हर भूमिका परिवर्तन पर दो अपरिवर्तनीय नियम लागू होते हैं, चाहे अनुरोध कोई भी करे:

• अंतिम owner को हटाया नहीं जा सकता। किसी संगठन के एकमात्र owner की भूमिका घटाने या उसे हटाने पर 409 लौटता है, ताकि कोई संगठन कभी बिना owner के न रहे। पहले किसी दूसरे व्यक्ति को owner बनाएँ।
• आप अपनी पहुँच खुद नहीं बदल सकते। अपनी भूमिका बदलने या खुद को हटाने पर 403 लौटता है। इससे गलती से खुद को बाहर कर देना और चुपचाप अपनी भूमिका बढ़ा लेना, दोनों रुकते हैं; यह बदलाव किसी दूसरे admin या owner को करना होता है।

संदर्भ कैसे चुना जाता है

सदस्य और टीम एंडपॉइंट दो स्तरों पर मौजूद हैं। कोई अनुरोध किस संगठन या वर्कस्पेस पर लागू होता है, यह इस पर निर्भर करता है कि वह कैसे प्रमाणित होता है:

• सत्र प्रमाणीकरण (डैशबोर्ड, या आपकी ओर से काम करने वाले टूल) हर अनुरोध के साथ संदर्भ देता है: संगठन-स्तर के एंडपॉइंट पर X-Organization-Id, और वर्कस्पेस-स्तर के एंडपॉइंट पर X-Workspace-Id।
• API कुंजियाँ अपना संदर्भ अपने आप साथ रखती हैं। कुंजी आपके वर्कस्पेस की होती है, और इसी से संगठन भी तय हो जाता है। किसी हेडर की ज़रूरत नहीं होती, और कुंजी से मेल न खाने वाला संदर्भ हेडर गलत बनावट वाला मानकर अस्वीकार कर दिया जाता है (400)।

संदर्भ तय होने का पूरा मॉडल वर्कस्पेस पर देखें।

अगले कदम

• प्रमाणीकरण और API कुंजियाँ: सेवाओं के लिए स्कोप, और कुंजियाँ कौन प्रबंधित कर सकता है
• वर्कस्पेस: वह वर्कस्पेस जिससे ये भूमिकाएँ जुड़ी होती हैं
• बिलिंग और उपयोग: संगठन-स्तर की बिलिंग भूमिकाएँ क्या प्रबंधित करती हैं