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
को इनहेरिट करती है, तो फ़ाइल में role=reader
को सेट करके, उसकी अनुमति का लेवल कम किया जा सकता है.
मिलने वाली अनुमतियां
अनुमतियां संसाधन से इस बात का पता नहीं चलता कि मौजूदा उपयोगकर्ता किसी फ़ाइल या फ़ोल्डर पर कार्रवाइयां कर सकता है या नहीं.
इसके बजाय, फ़ाइलें संसाधन में बूलियन capabilities
फ़ील्ड का कलेक्शन होता है. इसका इस्तेमाल यह बताने के लिए किया जाता है कि किसी फ़ाइल या फ़ोल्डर पर कोई कार्रवाई की जा सकती है या नहीं. Google Drive API, इन फ़ील्ड को फ़ाइल या फ़ोल्डर
से जुड़े मौजूदा उपयोगकर्ता की अनुमति संसाधन के आधार पर सेट करता है.
उदाहरण के लिए, जब एलेक्स आपके ऐप्लिकेशन में लॉग इन करता है और कोई फ़ाइल शेयर करने की कोशिश करता है, तो फ़ाइल के लिए
एलेक्स की भूमिका की जांच की जाती है. अगर भूमिका से उन्हें फ़ाइल शेयर करने की अनुमति मिलती है, तो फ़ाइल से जुड़े capabilities
, जैसे कि canShare
को भूमिका के हिसाब से भरा जाता है. अगर एलेक्स को फ़ाइल शेयर करनी है, तो आपका ऐप्लिकेशन capabilities
की जांच करता है, ताकि यह पक्का किया जा सके कि canShare
को true
पर सेट किया गया है.
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
भी देना होगा.
अनुमति बनाने के लिए:
- जुड़ी हुई फ़ाइल या फ़ोल्डर के लिए
fileId
के साथpermissions.create
तरीके का इस्तेमाल करें. - अनुरोध के मुख्य हिस्से में,
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
के बारे में ज़्यादा जानकारी के लिए, ऊपर दिया गया क्षमताएं सेक्शन देखें.
क्षमताओं की जांच करने के लिए, capabilities
फ़ील्ड पर सेट किए गए fileId
और fields
पैरामीटर के साथ files.get
को कॉल करें. 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
ढूंढने के लिए, fileId
के साथ permissions.list
का इस्तेमाल करें. permissions.list
अनुरोध पर permissionDetails
फ़ील्ड को फ़ेच करने के लिए, fields
पैरामीटर को permissions/permissionDetails
पर सेट करें.
यह फ़ील्ड उपयोगकर्ता, ग्रुप या डोमेन के लिए, इनहेरिट की गई और सीधे तौर पर दी गई सभी फ़ाइल अनुमतियों का आकलन करता है.
एक उदाहरण दिखाएं
नीचे दिए गए कोड सैंपल में, सोर्स की भूमिका तय करने का तरीका बताया गया है. रिस्पॉन्स, 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
ढूंढने के लिए,fileId
के साथpermissions.list
का इस्तेमाल करें.अनुरोध में, नए
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
को मिटाकर ऐक्सेस रद्द करने का तरीका बताया गया है. कामयाब रहने पर, जवाब का मुख्य हिस्सा खाली रहता है. यह पक्का करने के लिए कि अनुमति हटा दी गई है, permissions.list
को fileId
के साथ इस्तेमाल करें.
अनुरोध करें
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
फ़ाइल का मालिकाना हक, अपने संगठन के किसी दूसरे Google Workspace खाते को ट्रांसफ़र करें
"मेरी ड्राइव" में मौजूद फ़ाइलों का मालिकाना हक, अपने संगठन के एक Google Workspace खाते से उसी संगठन के दूसरे खाते में ट्रांसफ़र किया जा सकता है. शेयर की गई ड्राइव का मालिकाना हक रखने वाला संगठन उसमें मौजूद फ़ाइलों का मालिक होता है. इसलिए, 'शेयर की गई ड्राइव' में मौजूद फ़ाइलों और फ़ोल्डर के लिए मालिकाना हक ट्रांसफ़र नहीं किया जा सकता. शेयर की गई ड्राइव के आयोजक, आइटम को उस 'शेयर की गई ड्राइव' से अपनी "मेरी ड्राइव" में ले जा सकते हैं. इस तरह उनका मालिकाना हक उन्हें मिल जाएगा.
"मेरी ड्राइव" में मौजूद किसी फ़ाइल का मालिकाना हक ट्रांसफ़र करने के लिए, इनमें से कोई एक काम करें:
किसी खास उपयोगकर्ता (
type=user
) मालिक (role=owner
) को ऐक्सेस देने के लिए, फ़ाइल की अनुमति बनाएं.role=owner
के साथ किसी मौजूदा फ़ाइल की अनुमति अपडेट करें और खास उपयोगकर्ता (transferOwnership=true
) को मालिकाना हक ट्रांसफ़र करें.
फ़ाइल का मालिकाना हक एक उपभोक्ता खाते से दूसरे को ट्रांसफ़र करना
फ़ाइलों का मालिकाना हक एक उपभोक्ता खाते को दूसरे उपभोक्ता खाते को ट्रांसफ़र किया जा सकता है. हालांकि, Drive किसी फ़ाइल का मालिकाना हक दो उपभोक्ता खातों में तब तक ट्रांसफ़र नहीं करता है, जब तक कि संभावित नया मालिक ट्रांसफ़र के लिए साफ़ तौर पर सहमति नहीं देता है. फ़ाइल का मालिकाना हक एक उपभोक्ता खाते से दूसरे ग्राहक खाते में ट्रांसफ़र करने के लिए:
मौजूदा मालिक, संभावित नए मालिक की फ़ाइल अनुमति को बनाकर या अपडेट करके, मालिकाना हक ट्रांसफ़र करने की प्रक्रिया शुरू करता है. अनुमति में ये सेटिंग शामिल होनी चाहिए:
role=writer
,type=user
, औरpendingOwner=true
. अगर नया मालिक, भावी मालिक के लिए अनुमति बना रहा है, तो उस संभावित नए मालिक को एक ईमेल सूचना भेजी जाती है. इसमें बताया जाता है कि उसे फ़ाइल का मालिकाना हक लेने के लिए कहा जा रहा है.नया मालिक, फ़ाइल के ऐक्सेस की अनुमति बनाकर या उसे अपडेट करके, मालिकाना हक ट्रांसफ़र करने का अनुरोध स्वीकार करता है. अनुमति में ये सेटिंग शामिल होनी चाहिए:
role=owner
औरtransferOwnership=true
. अगर नया मालिक नई अनुमति बनाता है, तो पिछले मालिक को एक ईमेल सूचना भेजी जाती है. इसमें बताया जाता है कि मालिकाना हक ट्रांसफ़र कर दिया गया है.
जब कोई फ़ाइल ट्रांसफ़र की जाती है, तो पिछले मालिक की भूमिका writer
से डाउनग्रेड हो जाती है.
एक साथ कई अनुरोधों की मदद से, एक से ज़्यादा अनुमतियों में बदलाव करना
हमारा सुझाव है कि एक से ज़्यादा अनुमतियों में बदलाव करने के लिए, बैच अनुरोध का इस्तेमाल करें.
क्लाइंट लाइब्रेरी की मदद से, बैच की अनुमति में बदलाव करने का एक उदाहरण नीचे दिया गया है.