Partager des fichiers, des dossiers et des disques

Chaque fichier, dossier et Drive partagé Google Drive est associé à des ressources permissions. Chaque ressource identifie l'autorisation pour un type (user, group, domain, anyone) et un role (owner, organizer, fileOrganizer, writer, commenter, reader) spécifiques. Par exemple, un fichier peut avoir une autorisation accordant à un utilisateur spécifique (type=user) un accès en lecture seule (role=reader), tandis qu'une autre autorisation permet aux membres d'un groupe spécifique (type=group) d'ajouter des commentaires à un fichier (role=commenter).

Pour obtenir la liste complète des rôles et des opérations autorisées par chacun, consultez la page Rôles et autorisations.

Scénarios de partage de ressources Drive

Il existe cinq types de scénarios de partage différents :

  1. Pour partager un fichier dans Mon Drive, l'utilisateur doit disposer des droits role=writer ou role=owner.

  2. Pour partager un dossier dans Mon Drive, l'utilisateur doit disposer de role=writer ou role=owner.

    • Si la valeur booléenne writersCanShare est définie sur false pour le fichier, l'utilisateur doit disposer de l'role=owner plus permissive.

    • L'accès temporaire (régi par une date et une heure d'expiration) n'est pas autorisé sur les dossiers Mon Drive avec role=writer. Pour en savoir plus, consultez Définir une date d'expiration pour limiter l'accès aux fichiers.

  3. Pour partager un fichier dans un Drive partagé, l'utilisateur doit disposer des autorisations role=writer, role=fileOrganizer ou role=organizer.

    • Le paramètre writersCanShare ne s'applique pas aux éléments des Drive partagés. Elle est traitée comme si elle était toujours définie sur true.

  4. Pour partager un dossier dans un Drive partagé, l'utilisateur doit disposer de role=organizer.

    • Si la restriction sharingFoldersRequiresOrganizerPermission d'un Drive partagé est définie sur false, les utilisateurs disposant de role=fileOrganizer peuvent partager des dossiers dans ce Drive partagé.

  5. Pour gérer les membres des Drive partagés, l'utilisateur doit disposer de role=organizer. Seuls les utilisateurs et les groupes peuvent être membres de Drive partagés.

Définir une date d'expiration pour limiter l'accès aux fichiers

Lorsque vous travaillez avec des personnes sur un projet sensible, il peut être préférable de restreindre leur accès à certains fichiers dans Drive après un certain temps. Pour les fichiers dans le dossier Mon Drive, vous avez la possibilité de définir une date d'expiration afin d'en limiter l'accès ou d'y mettre fin.

Pour définir la date d'expiration :

Le champ expirationTime indique l'expiration de l'autorisation au moyen d'un horodatage RFC 3339. Les délais d'expiration sont soumis aux restrictions suivantes :

  • Ils ne peuvent être définis que sur les autorisations des utilisateurs et des groupes.
  • L'heure doit être située dans le futur.
  • La date ne peut pas être postérieure d'un an à plus tard.

Pour en savoir plus sur la date d'expiration, consultez les articles suivants :

Propagation des autorisations

Les listes d'autorisations d'un dossier se propagent vers le bas, et tous les fichiers et dossiers enfants héritent des autorisations du parent. Chaque fois que les autorisations ou la hiérarchie sont modifiées, la propagation est récursive dans tous les dossiers imbriqués. Par exemple, si un fichier existe dans un dossier et que ce dossier est ensuite déplacé dans un autre dossier, les autorisations sur le nouveau dossier se propagent au fichier. Si le nouveau dossier attribue un nouveau rôle à l'utilisateur du fichier, tel que "rédacteur", il remplace son ancien rôle.

À l'inverse, si un fichier hérite de role=writer à partir d'un dossier et est déplacé vers un autre dossier qui fournit un rôle de "lecteur", le fichier hérite désormais de role=reader.

Vous ne pouvez pas supprimer les autorisations héritées d'un fichier ou d'un dossier dans un Drive partagé. Au lieu de cela, ces autorisations doivent être ajustées sur le parent direct ou indirect dont elles ont été héritées. Vous pouvez supprimer les autorisations héritées des éléments dans "Mon Drive" ou "Partagés avec moi".

À l'inverse, les autorisations héritées peuvent être remplacées pour un fichier ou un dossier dans My Drive. Par conséquent, si un fichier hérite de role=writer à partir d'un dossier "Mon Drive", vous pouvez définir role=reader sur le fichier pour réduire son niveau d'autorisation.

Fonctionnalités

