मुख्य कंटेंट पर जाएँ

अनुमतियाँ

अधिकांश अनुमतियाँ entity:action:scope ट्रिपल का उपयोग करती हैं। कार्रवाइयों में list, read, edit और delete शामिल हैं। दायरे आम तौर पर ग्राहकों या टूर जैसी बड़ी इकाइयों के लिए all और assigned एक्सेस के बीच अंतर करते हैं।

मॉड्यूलर संगठनों के लिए, इन भूमिका अनुमतियों के अतिरिक्त आवश्यक सब्सक्रिप्शन मॉड्यूल भी जाँचे जाते हैं। कोई भूमिका किसी कार्रवाई की अनुमति दे सकती है, जबकि संबंधित मॉड्यूल उपलब्ध न हो; इसी तरह, सक्रिय मॉड्यूल किसी अनुपलब्ध भूमिका क्षमता की अनुमति नहीं देता। Subscription देखें।

संगठन प्रशासन भी admin इकाई के माध्यम से व्यक्त किया जाता है: चाइल्ड संगठनों, भूमिकाओं और इसी तरह के पदानुक्रम टूल को प्रबंधित करने वाली भूमिकाओं में admin अनुमतियाँ शामिल होती हैं, जैसे admin:list:all, admin:read:all और संबंधित admin:* संयोजन। “संगठन प्रशासक” के लिए सर्वर-साइड जाँच कुछ रूट्स पर admin: से शुरू होने वाली किसी भी अनुमति स्ट्रिंग को पर्याप्त मान सकती है—किसी वर्कस्पेस के लिए हमेशा डैशबोर्ड रोल एडिटर को सत्य का स्रोत मानें।

list सपोर्ट वाली प्राथमिक इकाइयों में customer, tour, landing-page, event, offer, newsletter, project, document, contactform, siteplan, place और admin शामिल हैं। protocol, email और task जैसी उप-इकाइयाँ जानबूझकर list को शामिल नहीं करतीं, क्योंकि दृश्यता संबंधों के माध्यम से निर्धारित होती है।

मिश्रित असाइनमेंट या प्लेटफ़ॉर्म-ऑपरेटर शॉर्टकट जैसे विशेष मामलों का समाधान उत्पाद के भीतर किया जाता है; किसी वर्कस्पेस के लिए डैशबोर्ड रोल एडिटर को सत्य का स्रोत मानें।

अनुमति प्रारूप​

entity:action:scope
भागअर्थउदाहरण
entityनियंत्रित किए जा रहे संसाधन का प्रकार।customer, tour, event, admin
actionवह कार्रवाई जो भूमिका कर सकती है।list, read, edit, delete
scopeएक्सेस का दायरा।assigned, all, off

कार्रवाइयाँ​

कार्रवाईअर्थ
listलिस्ट व्यू में उन इकाइयों के रिकॉर्ड देखें जो सूचीकरण का समर्थन करती हैं।
readरिकॉर्ड का विवरण खोलें या जाँचें।
editरिकॉर्ड बनाएँ या अपडेट करें।
deleteजहाँ अनुमति हो, रिकॉर्ड हटाएँ।

edit में अनुमति मॉडल के भीतर बनाने के अधिकार भी शामिल होते हैं, इसलिए बनाने वाले बटन अक्सर अलग बनाने की अनुमति के बजाय संपादन अनुमति पर निर्भर करते हैं।

दायरे​

दायराअर्थ
assignedअसाइनमेंट या संबंध नियमों के माध्यम से उपयोगकर्ता से जुड़े रिकॉर्ड का एक्सेस।
allसंगठन के भीतर उस इकाई के सभी रिकॉर्ड का एक्सेस।
offकोई स्पष्ट एक्सेस नहीं, सिवाय उत्पाद द्वारा लागू विशेष स्वयं-एक्सेस या संबंध नियमों के।

केवल-असाइन किए गए रिकॉर्ड का व्यवहार इकाई के अनुसार अलग हो सकता है। उदाहरण के लिए, ग्राहकों के लिए जिम्मेदार उपयोगकर्ता हो सकते हैं, जबकि कार्य, ईमेल और प्रोटोकॉल ग्राहक असाइनमेंट या सीधे असाइनमेंट के माध्यम से दिखाई दे सकते हैं।

इकाई समूह​

प्राथमिक इकाइयाँ सूची-शैली के एक्सेस का समर्थन करती हैं:

  • customer
  • tour
  • landing-page
  • event
  • offer
  • newsletter
  • project
  • document
  • contactform
  • siteplan
  • place
  • admin

उप-इकाइयाँ जानबूझकर list का उपयोग नहीं करतीं:

  • protocol
  • email
  • task

इन उप-इकाइयों तक आम तौर पर ग्राहकों, प्रोजेक्ट्स या सीधे असाइनमेंट से जुड़े संबंधों के माध्यम से पहुँचा जाता है।

डैशबोर्ड दृश्यता​

साइडबार यह तय करने के लिए अनुमतियों का उपयोग करता है कि कौन-से समूह और रूट दिखाई दें। यदि कोई उपयोगकर्ता कोई पेज नहीं देख सकता, तो पहले इकाई की अनुमति जाँचें:

  • ग्राहक प्रबंधन: customer, protocol, task, project, document, newsletter, email, event।
  • वेब ऐप्स और टूर: landing-page, tour, offer, contactform, siteplan (साइट प्लान और प्रश्न सामान्य कॉन्फ़िगरेशन में लैंडिंग-पेज दृश्यता के आधार पर नियंत्रित होते हैं)।
  • सेटिंग्स पदानुक्रम: admin इकाई अनुमतियाँ (चाइल्ड संगठन और भूमिकाएँ)।
  • इवेंट सेटिंग्स: event।

वेब ऐप्स और टूर के अंतर्गत Gallery कुछ आसपास के आइटम की तुलना में अधिक व्यापक रूप से दिखाई देता है; सटीक नियम डिप्लॉयमेंट के अनुसार अलग हो सकते हैं—यदि कोई लिंक दिखाई न दे, तो बिल्ड खराब मानने के बजाय लैंडिंग-पेज, टूर और संगठन संदर्भ की पुष्टि करें।

प्लेटफ़ॉर्म ऑपरेटरों को ऐसे अतिरिक्त रूट दिखाई दे सकते हैं जिनका टेनेंट उपयोगकर्ताओं को कभी सामना नहीं होता।

संबंधित अवधारणाएँ: अनुमतियाँ और संगठन, चाइल्ड संगठन और भूमिकाएँ।