ServiceUserRole

ServiceUserRole उस end-user को दी जाने वाली अनुमतियों का समूह है जो उत्पाद में साइन अप करता है, यानी ServiceUser को। यह एक ही संसाधन में रखता है कि Content Type, Content और Media पर क्या किया जा सकता है (पढ़ना, बनाना, संपादित करना, हटाना), Script को निष्पादित किया जा सकता है या नहीं, और साथ ही ऐसे फ़िल्टर भी जो दायरे को सीमित करते हैं, जैसे केवल कुछ Content Type तक या केवल अपने बनाए हुए तक। उपयोग की जा सकने वाली क्रियाएँ हर मानचित्र में अलग-अलग होती हैं (नीचे अनुमति मानचित्र की तालिका देखें)। यह अनुमति उस ACMA/ACDA पर लागू होती है जिसे ServiceUser कॉल करता है।

इसका स्थान SpaceRole से अलग है। SpaceRole, Weegloo User (कंटेंट स्टूडियो उपयोगकर्ता) की अनुमतियों का समूह है और CMA/CDA पर लागू होता है, जबकि ServiceUserRole, उत्पाद में साइन अप करने वाले ServiceUser की अनुमतियों का समूह है और ACMA/ACDA पर लागू होता है। बनाया गया ServiceUserRole अपने आप में किसी पर लागू नहीं होता। इसे ServiceLogin की डिफ़ॉल्ट भूमिका (defaultRole) में निर्दिष्ट करके, या ServiceUser के roleOverride में बाँधकर दिया जाता है।

संसाधन संरचना

नीचे ServiceUserRole "खरीदार" की एकल-अनुरोध प्रतिक्रिया है। sys (सिस्टम गुण) के साथ-साथ, यह अनुमति तय करने वाले मुख्य गुण contentType, content, media और script रखता है।

{
  "sys": {
    "id": "3trmXRLXeZN2RTHvVj3hFDN5546vbp",
    "type": "ServiceUserRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T12:40:36.944Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T12:40:36.944Z",
    "version": 1
  },
  "name": "खरीदार",
  "description": "ऐसा सदस्य जो प्रकाशित उत्पाद पढ़ सकता है",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "script": {}
}

मुख्य कुंजियाँ:

contentType: Content Type स्वयं (स्कीमा) पर अनुमति मानचित्र है। ServiceUser इस स्कीमा को केवल पढ़ता है, इसलिए इसमें केवल Read तय किया जाता है।
content: Content (कंटेंट डेटा) पर अनुमति मानचित्र है। ऊपर का उदाहरण केवल किसी विशिष्ट Content Type के Content को पढ़ने तक सीमित किया हुआ रूप दिखाता है।
media: Media (फ़ाइल, छवि) पर अनुमति मानचित्र है।
script: Script (घोषणात्मक बैकएंड एंडपॉइंट) पर अनुमति मानचित्र है। ServiceUser, Script को केवल निष्पादित (Execute) करता है।

SpaceRole के विपरीत, ServiceUserRole में Space सेटिंग्स तक पहुँच रखने वाला settings नहीं होता। इसका कारण यह है कि ServiceUser, Space सेटिंग्स को नहीं संभालता। साथ ही, यह दर्शाने वाला sys.isLocked भी नहीं होता कि यह डिफ़ॉल्ट रूप से प्रदान किया गया है या नहीं।

सिस्टम गुण (sys)

हर ServiceUserRole समान सिस्टम गुणों को sys ऑब्जेक्ट में रखता है। space, createdBy, updatedBy, Refer रूप ({ "sys": { "id", "type": "Refer", "targetType" } }) में आते हैं।

गुण	प्रकार	विवरण
`id`	string	संसाधन का अद्वितीय पहचानकर्ता।
`type`	string	संसाधन का प्रकार। ServiceUserRole के लिए हमेशा `"ServiceUserRole"`।
`space`	Refer<Space>	वह Space जिसमें यह ServiceUserRole है।
`createdBy`	Refer<User>	बनाने वाला उपयोगकर्ता।
`createdAt`	string (date-time)	बनाए जाने का समय।
`updatedBy`	Refer<User>	अंतिम बार संशोधित करने वाला उपयोगकर्ता।
`updatedAt`	string (date-time)	अंतिम संशोधन का समय।
`version`	integer (≥1)	संसाधन का संस्करण। हर संशोधन पर 1 बढ़ता है।

ServiceUserRole एक सेटिंग संसाधन है जिसमें प्रकाशन की कोई अवधारणा नहीं होती। इसलिए Content और Media के विपरीत, इसके sys में publish, archive, status नहीं होते, केवल version होता है। version, ServiceUserRole के हर संशोधन पर बढ़ता है। SpaceRole के विपरीत, sys.isLocked भी नहीं होता।

अनुमति मानचित्र: contentType, content, media