La ressource permissions ne détermine pas en définitive la capacité de l'utilisateur actuel à effectuer des actions sur un fichier ou un dossier. À la place, la ressource files contient une collection de champs booléens capabilities utilisés pour indiquer si une action peut être effectuée sur un fichier ou un dossier. L'API Google Drive définit ces champs en fonction de la ressource d'autorisations de l'utilisateur actuel associée au fichier ou au dossier.

Par exemple, lorsqu'Alex se connecte à votre application et tente de partager un fichier, les autorisations sur ce fichier sont vérifiées dans le rôle d'Alex. Si le rôle lui permet de partager un fichier, les capabilities associés au fichier, tels que canShare, sont renseignés par rapport au rôle. Si Alex souhaite partager le fichier, votre application vérifie capabilities pour s'assurer que canShare est défini sur true.

Pour obtenir un exemple de récupération du fichier capabilities, consultez la section Vérifier les autorisations utilisateur.

Créer une autorisation

Les deux champs suivants sont nécessaires lors de la création d'une autorisation :

  • type: type identifie le champ d'application de l'autorisation (user, group, domain ou anyone). Une autorisation avec type=user s'applique à un utilisateur spécifique, tandis qu'une autorisation avec type=domain s'applique à tous les membres d'un domaine spécifique.

  • role: le champ role identifie les opérations que le type peut effectuer. Par exemple, une autorisation avec type=user et role=reader accorde à un utilisateur spécifique un accès en lecture seule au fichier ou au dossier. Une autorisation avec type=domain et role=commenter permet à tous les membres du domaine d'ajouter des commentaires à un fichier. Pour obtenir la liste complète des rôles et des opérations autorisées par chacun d'eux, consultez la section Rôles et autorisations.

Lorsque vous créez une autorisation où type=user ou type=group, vous devez également fournir un emailAddress pour associer l'utilisateur ou le groupe spécifique à l'autorisation.

Lorsque vous créez une autorisation où type=domain, vous devez également fournir un domain pour lier un domaine spécifique à l'autorisation.

Pour créer une autorisation:

  1. Utilisez la méthode create() avec le paramètre de chemin fileId pour le fichier ou le dossier associé.
  2. Dans le corps de la requête, spécifiez type et role.
  3. Si la valeur est type=user ou type=group, fournissez un emailAddress. Si la valeur est type=domain, fournissez un domain.

Afficher un exemple

L'exemple de code suivant montre comment créer une autorisation. La réponse renvoie une instance d'une ressource Permission, avec le permissionId attribué.

Requête

POST https://www.googleapis.com/drive/v3/files/FILE_ID/permissions
 
{
  "requests": [
    {
        "type": "user",
        "role": "commenter",
        "emailAddress": "alex@altostrat.com"
    }
  ]
}

Response (Réponse)

{
    "kind": "drive#permission",
    "id": "PERMISSION_ID",
    "type": "user",
    "role": "commenter"
}

Utiliser des audiences cibles

Les audiences cibles sont des groupes de personnes, comme des services ou des équipes, que vous pouvez recommander aux utilisateurs ayant l'intention de partager des éléments. Vous pouvez encourager les utilisateurs à partager des éléments avec une audience spécifique ou restreinte plutôt que l'ensemble de votre organisation. Les audiences cibles peuvent vous aider à améliorer la sécurité et la confidentialité de vos données, et à faciliter le partage approprié par les utilisateurs. Pour en savoir plus, consultez la section À propos des audiences cibles.

Pour utiliser des audiences cibles :

  1. Dans la console d'administration Google, accédez à Menu  > Annuaire > Audiences cibles.

    Accéder aux audiences cibles

    Pour ce faire, vous devez être connecté avec un compte disposant de droits de super-administrateur.

  2. Dans la liste "Audiences cibles", cliquez sur le nom de l'audience cible. Pour créer une audience cible, consultez Créer une audience cible.

  3. Copiez l'ID unique à partir de l'URL de l'audience cible : https://admin.google.com/ac/targetaudiences/ID.

  4. Créez une autorisation avec type=domain, puis définissez le champ domain sur ID.audience.googledomains.com.

Pour savoir comment les utilisateurs interagissent avec les audiences cibles, consultez Expérience utilisateur pour le partage par lien.

Récupérer toutes les autorisations d'un fichier, d'un dossier ou d'un Drive partagé

Utilisez la méthode list() sur la ressource permissions pour récupérer toutes les autorisations d'un fichier, d'un dossier ou d'un Drive partagé.

Afficher un exemple

