अनुमतियाँ सूचीबद्ध करें
पूरी शब्दावली, हर प्रविष्टि के वाक्य और उस शीर्षक के साथ जिसके नीचे वह रेंडर होती है।
असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।
GET /roles/permissions
पूरी शब्दावली, हर प्रविष्टि के वाक्य और उस शीर्षक के साथ जिसके नीचे वह रेंडर होती है।
उदाहरण
roles:read चाहिए। एक स्थिरांक, हर वर्कस्पेस के लिए वही जवाब, और मैट्रिक्स इसी सूची से बनाएँ — इसे अपने कोड में उतारने के बजाय।
curl "$OE/roles/permissions" -H "$AUTH"{ "object": "list", "data": [ { "object": "permission", "id": "emails:send", "label": "Send email", "group": "mail", "scope": true }, { "object": "permission", "id": "members:write", "label": "Add and remove people, and change what they can reach", "group": "people", "scope": true }, { "object": "permission", "id": "api-keys:write", "label": "Create and revoke API keys", "group": "developer", "scope": false }, { "object": "permission", "id": "workspace:manage", "label": "Rename the workspace, remove domains and delete it", "group": "workspace", "scope": false } ]}इसे /roles/{id} से पहले पंजीकृत किया जाता है, वरना permissions को role id की तरह पढ़ा जाता है और उस पर हर अनुरोध 404 देता है। /rules/runs के ऊपर भी यही टिप्पणी है और उससे ऊपर /tracking/stats पर भी, दोनों उसी बग के बाद लिखी गईं। इसलिए सचमुच “permissions” नाम की भूमिका माँगने पर भूमिका ही माँगी जाती है और 404 मिलता है, जो टाइप की गई चीज़ का ईमानदार जवाब है।
scope बताता है कि API कुंजी वह अनुमति रख भी सकती है या नहीं। पाँच नहीं रख सकतीं (api-keys:read, api-keys:write, billing:read, billing:write और workspace:manage) क्योंकि इनमें से किसी के लिए कोई एंडपॉइंट नहीं है और कुंजी कोई व्यक्ति नहीं है। यही फ़्लैग एक ही कंपोनेंट को भूमिका-मैट्रिक्स और कुंजी-निर्माण की चेकबॉक्स सूची दोनों रेंडर करने देता है, बजाय इसके कि कौन-सा कौन है इसकी दूसरी हाथ से बनी प्रति रखी जाए।
उतारे जाने के बजाय परोसा जाता है, उसी कारण से जो नियम-फ़ील्ड सूची देती है: कॉपी किए गए array से बनी मैट्रिक्स किसी अनुमति का नाम बदलने के दिन भी पुरानी अनुमति दिखाती रहती है और पिछले हफ़्ते जुड़ी अनुमति कभी नहीं दिखाती। group वह शीर्षक है जिसके नीचे वह रेंडर होती है और undefined जाने के बजाय other पर लौट आता है। जो अनुमति किसी को दिखती नहीं, उसका ऑडिट भी कोई नहीं करता।
क्रम विहित है: यही वह क्रम है जिसमें संग्रहित भूमिका का permissions array लौटता है, इसलिए यह सूची रेंडर करने वाला क्लाइंट और भूमिका रेंडर करने वाला क्लाइंट वही अनुमतियाँ उसी क्रम में दिखाते हैं।
object और data के अलावा कोई लिफ़ाफ़ा नहीं। शब्दावली बंद और छोटी है, इसलिए यहाँ कोई कर्सर और कोई hasMore नहीं, बाकी हर सूची के विपरीत।