contentType, content, media, script में से प्रत्येक एक ऐसा मानचित्र है जिसकी कुंजियाँ क्रियाएँ होती हैं। हर क्रिया का मान एक ऐसा ऑब्जेक्ट है जो Allow (अनुमति) और Deny (अस्वीकृति) नियमों की सरणी रखता है। मानचित्र की संरचना SpaceRole जैसी ही है, पर उपयोग की जा सकने वाली क्रियाएँ हर मानचित्र में अलग-अलग हैं और SpaceRole की तुलना में सीमित हैं।

अनुमति मानचित्र	उपयोग की जा सकने वाली क्रियाएँ
`contentType`	`All` · `Read`
`content`	`All` · `Create` · `Read` · `Edit` · `Delete`
`media`	`All` · `Create` · `Read` · `Delete`
`script`	`All` · `Execute`

All उस मानचित्र में उपयोग की जा सकने वाली सभी क्रियाओं को एक साथ दर्शाता है। तालिका में न दी गई किसी क्रिया को कुंजी के रूप में डालने पर भूमिका सहेजना अस्वीकृत हो जाता है। प्रकाशन से जुड़ी क्रियाएँ (Publish, Unpublish, Archive, Unarchive) किसी भी मानचित्र में नहीं हैं, क्योंकि सदस्य के बनाए हुए Content और Media बनते ही तुरंत प्रकाशित हो जाते हैं (ACMA देखें)।

Save नाम की कोई क्रिया नहीं है। संशोधन की अनुमति Edit है, और Save उस घटना का नाम है जिसकी सदस्यता Webhook लेता है।

"content": {
  "Read":   { "Allow": [ /* नियम */ ], "Deny": [ /* नियम */ ] },
  "Edit":   { "Allow": [ /* नियम */ ] }
}

प्रत्येक नियम (rule) ऑब्जेक्ट में अनुमति के दायरे को सीमित करने वाले वैकल्पिक फ़िल्टर होते हैं।

self: उस नियम के लागू होने के लक्ष्य को संसाधन स्वयं तक सीमित करता है। contentType मानचित्र में इसका अर्थ किसी एक विशिष्ट Content Type से है, और script मानचित्र में किसी एक विशिष्ट Script से।
contentType: उसे उस Content Type तक सीमित करता है जिससे वह Content संबंधित है। Content Type की ओर इंगित करने वाला Refer डाला जाता है।
createdBy: केवल किसी विशिष्ट उपयोगकर्ता द्वारा बनाए गए संसाधनों तक सीमित करता है। sys.id में कोई विशिष्ट id डालने पर केवल उसी व्यक्ति के बनाए हुए तक, और आरक्षित मान :self डालने पर "अभी कॉल करने वाले ServiceUser के बनाए हुए तक" सीमित हो जाता है।
tag: केवल किसी विशिष्ट Tag वाले संसाधनों तक सीमित करता है।

कौन-सा फ़िल्टर किस अनुमति मानचित्र में मान्य है, यह SpaceRole जैसा ही है (contentType मानचित्र में लक्ष्य self से और content मानचित्र में contentType से निर्दिष्ट किया जाता है), और मेल न खाने वाला फ़िल्टर डालने पर भूमिका सहेजना अस्वीकृत हो जाता है। मानचित्र-वार तालिका SpaceRole की अनुमति मानचित्र में दी गई है।

ACDA में createdBy फ़िल्टर (:self सहित) लगाते समय लक्ष्य Content Type का publishWithAuthor true होना चाहिए। ACDA इस फ़िल्टर को प्रकाशन snapshot के sys.createdBy से जाँचता है, और यदि publishWithAuthor अपने डिफ़ॉल्ट मान false पर है तो snapshot में लेखक नहीं होता, इसलिए Allow नियम किसी से मेल नहीं खाता (सदस्य को अपने संसाधन खाली परिणाम के रूप में मिलते हैं) और Deny नियम किसी को नहीं छानता। दूसरी ओर, ACMA (प्रबंधन) इसे draft के sys.createdBy से जाँचता है, इसलिए यह इस सेटिंग से स्वतंत्र है, और एक ही नियम ACMA में काम करते हुए भी ACDA में गड़बड़ा सकता है। publishWithAuthor को सदस्य द्वारा सामग्री डालने से पहले चालू करना होता है और यह पूर्वप्रभावी नहीं होता। Content Type के publishWithAuthor का विवरण देखें।

खाली Allow सरणी [] का अर्थ है उस पूरी श्रेणी पर क्रिया की अनुमति देना। चूँकि फ़िल्टर खाली है, छानने के लिए कुछ नहीं रहता, इसलिए सभी संसाधनों पर वह क्रिया खुल जाती है।

SpaceRole के विपरीत, ServiceUserRole में settings नहीं होता। अनुमति मानचित्र चार हैं: contentType, content, media, script। फ़िल्टर कुंजियों और :self के अर्थ सहित अनुमति मानचित्र लिखने की विधि के लिए समान संरचना वाले SpaceRole का विवरण भी साथ में देखें। परंतु उपयोग की जा सकने वाली क्रियाएँ ऊपर दी गई तालिका के अनुसार हैं और SpaceRole से भिन्न हैं। :self का उपयोग करके केवल अपने बनाए हुए Content को संपादित करने तक सीमित करने का उदाहरण ठीक नीचे सामान्य सदस्य भूमिका और व्यवस्थापक भूमिका में दिखाया गया है।