L'exemple de code suivant montre comment obtenir toutes les autorisations. La réponse renvoie une liste d'autorisations.

Requête

GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissions

Response (Réponse)

{
  "kind": "drive#permissionList",
  "permissions": [
    {
      "id": "PERMISSION_ID",
      "type": "user",
      "kind": "drive#permission",
      "role": "commenter"
    }
  ]
}

Vérifier les autorisations des utilisateurs

Lorsque votre application ouvre un fichier, elle doit en vérifier les fonctionnalités et afficher l'interface utilisateur pour refléter les autorisations de l'utilisateur actuel. Par exemple, si l'utilisateur ne dispose pas d'une fonctionnalité canComment sur le fichier, la possibilité de commenter doit être désactivée dans l'interface utilisateur.

Pour en savoir plus sur capabilities, consultez la section Fonctionnalités.

Pour vérifier les fonctionnalités, appelez la méthode get() sur la ressource files avec le paramètre de chemin fileId et le paramètre fields défini sur le champ capabilities. Pour en savoir plus sur le renvoi de champs à l'aide du paramètre fields, consultez Renvoyer des champs spécifiques pour un fichier.

Afficher un exemple

L'exemple de code suivant montre comment vérifier les autorisations des utilisateurs. La réponse renvoie la liste des fonctionnalités dont dispose l'utilisateur sur le fichier. Chaque capacité correspond à une action précise qu'un utilisateur peut effectuer. Certains champs ne sont renseignés que pour les éléments de Drive partagés.

Requête

GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=capabilities

Response (Réponse)

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

Déterminer la source de rôle pour les fichiers et dossiers de Drive partagé

Pour modifier le rôle d'un fichier ou d'un dossier, vous devez connaître la source du rôle. Pour les Drive partagés, la source d'un rôle peut être basée sur l'appartenance au Drive partagé, le rôle d'un dossier ou le rôle d'un fichier.

Pour déterminer la source de rôle d'un lecteur partagé ou d'éléments de ce lecteur, appelez la méthode get() sur la ressource permissions avec les paramètres de chemin fileId et permissionId, et le paramètre fields défini sur le champ permissionDetails.

Pour trouver le permissionId, utilisez la méthode list() sur la ressource permissions avec le paramètre de chemin fileId. Pour extraire le champ permissionDetails de la requête list, définissez le paramètre fields sur permissions/permissionDetails.

Ce champ énumère toutes les autorisations de fichiers héritées et directes pour l'utilisateur, le groupe ou le domaine.

Afficher un exemple

L'exemple de code suivant montre comment déterminer la source du rôle. La réponse renvoie le permissionDetails d'une ressource permissions. Le champ inheritedFrom fournit l'ID de l'élément à partir duquel l'autorisation est héritée.

Requête

GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID?fields=permissionDetails&supportsAllDrives=true

Response (Réponse)

{
  "permissionDetails": [
    {
      "permissionType": "member",
      "role": "commenter",
      "inheritedFrom": "INHERITED_FROM_ID",
      "inherited": true
    },
    {
      "permissionType": "file",
      "role": "writer",
      "inherited": false
    }
  ]
}

Modifier les autorisations

Pour modifier les autorisations d'un fichier ou d'un dossier, vous pouvez modifier le rôle attribué :

  1. Appelez la méthode update() sur la ressource permissions avec le paramètre de chemin permissionId défini sur l'autorisation à modifier et le paramètre de chemin fileId défini sur le fichier, le dossier ou le Drive partagé associé. Pour trouver le permissionId, utilisez la méthode list() sur la ressource permissions avec le paramètre de chemin fileId.

  2. Dans la requête, identifiez le nouvel role.

Vous pouvez accorder des autorisations sur des fichiers ou des dossiers individuels d'un Drive partagé, même si l'utilisateur ou le groupe en est déjà membre. Par exemple, Alex dispose de role=commenter en tant que membre d'un Drive partagé. Toutefois, votre application peut accorder à Alex role=writer pour un fichier dans un Drive partagé. Dans ce cas, comme le nouveau rôle est plus permissif que celui accordé par l'appartenance, la nouvelle autorisation devient le rôle effectif pour le fichier ou le dossier.

Afficher un exemple

L'exemple de code suivant montre comment modifier les autorisations d'un fichier ou d'un dossier de "commentateur" à "rédacteur". La réponse renvoie une instance d'une ressource permissions.

Requête

PATCH https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
 
{
  "requests": [
    {
        "role": "writer"
    }
  ]
}

Response (Réponse)

