फ़ाइलें, फ़ोल्डर, और ड्राइव शेयर करना

Google Drive की हर फ़ाइल, फ़ोल्डर, और शेयर की गई ड्राइव में, permissions संसाधन जुड़े होते हैं. हर संसाधन, किसी खास type (user, group, domain, anyone) और role (owner, organizer, fileOrganizer, writer, commenter, reader) के लिए अनुमति की पहचान करता है. उदाहरण के लिए, किसी फ़ाइल में किसी खास उपयोगकर्ता (type=user) को सिर्फ़ पढ़ने का ऐक्सेस (role=reader) देने वाली अनुमति हो सकती है. वहीं, दूसरी अनुमति किसी खास ग्रुप (type=group) के सदस्यों को फ़ाइल में टिप्पणियां जोड़ने की अनुमति (role=commenter) दे सकती है.

भूमिकाओं और हर भूमिका के लिए अनुमति वाली कार्रवाइयों की पूरी सूची के लिए, भूमिकाएं और अनुमतियां देखें.

Drive के संसाधनों को शेयर करने के उदाहरण

शेयर करने के पांच अलग-अलग तरीके हैं:

1. 'मेरी ड्राइव' में मौजूद किसी फ़ाइल को शेयर करने के लिए, उपयोगकर्ता के पास role=writer या role=owner होना चाहिए.

   • अगर फ़ाइल के लिए writersCanShare बूलियन वैल्यू को false पर सेट किया गया है, तो उपयोगकर्ता के पास role=owner होना चाहिए.

   • अगर role=writer का ऐक्सेस कुछ समय के लिए दिया गया है और उसके खत्म होने की तारीख और समय तय है, तो वह फ़ाइल शेयर नहीं कर सकता. ज़्यादा जानकारी के लिए, फ़ाइल का ऐक्सेस सीमित करने के लिए, ऐक्सेस खत्म होने की तारीख सेट करना लेख पढ़ें.

2. 'मेरी ड्राइव' में मौजूद किसी फ़ोल्डर को शेयर करने के लिए, उपयोगकर्ता के पास role=writer या role=owner होना चाहिए.

   • अगर फ़ाइल के लिए writersCanShare बूलियन वैल्यू को false पर सेट किया गया है, तो उपयोगकर्ता के पास ज़्यादा अनुमति वाली role=owner होनी चाहिए.

   • role=writer के 'मेरी ड्राइव' फ़ोल्डर के लिए, कुछ समय के लिए ऐक्सेस देने की अनुमति नहीं है. यह ऐक्सेस, ऐक्सेस खत्म होने की तारीख और समय के हिसाब से मिलता है. ज़्यादा जानकारी के लिए, फ़ाइल का ऐक्सेस सीमित करने के लिए, ऐक्सेस खत्म होने की तारीख सेट करना लेख पढ़ें.

3. शेयर की गई ड्राइव में कोई फ़ाइल शेयर करने के लिए, उपयोगकर्ता के पास role=writer, role=fileOrganizer या role=organizer होना चाहिए.

   • writersCanShare सेटिंग, शेयर की गई ड्राइव में मौजूद आइटम पर लागू नहीं होती. इसे इस तरह माना जाता है कि यह हमेशा true पर सेट है.

4. शेयर की गई ड्राइव में कोई फ़ोल्डर शेयर करने के लिए, उपयोगकर्ता के पास role=organizer होना चाहिए.

   • अगर शेयर की गई ड्राइव पर sharingFoldersRequiresOrganizerPermission पाबंदी को false पर सेट किया गया है, तो role=fileOrganizer ऐक्सेस वाले उपयोगकर्ता उस शेयर की गई ड्राइव में फ़ोल्डर शेयर कर सकते हैं.

5. शेयर की गई ड्राइव की सदस्यता मैनेज करने के लिए, उपयोगकर्ता के पास 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 भी देना होगा.

अनुमति बनाने के लिए:

1. उस फ़ाइल या फ़ोल्डर के लिए, fileId पाथ पैरामीटर के साथ create() तरीके का इस्तेमाल करें.
2. अनुरोध के मुख्य हिस्से में, type और role की वैल्यू डालें.
3. अगर type=user या type=group है, तो emailAddress डालें. अगर type=domain है, तो domain दें.

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"
}

टारगेट ऑडियंस का इस्तेमाल करना