फ़िल्टर कुंजियाँ (self, contentType, createdBy, tag) और :self के अर्थ SpaceRole की अनुमति-नियम परिभाषा पर आधारित हैं। ServiceUserRole का :self केवल वर्तमान ServiceUser के बनाए हुए तक हल होता है। क्रियाओं की सूची SpaceRole का अनुसरण नहीं करती, बल्कि ऊपर दी गई तालिका का अनुसरण करती है।

सामान्य सदस्य भूमिका और व्यवस्थापक भूमिका

कोई सदस्य अन्य सदस्यों के संसाधनों तक संभाल सकता है या नहीं, यह नियम के createdBy फ़िल्टर से तय होता है। एक ही क्रिया में भी, createdBy में :self डालने पर वह क्रिया केवल कॉल करने वाले सदस्य के बनाए हुए को लक्ष्य बनाती है, और createdBy न डालने पर अन्य सदस्यों के बनाए हुए भी लक्ष्य बन जाते हैं।

सामान्य सदस्य को दी जाने वाली भूमिका में Edit और Delete को :self तक सीमित किया जाता है।

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  }
}

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

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
    ]
  }
}

इस तरह बनाई गई भूमिका को ServiceUser के roleOverride में निर्दिष्ट करके केवल उस एक सदस्य पर लागू किया जाता है। ServiceLogin के defaultRole को सामान्य सदस्य वाली भूमिका पर रखने पर, नए साइन अप करने वाले सदस्यों को व्यवस्थापक वाली भूमिका नहीं मिलती।

Media के लिए भी तरीका यही है। media मानचित्र की क्रिया से createdBy हटाने पर अन्य सदस्यों द्वारा अपलोड की गई फ़ाइलें भी लक्ष्य बन जाती हैं। परंतु contentType फ़िल्टर केवल content मानचित्र में उपयोग होता है, इसलिए इसे media मानचित्र में नहीं डाला जाता।

script (Script अनुमतियाँ)

script, Script पर अनुमति मानचित्र है, और इसकी संरचना content तथा media जैसी ही है। परंतु ServiceUser, Script के साथ जो एकमात्र काम कर सकता है वह है उसे निष्पादित करना (रचना, यानी बनाना/संपादित करना/हटाना, केवल CMA के Weegloo User के लिए है)। इसलिए ServiceUserRole के script में उपयोग की जा सकने वाली क्रियाएँ केवल All और Execute, ये दो हैं।

किसी साइन-अप सदस्य को Script निष्पादित करने की अनुमति देने के लिए इस तरह लिखें:

"script": {
  "Execute": { "Allow": [] }
}

नियम फ़िल्टर के रूप में self (किसी एक विशिष्ट Script) और createdBy, ये दो उपयोग किए जा सकते हैं। contentType और tag ऐसे अक्ष हैं जो Script से नहीं जुड़ते, इसलिए इन्हें डालने पर भूमिका सहेजना अस्वीकृत हो जाता है। किसी सदस्य को केवल एक विशिष्ट Script निष्पादित करने की अनुमति देनी हो, तो Execute के Allow में उस Script की ओर इंगित करने वाला self नियम रखें।

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

Script की अपनी संरचना तथा उसका निष्पादन एंडपॉइंट Script संसाधन और एंडपॉइंट में, और क्रियाओं की पूरी सूची SpaceRole की script अनुमति में दी गई है।

त्रुटियाँ

ये कोड ServiceUserRole के साथ काम करते समय मिलते हैं। सभी संसाधनों में समान रूप से मिलने वाले कोड के लिए सामान्य त्रुटियाँ देखें।

कोड शर्त

WGL400020 अनुमति मानचित्र में ऐसा फ़िल्टर डाला गया जो उस मानचित्र में उपयोग नहीं किया जा सकता, इसलिए ServiceUserRole सहेजना अस्वीकृत हो गया। script मानचित्र में contentType और tag डालने का मामला इसी में आता है।

कोड	शर्त
`WGL400020`	अनुमति मानचित्र में ऐसा फ़िल्टर डाला गया जो उस मानचित्र में उपयोग नहीं किया जा सकता, इसलिए ServiceUserRole सहेजना अस्वीकृत हो गया। `script` मानचित्र में `contentType` और `tag` डालने का मामला इसी में आता है।

API

नीचे के सभी एंडपॉइंट का आधार URL https://cma.weegloo.com/v1 है, और Authorization हेडर में CMA को प्रमाणित करने वाला Bearer टोकन आवश्यक है। भूमिका संशोधन (PUT, PATCH) के लिए ऑप्टिमिस्टिक समवर्तीता नियंत्रण हेतु X-Weegloo-Version हेडर (संसाधन का वर्तमान sys.version) भी भेजना होता है। निर्माण और हटाने में यह हेडर नहीं होता।