{
  "kind": "drive#permission",
  "id": "PERMISSION_ID",
  "type": "user",
  "role": "writer"
}

Lister et résoudre les propositions d'accès en attente

Une proposition d'accès est une proposition envoyée par un demandeur à un approbateur pour accorder à un destinataire l'accès à un élément Drive.

Un approbateur peut examiner et traiter toutes les propositions d'accès non résolues pour les fichiers Drive. Cela signifie que vous pouvez accélérer le processus d'approbation en interrogeant de manière automatisée les propositions d'accès, puis en les résolvant. Il permet également à un approbateur de consulter les propositions de manière globale.

L'API Drive fournit la ressource accessproposals qui vous permet d'afficher et de résoudre les propositions d'accès en attente. Les méthodes de la ressource accessproposals fonctionnent sur les fichiers, les dossiers et les fichiers d'un Drive partagé, mais pas sur le Drive partagé.

Les termes suivants sont spécifiques aux propositions d'accès :

  • Demandeur : utilisateur qui lance la proposition d'accès à un élément Drive.
  • Destinataire : utilisateur qui reçoit les autorisations supplémentaires sur un fichier si la proposition d'accès est accordée. Le destinataire est souvent identique au demandeur, mais ce n'est pas toujours le cas.
  • Approbateur: utilisateur chargé d'approuver (ou de refuser) la proposition d'accès. Cela est généralement dû au fait qu'ils sont propriétaires du document ou qu'ils ont la possibilité de le partager.

Répertorier les propositions d'accès en attente

Pour répertorier toutes les propositions d'accès en attente sur un élément Drive, appelez la méthode list() sur la ressource accessproposals et incluez le paramètre de chemin fileId.

Seuls les approbateurs d'un fichier peuvent en afficher les propositions en attente. Un approbateur est un utilisateur disposant de la fonctionnalité can_approve_access_proposals sur le fichier. Si le demandeur n'est pas un approbateur, une liste vide est renvoyée. Pour en savoir plus sur capabilities, consultez la section Fonctionnalités.

Le corps de la réponse consiste en un objet AccessProposal représentant une liste de propositions d'accès non résolues sur le fichier.

L'objet AccessProposal inclut des informations sur chaque proposition, telles que le demandeur, le destinataire et le message ajouté par le demandeur. Il comprend également un objet AccessProposalRoleAndView qui regroupe les role proposés par le demandeur avec un view. Étant donné que role est un champ répété, plusieurs valeurs peuvent exister pour chaque proposition. Par exemple, une proposition peut comporter un objet AccessProposalRoleAndView de role=reader et view=published, ainsi qu'un objet AccessProposalRoleAndView supplémentaire ne contenant que la valeur role=writer. Pour en savoir plus, consultez la section Vues.

Transmettez les paramètres de requête suivants pour personnaliser la pagination ou filtrer les propositions d'accès :

  • pageToken : jeton de page reçu d'un appel de liste précédent. Fournissez ce jeton pour récupérer la page suivante.

  • pageSize : nombre maximal de propositions d'accès à renvoyer par page.

Résoudre les propositions d'accès en attente

Pour résoudre toutes les propositions d'accès en attente sur un élément Drive, appelez la méthode resolve() sur la ressource accessproposals et incluez les paramètres de chemin d'accès fileId et proposalId.

La méthode resolve() inclut un paramètre de requête action qui indique l'action à effectuer sur la proposition. L'objet Action suit le changement d'état de la proposition afin que nous sachions si elle est acceptée ou refusée.

La méthode resolve() inclut également les paramètres de requête facultatifs de role et view. Les seuls rôles acceptés sont writer, commenter et reader. Si le rôle n'est pas spécifié, la valeur par défaut est reader. Un paramètre de requête facultatif supplémentaire de send_notification vous permet d'envoyer une notification par e-mail au demandeur lorsque la proposition est acceptée ou refusée.

Comme pour la méthode list(), les utilisateurs qui résolvent la proposition doivent disposer de la fonctionnalité can_approve_access_proposals sur le fichier. Pour en savoir plus sur capabilities, consultez la section Fonctionnalités.

Les propositions sont résolues à l'aide des mêmes modèles listés sous Scénarios de partage des ressources Drive. S'il existe plusieurs propositions pour le même utilisateur, mais avec des rôles différents, les conditions suivantes s'appliquent:

  • Si une proposition est acceptée et une autre refusée, le rôle accepté s'applique à l'élément Drive.
  • Si les deux propositions sont acceptées en même temps, la proposition avec l'autorisation la plus élevée (par exemple, role=writer par rapport à role=reader) est appliquée. L'autre proposition d'accès est supprimée de l'élément.