टारगेट ऑडियंस, लोगों के ऐसे ग्रुप होते हैं जिनके साथ उपयोगकर्ता अपने आइटम शेयर कर सकते हैं. जैसे, डिपार्टमेंट या टीमें. उपयोगकर्ताओं को पूरे संगठन के बजाय, किसी खास या सीमित ऑडियंस के साथ आइटम शेयर करने के लिए कहा जा सकता है. टारगेट ऑडियंस की मदद से, अपने डेटा की सुरक्षा और निजता को बेहतर बनाया जा सकता है. साथ ही, उपयोगकर्ताओं के लिए डेटा को सही तरीके से शेयर करना आसान हो जाता है. ज़्यादा जानकारी के लिए, टारगेट ऑडियंस के बारे में जानकारी देखें.

टारगेट ऑडियंस का इस्तेमाल करने के लिए:

1. Google Admin console में, मेन्यू menu > डायरेक्ट्री > टारगेट ऑडियंस पर जाएं.

   टारगेट ऑडियंस पर जाएं

   ऐसा करने के लिए, आपको सुपर एडमिन के अधिकारों वाले खाते से साइन इन करना होगा.

2. टारगेट ऑडियंस की सूची में, टारगेट ऑडियंस के नाम पर क्लिक करें. टारगेट ऑडियंस बनाने के लिए, टारगेट ऑडियंस बनाना लेख पढ़ें

3. टारगेट ऑडियंस के यूआरएल से यूनीक आईडी कॉपी करें: https://admin.google.com/ac/targetaudiences/ID.

4. 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
  }
}

शेयर की गई ड्राइव की फ़ाइलों और फ़ोल्डर के लिए भूमिका का सोर्स तय करना

किसी फ़ाइल या फ़ोल्डर पर भूमिका बदलने के लिए, आपको भूमिका का सोर्स पता होना चाहिए. शेयर की गई ड्राइव के लिए, किसी भूमिका का सोर्स, शेयर की गई ड्राइव की सदस्यता, फ़ोल्डर में भूमिका या फ़ाइल में भूमिका पर आधारित हो सकता है.

शेयर की गई ड्राइव या उस ड्राइव में मौजूद आइटम के लिए भूमिका का सोर्स तय करने के लिए, fileId और permissionId पाथ पैरामीटर के साथ permissions संसाधन पर get() तरीके को कॉल करें. साथ ही, fields पैरामीटर को permissionDetails फ़ील्ड पर सेट करें.

permissionId ढूंढने के लिए, fileId पाथ पैरामीटर के साथ permissions संसाधन पर list() तरीके का इस्तेमाल करें. list अनुरोध पर permissionDetails फ़ील्ड को फ़ेच करने के लिए, fields पैरामीटर को permissions/permissionDetails पर सेट करें.

इस फ़ील्ड में, उपयोगकर्ता, ग्रुप या डोमेन के लिए, फ़ाइल की सभी इनहेरिट की गई और सीधे तौर पर मिली अनुमतियां शामिल होती हैं.

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
    }
  ]
}

अनुमतियां बदलें

किसी फ़ाइल या फ़ोल्डर की अनुमतियां बदलने के लिए, असाइन की गई भूमिका बदली जा सकती है:

1. permissions संसाधन पर update() तरीके को कॉल करें. इसके लिए, permissionId पाथ पैरामीटर को बदलाव करने की अनुमति पर सेट करें और fileId पाथ पैरामीटर को उससे जुड़ी फ़ाइल, फ़ोल्डर या शेयर की गई ड्राइव पर सेट करें. permissionId ढूंढने के लिए, fileId पाथ पैरामीटर के साथ permissions संसाधन पर list() तरीके का इस्तेमाल करें.

2. अनुरोध में, नए role की पहचान करें.

शेयर की गई ड्राइव में मौजूद अलग-अलग फ़ाइलों या फ़ोल्डर के लिए अनुमतियां दी जा सकती हैं. भले ही, उपयोगकर्ता या ग्रुप पहले से ही सदस्य हो. उदाहरण के लिए, ऐलेक्स के पास role=commenter है, जो शेयर की गई ड्राइव की सदस्यता का हिस्सा है. हालांकि, आपका ऐप्लिकेशन, शेयर की गई ड्राइव में मौजूद किसी फ़ाइल के लिए, ऐलेक्स को role=writer ऐक्सेस दे सकता है. इस मामले में, सदस्यता के ज़रिए मिली भूमिका के मुकाबले नई भूमिका में ज़्यादा अनुमतियां होती हैं. इसलिए, फ़ाइल या फ़ोल्डर के लिए नई अनुमति, असल भूमिका बन जाती है.

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 फ़ाइल या फ़ोल्डर पर सीधे लागू की गई अनुमतियों को मिटाने के लिए भी किया जाता है.

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 किसी फ़ाइल का मालिकाना हक, दो उपभोक्ता खातों के बीच तब तक ट्रांसफ़र नहीं करता, जब तक कि संभावित मालिक साफ़ तौर पर ट्रांसफ़र की सहमति न दे. किसी फ़ाइल का मालिकाना हक, एक उपभोक्ता खाते से दूसरे में ट्रांसफ़र करने के लिए:

1. मौजूदा मालिक, फ़ाइल के संभावित मालिक के लिए अनुमति बनाकर या अपडेट करके, मालिकाना हक ट्रांसफ़र की प्रोसेस शुरू करता है. अनुमति में ये सेटिंग शामिल होनी चाहिए: role=writer, type=user, और pendingOwner=true. अगर मौजूदा मालिक, संभावित मालिक के लिए अनुमति बना रहा है, तो संभावित मालिक को ईमेल से सूचना भेजी जाती है. इसमें बताया जाता है कि उसे फ़ाइल का मालिकाना हक पाने के लिए कहा गया है.

2. फ़ाइल का मालिकाना हक पाने वाला व्यक्ति, फ़ाइल के लिए अनुमति बनाकर या अपडेट करके, मालिकाना हक ट्रांसफ़र करने का अनुरोध स्वीकार करता है. अनुमति में ये सेटिंग शामिल होनी चाहिए: role=owner और transferOwnership=true. अगर नया मालिक नई अनुमति बना रहा है, तो पिछले मालिक को ईमेल से सूचना भेजी जाती है. इसमें बताया जाता है कि मालिकाना हक ट्रांसफ़र कर दिया गया है.

किसी फ़ाइल का मालिकाना हक ट्रांसफ़र करने पर, पिछले मालिक की भूमिका को writer पर ले जाया जाता है.

एक साथ कई अनुरोधों की मदद से, कई अनुमतियों में बदलाव करना

हमारा सुझाव है कि एक से ज़्यादा अनुमतियों में बदलाव करने के लिए, एक साथ कई अनुरोध का इस्तेमाल करें.

यहां क्लाइंट लाइब्रेरी की मदद से, अनुमति में एक साथ कई बदलाव करने का उदाहरण दिया गया है.

import com.google.api.client.googleapis.batch.BatchRequest;
import com.google.api.client.googleapis.batch.json.JsonBatchCallback;
import com.google.api.client.googleapis.json.GoogleJsonError;
import com.google.api.client.googleapis.json.GoogleJsonResponseException;
import com.google.api.client.http.HttpHeaders;
import com.google.api.client.http.HttpRequestInitializer;
import com.google.api.client.http.javanet.NetHttpTransport;
import com.google.api.client.json.gson.GsonFactory;
import com.google.api.services.drive.Drive;
import com.google.api.services.drive.DriveScopes;
import com.google.api.services.drive.model.Permission;
import com.google.auth.http.HttpCredentialsAdapter;
import com.google.auth.oauth2.GoogleCredentials;
import java.io.IOException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

/* Class to demonstrate use-case of modify permissions. */
public class ShareFile {

  /**
   * Batch permission modification.
   * realFileId file Id.
   * realUser User Id.
   * realDomain Domain of the user ID.
   *
   * @return list of modified permissions if successful, {@code null} otherwise.
   * @throws IOException if service account credentials file not found.
   */
  public static List<String> shareFile(String realFileId, String realUser, String realDomain)
      throws IOException {
        /* Load pre-authorized user credentials from the environment.
         TODO(developer) - See https://developers.google.com/identity for
         guides on implementing OAuth2 for your application.application*/
    GoogleCredentials credentials = GoogleCredentials.getApplicationDefault()
        .createScoped(Arrays.asList(DriveScopes.DRIVE_FILE));
    HttpRequestInitializer requestInitializer = new HttpCredentialsAdapter(
        credentials);

    // Build a new authorized API client service.
    Drive service = new Drive.Builder(new NetHttpTransport(),
        GsonFactory.getDefaultInstance(),
        requestInitializer)
        .setApplicationName("Drive samples")
        .build();

    final List<String> ids = new ArrayList<String>();


    JsonBatchCallback<Permission> callback = new JsonBatchCallback<Permission>() {
      @Override
      public void onFailure(GoogleJsonError e,
                            HttpHeaders responseHeaders)
          throws IOException {
        // Handle error
        System.err.println(e.getMessage());
      }

      @Override
      public void onSuccess(Permission permission,
                            HttpHeaders responseHeaders)
          throws IOException {
        System.out.println("Permission ID: " + permission.getId());

        ids.add(permission.getId());

      }
    };
    BatchRequest batch = service.batch();
    Permission userPermission = new Permission()
        .setType("user")
        .setRole("writer");

    userPermission.setEmailAddress(realUser);
    try {
      service.permissions().create(realFileId, userPermission)
          .setFields("id")
          .queue(batch, callback);

      Permission domainPermission = new Permission()
          .setType("domain")
          .setRole("reader");

      domainPermission.setDomain(realDomain);

      service.permissions().create(realFileId, domainPermission)
          .setFields("id")
          .queue(batch, callback);

      batch.execute();

      return ids;
    } catch (GoogleJsonResponseException e) {
      // TODO(developer) - handle error appropriately
      System.err.println("Unable to modify permission: " + e.getDetails());
      throw e;
    }
  }
}

