Google Drive की हर फ़ाइल, फ़ोल्डर, और शेयर की गई ड्राइव को
अनुमतियों से जुड़े संसाधन. हर संसाधन
किसी खास type
(उपयोगकर्ता, ग्रुप, डोमेन, कोई भी) के लिए अनुमति की पहचान करता है
और role
, जैसे कि "टिप्पणी करने वाला" या "रीडर" हो. उदाहरण के लिए, किसी फ़ाइल में
किसी खास उपयोगकर्ता (type=user
) को रीड ओनली ऐक्सेस देने की अनुमति
(role=reader
) जब किसी दूसरे ग्रुप के सदस्यों को कोई और अनुमति दी जाती है
(type=group
) फ़ाइल (role=commenter
) में टिप्पणियां जोड़ने की सुविधा.
हर भूमिका के लिए और अनुमति दी गई कार्रवाइयों की पूरी सूची के लिए, इसे देखें भूमिकाएं और अनुमतियां हैं.
Drive के संसाधनों को शेयर करने की स्थितियां
शेयर करने के तरीके पांच अलग-अलग तरह के होते हैं:
'मेरी ड्राइव' में फ़ाइल शेयर करने के लिए, उपयोगकर्ता के पास
role=writer
होना ज़रूरी है याrole=owner
.अगर
writersCanShare
की बूलियन वैल्यू फ़ाइल के लिए,False
पर सेट है, तो उपयोगकर्ता के पासrole=owner
होना ज़रूरी है.अगर
role=writer
वाले उपयोगकर्ता के पास, कुछ समय के लिए अमान्य है, तो वे फ़ाइल शेयर नहीं कर सकते. ज़्यादा के लिए जानकारी, फ़ाइल को सीमित करने के लिए समाप्ति तारीख सेट करें ऐक्सेस पर टैप करें.
'मेरी ड्राइव' में मौजूद कोई फ़ोल्डर शेयर करने के लिए, उपयोगकर्ता के पास
role=writer
याrole=owner
.अगर फ़ाइल की
writersCanShare
बूलियन वैल्यू कोFalse
पर सेट किया गया है, उपयोगकर्ता के पासrole=owner
की ज़्यादा अनुमति होनी चाहिए.कुछ समय के लिए ऐक्सेस की अनुमति नहीं है. ऐक्सेस के लिए, समयसीमा खत्म होने की तारीख और समय तय किया जाता है
role=writer
वाले 'मेरी ड्राइव' फ़ोल्डर में. ज़्यादा के लिए जानकारी, देखें फ़ाइल का ऐक्सेस सीमित करने के लिए, ऐक्सेस खत्म होने की तारीख सेट करें.
शेयर की गई ड्राइव में फ़ाइल शेयर करने के लिए, उपयोगकर्ता के पास
role=writer
,role=fileOrganizer
याrole=organizer
.writersCanShare
सेटिंग, 'शेयर की गई ड्राइव' में मौजूद आइटम पर लागू नहीं होती है. इसे ऐसे माना जाता है जैसे यह हमेशाTrue
पर सेट हो.
शेयर की गई ड्राइव में फ़ोल्डर शेयर करने के लिए, उपयोगकर्ता के पास
role=organizer
होना ज़रूरी है.- अगर किसी कीवर्ड पर
sharingFoldersRequiresOrganizerPermission
प्रतिबंध शेयर की गई ड्राइव कोFalse
पर सेट किया गया है.role=fileOrganizer
वाले उपयोगकर्ता ये काम कर सकते हैं उस 'शेयर की गई ड्राइव' में मौजूद फ़ोल्डर शेयर कर सकते हैं.
- अगर किसी कीवर्ड पर
शेयर की गई ड्राइव की सदस्यता मैनेज करने के लिए, उपयोगकर्ता के पास
role=organizer
होना ज़रूरी है. सिर्फ़ उपयोगकर्ता और ग्रुप, शेयर की गई ड्राइव के सदस्य हो सकते हैं.
फ़ाइल का ऐक्सेस सीमित करने के लिए, ऐक्सेस खत्म होने की तारीख सेट करें
जब किसी संवेदनशील प्रोजेक्ट पर लोगों के साथ काम किया जाता है, तो हो सकता है कि एक अवधि के बाद Drive में कुछ फ़ाइलों के ऐक्सेस पर पाबंदी लगा देते हैं समय. 'मेरी ड्राइव' में मौजूद फ़ाइलों के लिए, ऐक्सेस खत्म होने की तारीख इस पर सेट की जा सकती है: उस फ़ाइल के ऐक्सेस को सीमित करें या हटाएं.
ऐक्सेस खत्म होने की तारीख सेट करने के लिए:
permissions.create
का इस्तेमाल करें तरीका औरpermissions.expirationTime
फ़ील्ड (अन्य ज़रूरी फ़ील्ड के साथ) पर क्लिक करें. ज़्यादा जानकारी के लिए, यह देखें अनुमति बनाएं.permissions.update
का इस्तेमाल करें तरीका औरpermissions.expirationTime
फ़ील्ड को सेट करें (दूसरे के साथ आवश्यक फ़ील्ड). ज़्यादा जानकारी के लिए, बदलें अनुमतियां हैं.
expirationTime
फ़ील्ड से पता चलता है कि आरएफ़सी 3339 का इस्तेमाल करके, अनुमति की समयसीमा कब खत्म होती है
तारीख और समय
को अपनाएं. खत्म होने के समय पर ये पाबंदियां होती हैं:
- इन्हें सिर्फ़ उपयोगकर्ता और ग्रुप की अनुमतियों पर सेट किया जा सकता है.
- समय की जानकारी, आने वाले समय की होनी चाहिए.
- यह समय, आने वाले समय में एक साल से ज़्यादा का नहीं हो सकता.
ऐक्सेस खत्म होने की तारीख के बारे में ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
- फ़ाइल ऐक्सेस करने के लिए, समयसीमा खत्म होने की तारीख सेट करना
- फ़ाइल ऐक्सेस करने की समयसीमा खत्म होने की तारीख जोड़ना को अपनाएं.
अनुमति का प्रमोशन
किसी फ़ोल्डर के लिए अनुमतियों की सूचियां, नीचे की ओर बढ़ती हैं. साथ ही, सभी चाइल्ड फ़ाइलों और फ़ोल्डर को पैरंट से अनुमतियां मिलती हैं. जब भी अनुमतियां दें या क्रम में बदलाव किया जाता है और सभी नेस्ट किए गए फ़ोल्डर. उदाहरण के लिए, अगर कोई फ़ाइल किसी फ़ोल्डर में मौजूद है और उस फ़ोल्डर को किसी दूसरे फ़ोल्डर में ले जाया गया है तो नए फ़ोल्डर की अनुमतियां फ़ाइल पर लागू हो जाएंगी. अगर नया फ़ोल्डर, फ़ाइल के उपयोगकर्ता को "लेखक" जैसी कोई नई भूमिका देता है, तो यह अपनी पुरानी भूमिका को बदल देता है.
इसके उलट, अगर कोई फ़ाइल किसी फ़ोल्डर से role=writer
को इनहेरिट करती है और उसे
कोई अन्य फ़ोल्डर जो "रीडर" उपलब्ध कराता है भूमिका, फ़ाइल अब इनहेरिट की जाती है
role=reader
.
अपने-आप मिली अनुमतियां, शेयर की गई ड्राइव में मौजूद किसी फ़ाइल या फ़ोल्डर से नहीं हटाई जा सकतीं. इसके बजाय, इन अनुमतियों को सीधे तौर पर या किसी अन्य तरीके से, पैरंट के हिसाब से अडजस्ट किया जाना चाहिए. जो इनहेरिट किए गए हैं. सामान्य तौर पर मिली अनुमतियां, इन आइटम से हटाई जा सकती हैं "मेरी ड्राइव" या "मुझसे शेयर की गई."
इसके उलट, इनहेरिट की गई अनुमतियों को 'मेरी साइट' में किसी फ़ाइल या फ़ोल्डर पर बदला जा सकता है
ड्राइविंग. इसलिए, अगर कोई फ़ाइल role=writer
को My
Drive फ़ोल्डर है, तो आप फ़ाइल पर role=reader
को सेट करके इसका साइज़ नीचे कर सकते हैं
अनुमति का लेवल सेट करें.
मिलने वाली अनुमतियां
अनुमतियों से जुड़ा संसाधन आखिरकार
तय करें कि मौजूदा उपयोगकर्ता किसी फ़ाइल या फ़ोल्डर पर कोई कार्रवाई कर सकता है या नहीं.
इसके बजाय, फ़ाइल संसाधन में
बूलियन capabilities
फ़ील्ड का इस्तेमाल यह बताने के लिए किया जाता है कि किसी कार्रवाई को
फ़ाइल या फ़ोल्डर पर किया गया था. Google Drive API, इन फ़ील्ड को इनके आधार पर सेट करता है
फ़ाइल या फ़ोल्डर से जुड़े मौजूदा उपयोगकर्ता की अनुमतियों का संसाधन.
उदाहरण के लिए, जब एलेक्स आपके ऐप्लिकेशन में लॉग इन करता है और किसी फ़ाइल को शेयर करने की कोशिश करता है, तो एलेक्स की भूमिका
फ़ाइल की अनुमतियों के लिए चेक किया जाता है. अगर भूमिका उन्हें फ़ाइल शेयर करने की अनुमति देती है,
फ़ाइल से जुड़े capabilities
, जैसे कि canShare
भरे हुए हैं
वह भूमिका के हिसाब से होनी चाहिए. अगर एलेक्स फ़ाइल शेयर करना चाहता है, तो आपका ऐप्लिकेशन
यह पक्का करने के लिए कि canShare
, true
पर सेट हो, capabilities
.
capabilities
फ़ाइल को फिर से पाने के उदाहरण के लिए, उपयोगकर्ता की पुष्टि करें देखें
अनुमतियां हैं.
अनुमति बनाएं
अनुमति बनाते समय, इन दो फ़ील्ड की ज़रूरत होती है:
type
—type
अनुमति के दायरे की पहचान करता है (user
,group
,domain
याanyone
).type=user
के साथ दी गई अनुमति किसी खास उपयोगकर्ता पर लागू होती है, जबकिtype=domain
की अनुमति किसी खास डोमेन में सभी पर लागू होती है.role
—role
फ़ील्ड उन कार्रवाइयों की पहचान करता है जिन्हेंtype
कर सकता है. उदाहरण के लिए,type=user
औरrole=reader
के साथ किसी खास उपयोगकर्ता को अनुमति मिलती है फ़ाइल या फ़ोल्डर का रीड ओनली ऐक्सेस. याtype=domain
से अनुमति लें औरrole=commenter
, डोमेन के सभी लोगों को किसी फ़ाइल में टिप्पणियां जोड़ने की सुविधा देता है. इसके लिए हर भूमिका के लिए और उसकी अनुमति वाली कार्रवाइयों की पूरी सूची देखें. भूमिकाएं और अनुमतियां हैं.
जब type=user
या type=group
के लिए कोई अनुमति बनाई जाती है, तो आपको यह भी करना होगा
टाई करने के लिए emailAddress
उपलब्ध कराएं
किसी खास उपयोगकर्ता या ग्रुप को अनुमति देनी होगी.
जब type=domain
के लिए कोई अनुमति बनाई जाती है, तो आपको
किसी खास डोमेन को जोड़ने के लिए domain
कितने लोगों ने मदद की.
अनुमति बनाने के लिए:
permissions.create
तरीका इस्तेमाल करें फ़ाइल या फ़ोल्डर के लिए,fileId
का इस्तेमाल करें.- अनुरोध के मुख्य हिस्से में,
type
औरrole
की जानकारी दें. - अगर
type=user
याtype=group
है, तोemailAddress
दें. अगरtype=domain
,domain
दें.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, अनुमति बनाने का तरीका बताता है. रिस्पॉन्स, Permission
संसाधन का इंस्टेंस दिखाता है, जिसमें असाइन किए गए permissionId
भी शामिल होते हैं.
अनुरोध करें
POST https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
{ "requests": [ { "type": "user", "role": "commenter", "emailAddress": "alex@altostrat.com" } ] }
जवाब
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "commenter"
}
टारगेट ऑडियंस का इस्तेमाल करें
टारगेट ऑडियंस, डिपार्टमेंट या टीम जैसे लोगों के ऐसे ग्रुप होते हैं जिन्हें आपके पास उपयोगकर्ताओं को अपने आइटम शेयर करने का सुझाव दिया जाता है. आप अपने उपयोगकर्ताओं को ऐसे आइटम जिनमें आपके पूरे कॉन्टेंट के बजाय, ज़्यादा खास या सीमित ऑडियंस होती है संगठन. टारगेट ऑडियंस की मदद से, प्लैटफ़ॉर्म की सुरक्षा और निजता को बेहतर बनाया जा सकता है आपके डेटा को डाउनलोड और शेयर करना आसान हो. ज़्यादा के लिए लक्ष्य के बारे में जानकारी ऑडियंस को अपनाएं.
टारगेट ऑडियंस का इस्तेमाल करने के लिए:
Google Admin console में, मेन्यू पर जाएं > डायरेक्ट्री > टारगेट ऑडियंस.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया हैइस टास्क के लिए, आपको उस खाते से साइन इन करना होगा जिसके पास सुपर एडमिन का अधिकार है.
टारगेट ऑडियंस की सूची में, टारगेट ऑडियंस के नाम पर क्लिक करें. यहां की यात्रा पर हूं टारगेट ऑडियंस बनाने और टारगेट ऑडियंस बनाने ऑडियंस
टारगेट ऑडियंस के यूआरएल से यूनीक आईडी कॉपी करें:
https://admin.google.com/ac/targetaudiences/ID
.type=domain
के साथ अनुमति बनाएं औरdomain
फ़ील्ड कोID.audience.googledomains.com
पर सेट करें.
यह देखने के लिए कि उपयोगकर्ता टारगेट ऑडियंस के साथ कैसे इंटरैक्ट करते हैं, लिंक के लिए उपयोगकर्ता अनुभव देखें शेयर करना को अपनाएं.
किसी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव के लिए सभी अनुमतियां वापस पाना
permissions.list
तरीके का इस्तेमाल करके,
किसी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव की सभी अनुमतियां फिर से पाएं.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, सभी अनुमतियां पाने का तरीका बताता है. रिस्पॉन्स, अनुमतियों की सूची दिखाता है.
अनुरोध करें
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
जवाब
{
"kind": "drive#permissionList",
"permissions": [
{
"id": "PERMISSION_ID
",
"type": "user",
"kind": "drive#permission",
"role": "commenter"
}
]
}
उपयोगकर्ता की अनुमतियों की पुष्टि करें
जब आपका ऐप्लिकेशन कोई फ़ाइल खोलता है, तो उसे फ़ाइल की क्षमताओं की जांच करनी चाहिए. साथ ही,
मौजूदा उपयोगकर्ता की अनुमतियां दिखाने के लिए यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना. उदाहरण के लिए, अगर उपयोगकर्ता
फ़ाइल पर canComment
क्षमता नहीं है, टिप्पणी करने की सुविधा
यूज़र इंटरफ़ेस (यूआई) में बंद होना चाहिए.
capabilities
के बारे में ज़्यादा जानकारी के लिए, क्षमताएं देखें
सेक्शन पढ़ें.
क्षमताओं को देखने के लिए, files.get
को इसके साथ कॉल करें:
fileId
और fields
पैरामीटर को capabilities
फ़ील्ड पर सेट किया गया है. इसके लिए
fields
पैरामीटर का इस्तेमाल करके, फ़ील्ड रिटर्न के बारे में ज़्यादा जानकारी देखें.
फ़ाइल के लिए खास फ़ील्ड दिखाएं.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, उपयोगकर्ता की अनुमतियों की पुष्टि करने का तरीका बताता है. रिस्पॉन्स, उन क्षमताओं की सूची दिखाता है जो उपयोगकर्ता के पास फ़ाइल में हैं. हर सुविधा एक सटीक कार्रवाई से जुड़ी होती है, जिसे उपयोगकर्ता कर सकता है. कुछ फ़ील्ड में, सिर्फ़ शेयर की गई ड्राइव में मौजूद आइटम का डेटा अपने-आप भर जाता है.
अनुरोध करें
GET https://www.googleapis.com/drive/v3/files/FILE_ID
?fields=capabilities
जवाब
{ "capabilities": { "canAcceptOwnership": false, "canAddChildren": false, "canAddMyDriveParent": false, "canChangeCopyRequiresWriterPermission": true, "canChangeSecurityUpdateEnabled": false, "canComment": true, "canCopy": true, "canDelete": true, "canDownload": true, "canEdit": true, "canListChildren": false, "canModifyContent": true, "canModifyContentRestriction": true, "canModifyLabels": true, "canMoveChildrenWithinDrive": false, "canMoveItemOutOfDrive": true, "canMoveItemWithinDrive": true, "canReadLabels": true, "canReadRevisions": true, "canRemoveChildren": false, "canRemoveMyDriveParent": true, "canRename": true, "canShare": true, "canTrash": true, "canUntrash": true } }
शेयर की गई ड्राइव की फ़ाइलों और फ़ोल्डर
किसी फ़ाइल या फ़ोल्डर की भूमिका बदलने के लिए, आपको भूमिका का सोर्स पता होना चाहिए. शेयर की गई ड्राइव के लिए भूमिका का सोर्स, शेयर की गई ड्राइव की सदस्यता के आधार पर हो सकता है ड्राइव, फ़ोल्डर में मौजूद भूमिका या किसी फ़ाइल पर मौजूद भूमिका.
किसी शेयर की गई ड्राइव या उसमें मौजूद आइटम के लिए भूमिका का सोर्स पता करने के लिए
ड्राइव न करें, तो permissions.get
को
fileId
, permissionId
, और fields
पैरामीटर को
permissionDetails
फ़ील्ड. permissionId
को ढूंढने के लिए, इसका इस्तेमाल करें
permissions.list
ने fileId
के साथ काम किया. यहां की यात्रा पर हूं
permissions.list
अनुरोध पर permissionDetails
फ़ील्ड फ़ेच करें,
permissions/permissionDetails
के लिए fields
पैरामीटर.
इस फ़ील्ड में उपयोगकर्ता के लिए, इनहेरिट की गई और डायरेक्ट फ़ाइल की सभी अनुमतियां शामिल की गई हैं, का उपयोग करने के लिए प्रोत्साहित करते हैं.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, भूमिका का सोर्स पता करने का तरीका बताता है. रिस्पॉन्स, Permission
संसाधन का permissionDetails
दिखाता है. inheritedFrom
फ़ील्ड उस आइटम का आईडी देता है जिससे अनुमति मिली है.
अनुरोध करें
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
?fields=permissionDetails&supportsAllDrives=true
जवाब
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID
",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}
अनुमतियां बदलें
किसी फ़ाइल या फ़ोल्डर की अनुमतियां बदलने के लिए, असाइन की गई भूमिका को बदला जा सकता है:
permissions.update
को इस बदलाव की अनुमति काpermissionId
और इसके लिएfileId
शेयर की गई ड्राइव, फ़ोल्डर या उससे जुड़ी फ़ाइल या फ़ोल्डर शामिल है.permissionId
को ढूंढने के लिए, इसका इस्तेमाल करेंpermissions.list
नेfileId
के साथ काम किया.अनुरोध में, नए
role
की पहचान करें.
शेयर की गई ड्राइव में मौजूद अलग-अलग फ़ाइलों या फ़ोल्डर के लिए भी अनुमतियां दी जा सकती हैं
अगर उपयोगकर्ता या ग्रुप पहले से ही सदस्य है. उदाहरण के लिए, एलेक्स के पास role=commenter
है
'शेयर की गई ड्राइव' में उनकी सदस्यता के हिस्से के तौर पर दिखते हैं. हालांकि, आपका ऐप्लिकेशन एलेक्स को अनुमति दे सकता है
शेयर की गई ड्राइव में मौजूद फ़ाइल के लिए role=writer
. इस मामले में, क्योंकि नई भूमिका
सदस्यता के ज़रिए मिलने वाली भूमिका की तुलना में, वे इसमें
अनुमति, फ़ाइल या फ़ोल्डर के लिए असरदार भूमिका बन जाती है.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल किसी फ़ाइल या फ़ोल्डर की अनुमतियों को, टिप्पणी करने वाले व्यक्ति से लेखक के तौर पर बदलने का तरीका बताता है. रिस्पॉन्स, Permission
संसाधन का इंस्टेंस दिखाता है.
अनुरोध करें
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
{ "requests": [ { "role": "writer" } ] }
जवाब
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "writer"
}
किसी फ़ाइल या फ़ोल्डर का ऐक्सेस वापस लेना
किसी फ़ाइल या फ़ोल्डर का ऐक्सेस रद्द करने के लिए, इस नंबर पर कॉल करें
delete
को fileId
और
अनुमति मिटाने के लिए permissionId
.
"मेरी ड्राइव" में मौजूद आइटम के लिए, इनहेरिट की गई किसी कॉपी को मिटाया जा सकता है अनुमति. इनहेरिट की गई अनुमति मिटाने से आइटम का ऐक्सेस रद्द हो जाता है और चाइल्ड आइटम, अगर कोई हो.
शेयर की गई ड्राइव में मौजूद आइटम के लिए, इनहेरिट की गई अनुमतियां रद्द नहीं की जा सकतीं. अपडेट करें या इसके बजाय, पैरंट फ़ाइल या फ़ोल्डर से अनुमति वापस लें.
delete
ऑपरेशन का इस्तेमाल सीधे इस पर लागू की गई अनुमतियों को मिटाने के लिए भी किया जाता है
शेयर की गई ड्राइव की फ़ाइल या फ़ोल्डर है.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, permissionId
को मिटाकर, ऐक्सेस को वापस लेने का तरीका बताता है. जवाब सही होने पर, जवाब का मुख्य हिस्सा खाली होता है. यह पुष्टि करने के लिए कि अनुमति हटा दी गई है, fileId
के साथ permissions.list
का इस्तेमाल करें.
अनुरोध करें
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
फ़ाइल का मालिकाना हक, उसी संगठन के किसी दूसरे Google Workspace खाते को ट्रांसफ़र करना
"मेरी ड्राइव" में मौजूद फ़ाइलों का मालिकाना हक पैसे यहां से ट्रांसफ़र किए जा सकते हैं एक Google Workspace खाता उसी संगठन के किसी दूसरे खाते में लिंक कर दिया गया हो. ऐसा संगठन जिसके पास शेयर किए गए कॉन्टेंट का मालिकाना हक है Drive में मौजूद फ़ाइलों का मालिकाना हक आपके पास ही रहता है. इसलिए, मालिकाना हक ट्रांसफ़र करने की सुविधा उपलब्ध नहीं है शेयर की गई ड्राइव में मौजूद फ़ाइलों और फ़ोल्डर के लिए. 'शेयर की गई ड्राइव' के आयोजकों को एक से दूसरे ग्रुप में ले जाया जा सकता है उस 'शेयर की गई ड्राइव' के आइटम और अपनी "मेरी ड्राइव" में कौनसा उन्हें मालिकाना हक ट्रांसफ़र कर देती है.
"मेरी ड्राइव" में किसी फ़ाइल का मालिकाना हक ट्रांसफ़र करने के लिए, इनमें से कोई एक काम करें फ़ॉलो किया जा रहा है:
किसी खास उपयोगकर्ता को देने के लिए फ़ाइल की अनुमति बनाएं (
type=user
) मालिक का ऐक्सेस (role=owner
).role=owner
में किसी मौजूदा फ़ाइल की अनुमति को अपडेट करें और ट्रांसफ़र करें बताए गए उपयोगकर्ता (transferOwnership=true
) को मालिकाना हक.
फ़ाइल का मालिकाना हक एक उपभोक्ता खाते से दूसरे उपभोक्ता खाते में ट्रांसफ़र करना
फ़ाइलों का मालिकाना हक एक उपभोक्ता खाते के बीच दूसरे उपभोक्ता खाते में ट्रांसफ़र किया जा सकता है. हालांकि, Drive, दो खातों के बीच किसी फ़ाइल का मालिकाना हक ट्रांसफ़र नहीं करता उपभोक्ता खाते जब तक संभावित नया मालिक ट्रांसफ़र के लिए साफ़ तौर पर सहमति नहीं देता. ट्रांसफ़र करने के लिए मालिकाना हक को एक उपभोक्ता खाते से दूसरे उपभोक्ता खाते में दर्ज करना:
मौजूदा मालिक, मालिकाना हक ट्रांसफ़र करने या उसमें बदलाव करने की प्रोसेस शुरू करता है संभावित नए मालिक की फ़ाइल से जुड़ी अनुमति. अनुमति में यह शामिल होना चाहिए ये सेटिंग:
role=writer
,type=user
, औरpendingOwner=true
. अगर नया स्वामी संभावित स्वामी के लिए एक अनुमति बना रहा है, एक ईमेल संभावित नए मालिक को यह सूचना भेजी जाती है कि वे जब आपसे फ़ाइल का मालिकाना हक पाने के लिए कहा जाए.नया मालिक, प्रोजेक्ट बनाते या अपडेट करके, मालिकाना हक ट्रांसफ़र करने का अनुरोध स्वीकार करता है अनुमति नहीं है. अनुमति में ये सेटिंग शामिल होनी चाहिए:
role=owner
औरtransferOwnership=true
. अगर नया मालिक, नई अनुमति, पिछले स्वामी को एक ईमेल नोटिफ़िकेशन भेजा जाता है यह बताता है कि मालिकाना हक को ट्रांसफ़र कर दिया गया है.
जब कोई फ़ाइल ट्रांसफ़र की जाती है, तो पिछले मालिक की भूमिका डाउनग्रेड होकर writer
हो जाती है.
बैच रिक्वेस्ट की मदद से कई अनुमतियों में बदलाव करना
हमारा सुझाव है कि आप एक से ज़्यादा बैच में बदलाव करने के लिए, बैच अनुरोध अनुमतियां दी हैं.
नीचे एक साथ, बैच की अनुमति में बदलाव करने का उदाहरण दिया गया है क्लाइंट लाइब्रेरी पर जाएं.