Google Drive की हर फ़ाइल, फ़ोल्डर, और शेयर की गई ड्राइव में, permissions
संसाधन जुड़े होते हैं. हर संसाधन,
किसी खास type
(user
, group
, domain
,
anyone
) और role
(owner
, organizer
, fileOrganizer
, writer
,
commenter
, reader
) की अनुमति का पता लगाता है. उदाहरण के लिए, किसी फ़ाइल के पास किसी खास उपयोगकर्ता (type=user
) को सिर्फ़ पढ़ने का ऐक्सेस (role=reader
) देने की अनुमति हो सकती है. वहीं, कोई अन्य फ़ाइल (type=group
) किसी फ़ाइल (type=group
) के सदस्यों को फ़ाइल (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()
तरीके का इस्तेमाल करें और अन्य ज़रूरी फ़ील्ड के साथexpirationTime
फ़ील्ड सेट करें. ज़्यादा जानकारी के लिए, अनुमति बनाना देखें.permissions
संसाधन परupdate()
तरीके का इस्तेमाल करें औरexpirationTime
फ़ील्ड को अन्य ज़रूरी फ़ील्ड के साथ सेट करें. ज़्यादा जानकारी के लिए, अनुमतियों में बदलाव करना लेख पढ़ें.
expirationTime
फ़ील्ड से पता चलता है कि आरएफ़सी 3339 की तारीख-समय का इस्तेमाल करके, अनुमति की समयसीमा कब खत्म होती है. खत्म होने के समय पर ये पाबंदियां लागू होती हैं:
- इन्हें सिर्फ़ उपयोगकर्ता और ग्रुप की अनुमतियों पर सेट किया जा सकता है.
- समय, आने वाले समय का होना चाहिए.
- यह समय, आने वाले एक साल से ज़्यादा का नहीं हो सकता.
खत्म होने की तारीख के बारे में ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
अनुमति का प्रसार
किसी फ़ोल्डर के लिए अनुमतियों की सूचियां, नीचे की ओर बढ़ती हैं. साथ ही, सभी चाइल्ड फ़ाइलों और फ़ोल्डर पर पैरंट की अनुमतियां लागू होती हैं. जब भी अनुमतियों या क्रम में बदलाव किया जाता है, तो नेस्ट किए गए सभी फ़ोल्डर में बदलाव लागू हो जाता है. उदाहरण के लिए, अगर कोई फ़ाइल किसी फ़ोल्डर में मौजूद है और उस फ़ोल्डर को किसी दूसरे फ़ोल्डर में ले जाया जाता है, तो नए फ़ोल्डर की अनुमतियां फ़ाइल पर लागू हो जाती हैं. अगर नए फ़ोल्डर में फ़ाइल के उपयोगकर्ता को "लेखक" जैसी कोई नई भूमिका दी जाती है, तो यह उसकी पुरानी भूमिका को बदल देगा.
इसके उलट, अगर किसी फ़ाइल को किसी फ़ोल्डर से role=writer
इनहेरिट किया जाता है और उसे "रीडर" भूमिका देने वाले किसी दूसरे फ़ोल्डर में ले जाया जाता है, तो फ़ाइल को अब role=reader
इनहेरिट किया जाता है.
अपने-आप मिली अनुमतियां, शेयर की गई ड्राइव में मौजूद किसी फ़ाइल या फ़ोल्डर से नहीं हटाई जा सकतीं. इसके बजाय, इन अनुमतियों को उस सीधे या किसी दूसरे पैरंट खाते पर अडजस्ट करना होगा जिससे इन्हें इनहेरिट किया गया था. "मेरी ड्राइव" या "मुझसे शेयर की गई" में मौजूद आइटम से, इनहेरिट की गई अनुमतियां हटाई जा सकती हैं.
इसके उलट, 'मेरी ड्राइव' में मौजूद किसी फ़ाइल या फ़ोल्डर के लिए, इनहेरिट की गई अनुमतियों को बदला जा सकता है. इसलिए, अगर किसी फ़ाइल को My Drive फ़ोल्डर से role=writer
इनहेरिट किया जाता है, तो अनुमति के लेवल को कम करने के लिए, फ़ाइल पर role=reader
सेट किया जा सकता है.
मिलने वाली अनुमतियां
permissions
संसाधन से यह तय नहीं होता कि मौजूदा उपयोगकर्ता, किसी फ़ाइल या फ़ोल्डर पर कौनसी कार्रवाइयां कर सकता है. इसके बजाय, files
संसाधन में बूलियन 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
पाथ पैरामीटर के साथcreate()
तरीके का इस्तेमाल करें. - अनुरोध के मुख्य हिस्से में,
type
औरrole
की वैल्यू डालें. - अगर
type=user
याtype=group
है, तोemailAddress
डालें. अगरtype=domain
है, तोdomain
दें.
एक उदाहरण दिखाएं
नीचे दिए गए कोड सैंपल में, अनुमति बनाने का तरीका बताया गया है. रिस्पॉन्स में, असाइन किया गया permissionId
शामिल है. साथ ही, इसमें Permission
संसाधन का एक इंस्टेंस भी होता है.
अनुरोध
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
ढूंढने के लिए, fileId
पाथ पैरामीटर के साथ permissions
संसाधन पर, list()
तरीके का इस्तेमाल करें. list
अनुरोध पर permissionDetails
फ़ील्ड फ़ेच करने के लिए, fields
पैरामीटर को permissions/permissionDetails
पर सेट करें.
इस फ़ील्ड में, उपयोगकर्ता, ग्रुप या डोमेन के लिए, फ़ाइल की सभी इनहेरिट की गई और सीधे तौर पर मिली अनुमतियां शामिल होती हैं.
एक उदाहरण दिखाएं
नीचे दिया गया कोड सैंपल, भूमिका का सोर्स पता करने का तरीका बताता है. रिस्पॉन्स में, permissions
संसाधन का 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
ऐक्सेस दे सकता है. इस मामले में, सदस्यता के ज़रिए मिली भूमिका के मुकाबले नई भूमिका में ज़्यादा अनुमतियां होती हैं. इसलिए, फ़ाइल या फ़ोल्डर के लिए नई अनुमति, असल भूमिका बन जाती है.
एक उदाहरण दिखाएं
यहां दिए गए कोड सैंपल में, किसी फ़ाइल या फ़ोल्डर की अनुमतियों को टिप्पणी करने वाले से लेखक में बदलने का तरीका बताया गया है. रिस्पॉन्स में, permissions
रिसॉर्स का एक इंस्टेंस दिखता है.
अनुरोध
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"
}
ऐक्सेस के लंबित प्रस्तावों की सूची बनाएं और उनका समाधान करें
ऐक्सेस का प्रस्ताव, अनुरोध करने वाले व्यक्ति का वह प्रस्ताव होता है जिसमें वह Drive के किसी आइटम का ऐक्सेस पाने के लिए, अनुमति देने वाले व्यक्ति से अनुरोध करता है.
अनुमति देने वाला व्यक्ति, Drive की सभी फ़ाइलों में ऐक्सेस से जुड़े ऐसे सभी प्रस्तावों की समीक्षा कर सकता है और उन पर कार्रवाई कर सकता है जिन पर कार्रवाई नहीं हुई है. इसका मतलब है कि अनुमति मिलने की प्रोसेस को तेज़ किया जा सकता है. इसके लिए, ऐक्सेस के प्रस्तावों के लिए प्रोग्राम के हिसाब से क्वेरी की जा सकती है और फिर उन्हें हल किया जा सकता है. इससे, अनुमति देने वाले व्यक्ति को एक साथ कई प्रस्ताव देखने की सुविधा भी मिलती है.
Drive API में, accessproposals
संसाधन उपलब्ध हैं, ताकि ऐक्सेस के उन प्रस्तावों को देखा जा सके और उनका समाधान किया जा सके जिन्हें मंज़ूरी मिलना बाकी है. accessproposals
संसाधन के तरीके, फ़ाइलों, फ़ोल्डर, और शेयर की गई ड्राइव में मौजूद फ़ाइलों पर काम करते हैं. हालांकि, ये शेयर की गई ड्राइव पर नहीं काम करते.
नीचे दिए गए शब्द, ऐक्सेस के प्रस्तावों के लिए खास तौर पर इस्तेमाल किए जाते हैं:
- अनुरोध करने वाला: वह उपयोगकर्ता जो Drive के किसी आइटम का ऐक्सेस पाने का अनुरोध करता है.
- पाने वाला: वह उपयोगकर्ता जिसे फ़ाइल का ऐक्सेस देने का प्रस्ताव स्वीकार किए जाने पर, फ़ाइल के लिए अतिरिक्त अनुमतियां मिलेंगी. कई बार प्राप्तकर्ता ही अनुरोधकर्ता होता है, लेकिन हमेशा नहीं.
- अनुमति देने वाला व्यक्ति: ऐक्सेस के प्रस्ताव को स्वीकार या अस्वीकार करने के लिए ज़िम्मेदार उपयोगकर्ता. आम तौर पर, ऐसा इसलिए होता है, क्योंकि वे दस्तावेज़ के मालिक हैं या उनके पास दस्तावेज़ शेयर करने की अनुमति है.
ऐक्सेस के उन प्रस्तावों की सूची बनाएं जिन्हें मंज़ूरी मिलना बाकी है
Drive के किसी आइटम पर, ऐक्सेस के लिए मंज़ूरी बाकी होने वाले सभी प्रस्तावों की सूची देखने के लिए, accessproposals
संसाधन पर list()
तरीका कॉल करें और fileId
पाथ पैरामीटर शामिल करें.
किसी फ़ाइल पर अनुमति देने वाले लोग ही, उस फ़ाइल में मंज़ूरी बाकी प्रस्तावों की सूची बना सकते हैं. अनुमति देने वाला व्यक्ति, वह उपयोगकर्ता होता है जिसके पास फ़ाइल पर can_approve_access_proposals
की अनुमति होती है. अगर अनुरोध करने वाला व्यक्ति अनुमति देने वाला व्यक्ति नहीं है, तो खाली सूची दिखती है. capabilities
के बारे में ज़्यादा जानकारी के लिए, क्षमताएं सेक्शन देखें.
रिस्पॉन्स के मुख्य हिस्से में एक AccessProposal
ऑब्जेक्ट होता है. यह फ़ाइल में, ऐक्सेस के ऐसे प्रस्तावों की सूची दिखाता है जिन पर अब तक समाधान नहीं हुआ है.
AccessProposal
ऑब्जेक्ट में, हर प्रस्ताव के बारे में जानकारी शामिल होती है. जैसे, अनुरोध करने वाला व्यक्ति, मैसेज पाने वाला व्यक्ति, और अनुरोध करने वाले व्यक्ति का जोड़ा गया मैसेज. इसमें एक ऐसा AccessProposalRoleAndView
ऑब्जेक्ट भी शामिल होता है जो अनुरोध करने वाले के सुझाए गए role
को view
के साथ ग्रुप करता है. role
एक दोहराया गया फ़ील्ड है, इसलिए हर प्रस्ताव के लिए कई वैल्यू मौजूद हो सकती हैं. उदाहरण के लिए, किसी प्रस्ताव में role=reader
और view=published
का AccessProposalRoleAndView
ऑब्जेक्ट हो सकता है. साथ ही, इसमें सिर्फ़ role=writer
वैल्यू वाला एक और AccessProposalRoleAndView
ऑब्जेक्ट हो सकता है. ज़्यादा जानकारी के लिए, व्यू देखें.
ऐक्सेस के प्रपोज़ल को पसंद के मुताबिक पेजों में बांटने या उन्हें फ़िल्टर करने के लिए, इन क्वेरी पैरामीटर को पास करें:
pageToken
: सूची के पिछले कॉल से मिला पेज टोकन. अगले पेज को वापस पाने के लिए, यह टोकन दें.pageSize
: हर पेज पर, ऐक्सेस के ज़्यादा से ज़्यादा कितने सुझाव दिखाने हैं.
ऐक्सेस के लिए किए गए लंबित अनुरोधों को हल करना
Drive के किसी आइटम के लिए, ऐक्सेस के सभी लंबित अनुरोधों को हल करने के लिए, accessproposals
संसाधन पर resolve()
तरीके को कॉल करें. साथ ही, fileId
और proposalId
पाथ पैरामीटर शामिल करें.
resolve()
तरीके में एक action
क्वेरी पैरामीटर शामिल है, जो प्रस्ताव पर की जाने वाली कार्रवाई दिखाता है. Action
ऑब्जेक्ट, प्रस्ताव के स्टेटस में हुए बदलाव को ट्रैक करता है, ताकि हमें पता चल सके कि उसे स्वीकार किया जा रहा है या अस्वीकार.
resolve()
तरीके में, role
और
view
के वैकल्पिक क्वेरी पैरामीटर भी शामिल होते हैं. सिर्फ़ writer
, commenter
, और reader
भूमिकाएं इस्तेमाल की जा सकती हैं. अगर भूमिका तय नहीं की गई है, तो डिफ़ॉल्ट रूप से reader
लागू हो जाती है. send_notification
का एक अन्य वैकल्पिक क्वेरी पैरामीटर, अनुरोध स्वीकार या अस्वीकार किए जाने पर, अनुरोध करने वाले व्यक्ति को ईमेल से सूचना भेजने की सुविधा देता है.
list()
तरीके की तरह ही, प्रस्ताव को स्वीकार करने वाले उपयोगकर्ताओं के पास फ़ाइल पर
can_approve_access_proposals
की अनुमति होनी चाहिए. capabilities
के बारे में ज़्यादा जानकारी के लिए, सुविधाएं सेक्शन देखें.
प्रस्तावों का समाधान उन्हीं पैटर्न का इस्तेमाल करके किया जाता है जिनकी सूची Drive के संसाधन शेयर करने से जुड़ी स्थितियां में दी गई है. अगर एक ही उपयोगकर्ता के लिए, अलग-अलग भूमिकाओं के साथ कई प्रस्ताव हैं, तो ये नियम लागू होते हैं:
- अगर एक प्रस्ताव स्वीकार किया जाता है और एक अस्वीकार किया जाता है, तो स्वीकार किए गए प्रस्ताव में बताई गई भूमिका, Drive आइटम पर लागू होती है.
- अगर दोनों प्रस्तावों को एक ही समय पर स्वीकार किया जाता है, तो ज़्यादा अनुमति वाला प्रस्ताव (उदाहरण के लिए,
role=writer
बनामrole=reader
) लागू किया जाता है. आइटम से, ऐक्सेस का दूसरा प्रस्ताव हटा दिया जाता है.
resolve()
तरीके से प्रस्ताव भेजने के बाद, शेयर करने की कार्रवाई पूरी हो जाती है. AccessProposal
को अब list()
के तरीके से नहीं लौटाया जाता. प्रस्ताव स्वीकार करने के बाद, उपयोगकर्ता को किसी फ़ाइल या फ़ोल्डर की अनुमतियां अपडेट करने के लिए, permissions
कलेक्शन का इस्तेमाल करना होगा. ज़्यादा जानकारी के लिए, अनुमतियों में बदलाव करना सेक्शन देखें.
किसी फ़ाइल या फ़ोल्डर का ऐक्सेस रद्द करना
किसी फ़ाइल या फ़ोल्डर का ऐक्सेस रद्द करने के लिए, अनुमति मिटाने के लिए सेट किए गए fileId
और permissionId
पाथ पैरामीटर के साथ, permissions
संसाधन पर delete()
तरीके को कॉल करें.
"मेरी ड्राइव" में मौजूद आइटम के लिए, इनहेरिट की गई अनुमति को मिटाया जा सकता है. इनहेरिट की गई अनुमति मिटाने पर, आइटम और उसके चाइल्ड आइटम का ऐक्सेस रद्द हो जाता है.
शेयर की गई ड्राइव में मौजूद आइटम के लिए, इनहेरिट की गई अनुमतियां वापस नहीं ली जा सकतीं. इसके बजाय, पैरंट फ़ाइल या फ़ोल्डर की अनुमति अपडेट करें या रद्द करें.
delete()
तरीके का इस्तेमाल, शेयर की गई Drive फ़ाइल या फ़ोल्डर पर सीधे लागू की गई अनुमतियों को मिटाने के लिए भी किया जाता है.
एक उदाहरण दिखाएं
यहां दिए गए कोड के सैंपल में, permissionId
को मिटाकर ऐक्सेस रद्द करने का तरीका बताया गया है. अगर एपीआई सही से जुड़ जाता है, तो जवाब का मुख्य हिस्सा खाली होता है. अनुमति हटाए जाने की पुष्टि करने के लिए, permissions
संसाधन पर fileId
पाथ पैरामीटर के साथ list()
तरीके का इस्तेमाल करें.
अनुरोध
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
पर ले जाया जाता है.
एक साथ कई अनुरोध करके, कई अनुमतियों में बदलाव करना
हमारा सुझाव है कि एक से ज़्यादा अनुमतियों में बदलाव करने के लिए, बैच अनुरोधों का इस्तेमाल करें.
क्लाइंट लाइब्रेरी की मदद से, बैच की अनुमति में बदलाव करने का एक उदाहरण नीचे दिया गया है.
Java
Python
Node.js
PHP
.NET
मिलते-जुलते विषय
- फ़ाइल के कॉन्टेंट को सुरक्षित रखना
- संसाधन कुंजियों का इस्तेमाल करके, लिंक से शेयर की गई Drive फ़ाइलों को ऐक्सेस करना
- भूमिकाएं और अनुमतियां