import google.auth
from googleapiclient.discovery import build
from googleapiclient.errors import HttpError


def share_file(real_file_id, real_user, real_domain):
  """Batch permission modification.
  Args:
      real_file_id: file Id
      real_user: User ID
      real_domain: Domain of the user ID
  Prints modified permissions

  Load pre-authorized user credentials from the environment.
  TODO(developer) - See https://developers.google.com/identity
  for guides on implementing OAuth2 for the application.
  """
  creds, _ = google.auth.default()

  try:
    # create drive api client
    service = build("drive", "v3", credentials=creds)
    ids = []
    file_id = real_file_id

    def callback(request_id, response, exception):
      if exception:
        # Handle error
        print(exception)
      else:
        print(f"Request_Id: {request_id}")
        print(f'Permission Id: {response.get("id")}')
        ids.append(response.get("id"))

    # pylint: disable=maybe-no-member
    batch = service.new_batch_http_request(callback=callback)
    user_permission = {
        "type": "user",
        "role": "writer",
        "emailAddress": "user@example.com",
    }
    batch.add(
        service.permissions().create(
            fileId=file_id,
            body=user_permission,
            fields="id",
        )
    )
    domain_permission = {
        "type": "domain",
        "role": "reader",
        "domain": "example.com",
    }
    domain_permission["domain"] = real_domain
    batch.add(
        service.permissions().create(
            fileId=file_id,
            body=domain_permission,
            fields="id",
        )
    )
    batch.execute()

  except HttpError as error:
    print(f"An error occurred: {error}")
    ids = None

  return ids


if __name__ == "__main__":
  share_file(
      real_file_id="1dUiRSoAQKkM3a4nTPeNQWgiuau1KdQ_l",
      real_user="gduser1@workspacesamples.dev",
      real_domain="workspacesamples.dev",
  )

/**
 * Batch permission modification
 * @param{string} fileId file ID
 * @param{string} targetUserEmail username
 * @param{string} targetDomainName domain
 * @return{list} permission id
 * */
async function shareFile(fileId, targetUserEmail, targetDomainName) {
  const {GoogleAuth} = require('google-auth-library');
  const {google} = require('googleapis');

  // Get credentials and build service
  // TODO (developer) - Use appropriate auth mechanism for your app
  const auth = new GoogleAuth({
    scopes: 'https://www.googleapis.com/auth/drive',
  });
  const service = google.drive({version: 'v3', auth});
  const permissionIds = [];

  const permissions = [
    {
      type: 'user',
      role: 'writer',
      emailAddress: targetUserEmail, // 'user@partner.com',
    },
    {
      type: 'domain',
      role: 'writer',
      domain: targetDomainName, // 'example.com',
    },
  ];
  // Note: Client library does not currently support HTTP batch
  // requests. When possible, use batched requests when inserting
  // multiple permissions on the same item. For this sample,
  // permissions are inserted serially.
  for (const permission of permissions) {
    try {
      const result = await service.permissions.create({
        resource: permission,
        fileId: fileId,
        fields: 'id',
      });
      permissionIds.push(result.data.id);
      console.log(`Inserted permission id: ${result.data.id}`);
    } catch (err) {
      // TODO(developer): Handle failed permissions
      console.error(err);
    }
  }
  return permissionIds;
}