Une fois une proposition envoyée à la méthode resolve(), l'action de partage est terminée. Le AccessProposal n'est plus renvoyé via la méthode list(). Une fois la proposition acceptée, l'utilisateur doit utiliser la collection permissions pour mettre à jour les autorisations d'un fichier ou d'un dossier. Pour en savoir plus, consultez la section Modifier les autorisations.

Révoquer l'accès à un fichier ou à un dossier

Pour révoquer l'accès à un fichier ou à un dossier, appelez la méthode delete() sur la ressource permissions avec les paramètres de chemin fileId et permissionId définis pour supprimer l'autorisation.

Pour les éléments de "Mon Drive", vous pouvez supprimer une autorisation héritée. La suppression d'une autorisation héritée révoque l'accès à l'élément et aux éléments enfants, le cas échéant.

Pour les éléments d'un Drive partagé, les autorisations héritées ne peuvent pas être révoquées. Modifiez ou révoquez plutôt l'autorisation sur le fichier ou le dossier parent.

La méthode delete() permet également de supprimer les autorisations appliquées directement à un fichier ou à un dossier Drive partagé.

Afficher un exemple

L'exemple de code suivant montre comment révoquer l'accès en supprimant un permissionId. Si la requête aboutit, le corps de la réponse est vide. Pour vérifier que l'autorisation est supprimée, utilisez la méthode list() sur la ressource permissions avec le paramètre de chemin fileId.

Requête

DELETE https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID

Transférer la propriété d'un fichier vers un autre compte Google Workspace de la même organisation

Vous pouvez transférer la propriété des fichiers existants dans "Mon Drive" d'un compte Google Workspace à un autre compte de la même organisation. Une organisation propriétaire d'un Drive partagé est propriétaire des fichiers qu'il contient. Par conséquent, les transferts de propriété ne sont pas acceptés pour les fichiers et dossiers des Drive partagés. Les organisateurs d'un Drive partagé peuvent déplacer des éléments de ce Drive vers leur propre dossier "Mon Drive", ce qui leur en transfère la propriété.

Pour transférer la propriété d'un fichier dans "Mon Drive", procédez comme suit :

  • Créez une autorisation de fichier accordant un accès propriétaire (role=owner) à un utilisateur spécifique (type=user).

  • Mettez à jour l'autorisation d'un fichier existant avec role=owner et transférez la propriété à l'utilisateur spécifié (transferOwnership=true).

Transférer la propriété d'un fichier d'un compte personnel à un autre

Vous pouvez transférer la propriété de fichiers d'un compte client à un autre. Toutefois, Drive ne transfère pas la propriété d'un fichier entre les deux comptes personnels tant que le propriétaire potentiel n'accepte pas explicitement le transfert. Pour transférer la propriété d'un fichier d'un compte client à un autre:

  1. Le propriétaire actuel lance un transfert de propriété en créant ou en mettant à jour l'autorisation de fichier du propriétaire potentiel. L'autorisation doit inclure les paramètres suivants : role=writer, type=user et pendingOwner=true. Si le propriétaire actuel crée une autorisation pour le propriétaire potentiel, une notification par e-mail lui est envoyée pour l'informer qu'il est invité à devenir propriétaire du fichier.

  2. Le propriétaire potentiel accepte la demande de transfert de propriété en créant ou en mettant à jour son autorisation de fichier. L'autorisation doit inclure les paramètres role=owner et transferOwnership=true. Si le propriétaire potentiel crée une autorisation, une notification par e-mail est envoyée à l'ancien propriétaire pour l'informer que la propriété a été transférée.

Lorsqu'un fichier est transféré, le rôle de l'ancien propriétaire est rétrogradé à writer.

Modifier plusieurs autorisations avec des requêtes par lot

Nous vous recommandons vivement d'utiliser des requêtes groupées pour modifier plusieurs autorisations.

Voici un exemple de modification d'autorisation par lot avec une bibliothèque cliente.

Java

drive/snippets/drive_v3/src/main/java/ShareFile.java
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;
    }
  }
}

Python

drive/snippets/drive-v3/file_snippet/share_file.py
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",
  )

Node.js

drive/snippets/drive_v3/file_snippets/share_file.js
/**
 * 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;
}

PHP

drive/snippets/drive_v3/src/DriveShareFile.php
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;
    }

}

.NET

drive/snippets/drive_v3/DriveV3Snippets/ShareFile.cs
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;
        }
    }
}