use Google\Client;
use Google\Service\Drive;
function shareFile()
{
    try {
        $client = new Client();
        $client->useApplicationDefaultCredentials();
        $client->addScope(Drive::DRIVE);
        $driveService = new Drive($client);
        $realFileId = readline("Enter File Id: ");
        $realUser = readline("Enter user email address: ");
        $realDomain = readline("Enter domain name: ");
        $ids = array();
            $fileId = '1sTWaJ_j7PkjzaBWtNc3IzovK5hQf21FbOw9yLeeLPNQ';
            $fileId = $realFileId;
            $driveService->getClient()->setUseBatch(true);
            try {
                $batch = $driveService->createBatch();

                $userPermission = new Drive\Permission(array(
                    'type' => 'user',
                    'role' => 'writer',
                    'emailAddress' => 'user@example.com'
                ));
                $userPermission['emailAddress'] = $realUser;
                $request = $driveService->permissions->create(
                    $fileId, $userPermission, array('fields' => 'id'));
                $batch->add($request, 'user');
                $domainPermission = new Drive\Permission(array(
                    'type' => 'domain',
                    'role' => 'reader',
                    'domain' => 'example.com'
                ));
                $userPermission['domain'] = $realDomain;
                $request = $driveService->permissions->create(
                    $fileId, $domainPermission, array('fields' => 'id'));
                $batch->add($request, 'domain');
                $results = $batch->execute();

                foreach ($results as $result) {
                    if ($result instanceof Google_Service_Exception) {
                        // Handle error
                        printf($result);
                    } else {
                        printf("Permission ID: %s\n", $result->id);
                        array_push($ids, $result->id);
                    }
                }
            } finally {
                $driveService->getClient()->setUseBatch(false);
            }
            return $ids;
    } catch(Exception $e) {
        echo "Error Message: ".$e;
    }

}

using Google.Apis.Auth.OAuth2;
using Google.Apis.Drive.v3;
using Google.Apis.Drive.v3.Data;
using Google.Apis.Requests;
using Google.Apis.Services;

namespace DriveV3Snippets
{
    // Class to demonstrate use-case of Drive modify permissions.
    public class ShareFile
    {
        /// <summary>
        /// Batch permission modification.
        /// </summary>
        /// <param name="realFileId">File id.</param>
        /// <param name="realUser">User id.</param>
        /// <param name="realDomain">Domain id.</param>
        /// <returns>list of modified permissions, null otherwise.</returns>
        public static IList<String> DriveShareFile(string realFileId, string realUser, string realDomain)
        {
            try
            {
                /* Load pre-authorized user credentials from the environment.
                 TODO(developer) - See https://developers.google.com/identity for
                 guides on implementing OAuth2 for your application. */
                GoogleCredential credential = GoogleCredential.GetApplicationDefault()
                    .CreateScoped(DriveService.Scope.Drive);

                // Create Drive API service.
                var service = new DriveService(new BaseClientService.Initializer
                {
                    HttpClientInitializer = credential,
                    ApplicationName = "Drive API Snippets"
                });

                var ids = new List<String>();
                var batch = new BatchRequest(service);
                BatchRequest.OnResponse<Permission> callback = delegate(
                    Permission permission,
                    RequestError error,
                    int index,
                    HttpResponseMessage message)
                {
                    if (error != null)
                    {
                        // Handle error
                        Console.WriteLine(error.Message);
                    }
                    else
                    {
                        Console.WriteLine("Permission ID: " + permission.Id);
                    }
                };
                Permission userPermission = new Permission()
                {
                    Type = "user",
                    Role = "writer",
                    EmailAddress = realUser
                };

                var request = service.Permissions.Create(userPermission, realFileId);
                request.Fields = "id";
                batch.Queue(request, callback);

                Permission domainPermission = new Permission()
                {
                    Type = "domain",
                    Role = "reader",
                    Domain = realDomain
                };
                request = service.Permissions.Create(domainPermission, realFileId);
                request.Fields = "id";
                batch.Queue(request, callback);
                var task = batch.ExecuteAsync();
                task.Wait();
                return ids;
            }
            catch (Exception e)
            {
                // TODO(developer) - handle error appropriately
                if (e is AggregateException)
                {
                    Console.WriteLine("Credential Not found");
                }
                else
                {
                    throw;
                }
            }
            return null;
        }
    }
}

मिलते-जुलते विषय

• फ़ाइल के कॉन्टेंट को सुरक्षित करना
• रिसॉर्स कुंजियों का इस्तेमाल करके, लिंक की गई Drive फ़ाइलों को ऐक्सेस करना
• भूमिकाएं और अनुमतियां