En autorisant les utilisateurs à envoyer des accords à partir de plusieurs groupes, les administrateurs peuvent lier fortement les modèles de bibliothèque, l’authentification des destinataires et les exigences de signature à un groupe, permettant ainsi au workflow de définir la nature du groupe plutôt que les utilisateurs qui y sont associés.
Lors de la création d’un accord, ce sont les paramètres au niveau du groupe qui déterminent en grande partie les actifs disponibles (modèles/workflows) et les propriétés de l’accord infligées par le système (branding, rôles des destinataires, méthodes d’authentification, sécurité/rétention des PDF, etc.).
Tout ID utilisateur individuel verrouillé dans un groupe est également verrouillé dans un ensemble de paramètres par défaut, dans un ensemble de modèles et de workflows, ainsi que dans un concept de conformité à la signature.
Le fait de permettre aux utilisateurs d’accéder à plusieurs groupes donne aux administrateurs la possibilité d’envisager les groupes comme bien plus qu’un ensemble d’utilisateurs. Les groupes peuvent ainsi être considérés comme un environnement encadré par des exigences spécifiques de signature des documents auxquels vous accordez l’accès aux utilisateurs.
Par exemple, un groupe peut être conçu autour d’un ensemble de règles de signature et de distribution très strictes liées à la conformité, alors qu’un autre peut l’être autour de workflows et de modèles internes d’authentification faible. Les utilisateurs affectés aux deux groupes pourront accéder à toutes les ressources de chaque groupe.
Les administrateurs de groupe ont également la possibilité de gérer plusieurs groupes, ce qui améliore l’exploitabilité de leur rôle.
Ce document met en évidence les modifications apportées par la fonctionnalité « Utilisateurs dans plusieurs groupes » à l’interface et aux fonctions dédiées aux utilisateurs. Il identifie en outre les conséquences pour les administrateurs de la migration vers la fonctionnalité « Utilisateurs dans plusieurs groupes ».
Tous les utilisateurs soumis aux règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes se voient attribuer un « groupe principal ». Le groupe principal est :
Objets et héritage (objets parent-enfant)
« Objet » désigne un ensemble de propriétés représentant une idée. Votre compte est un type d’objet, tout comme votre utilisateur.
Dans les applications telles qu’Acrobat Sign, les objets peuvent être utilisés comme modèles pour créer d’autres objets. Lorsqu’un objet est construit à partir d’un objet « modèle », les deux objets ont une relation parent-enfant.
L’objet enfant étant une copie directe du parent, leurs paramètres sont identiques. L’objet enfant hérite des valeurs des propriétés de son parent. Si une valeur parent est modifiée, la modification est répercutée sur l’enfant.
Dans Acrobat Sign, une arborescence d’objets désigne le groupe de propriétés Compte > Groupe > Utilisateur.
Observez la chaîne d’objets Compte > Groupe > Utilisateur afin de comprendre facilement comment le déplacement d’un utilisateur vers un nouveau groupe modifie la fonctionnalité « par défaut » de l’utilisateur en raison des nouveaux paramètres hérités du groupe.
La modification d’une valeur de propriété d’un objet enfant est autorisée. Cette modification explicite rompt généralement l’héritage de cette valeur de propriété de l’objet parent. Si l’objet parent modifie la valeur d’une telle propriété, l’enfant n’hérite pas de la nouvelle valeur, car la valeur explicitement définie est prioritaire.
Vous remarquerez cela notamment lorsque les administrateurs de groupe remplacent les paramètres de compte de leur groupe. Ainsi, comme les utilisateurs du groupe sont des objets enfants du groupe dans lequel ils se trouvent, l’expérience utilisateur s’en trouve modifiée.
Les utilisateurs qui ont accès à plusieurs groupes modifient leurs propriétés héritées lorsqu’ils modifient le groupe à partir duquel ils agissent. Vous remarquerez que lorsqu’un utilisateur modifie son groupe sur la page Envoyer, la page est actualisée à mesure que les nouvelles propriétés de groupe sont chargées. Vous remarquerez cela si vous avez un logo pour chaque groupe.
Objet ID
Chaque objet possède un numéro d’identification unique. Cet ID unique permet à l’application de différencier les objets d’un type similaire et de les relier les uns aux autres.
L’utilité des ID utilisateur et des ID de groupe devient plus évidente avec les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes, en particulier en ce qui concerne le reporting. Lorsqu’un utilisateur crée un actif dans le système (accord, modèle, formulaire web), l’ID utilisateur du créateur et l’ID de groupe dans lequel l’actif a été créé sont codés dans l’actif.
Lorsqu’un utilisateur exécute un rapport sur ses accords, l’application renvoie les données associées à son ID utilisateur. L’ID de groupe n’est pas pertinent pour la recherche (sauf si un filtre est appliqué).
Toutefois, lorsqu’un administrateur de groupe exécute le rapport d’un groupe, l’application renvoie les données se rapportant à l’ID de groupe (quel que soit l’ID utilisateur qui l’a créé)
Si les utilisateurs ne sont présents que dans un seul groupe, il n’y a généralement aucune différence à observer. En revanche, lorsque des utilisateurs créent des actifs dans plusieurs groupes, il est possible que le contenu d’un utilisateur puisse s’étendre aux groupes de plusieurs administrateurs de groupe.
Les administrateurs de groupe peuvent uniquement accéder au contenu généré dans les ID de groupe qu’ils gèrent (à l’exception du contenu qu’ils créent personnellement). Si un administrateur de groupe signale le contenu d’un ID utilisateur, le jeu de données renvoyé inclut uniquement le contenu (créé par l’ID utilisateur) dans le ou les groupes qu’il administre.
Les accords, les formulaires web et les événements Envoyer en masse créés avant l’activation de la fonctionnalité Utilisateurs dans plusieurs groupes sont uniquement liés à l’ID d’utilisateur de création.
Les accords, les formulaires web et les événements Envoyer en masse créés après l’activation de la fonctionnalité Utilisateurs dans plusieurs groupes sont liés à l’ID de groupe dans lequel ils ont été créés en plus de l’ID d’utilisateur qui les a créés.
En pratique, cela signifie que les actifs créés avant l’activation de la fonctionnalité Utilisateurs dans plusieurs groupes sont déplacés avec l’utilisateur si vous modifiez le groupe principal de celui-ci. Les utilisateurs qui consultent le groupe (via le partage de compte) ne voient plus ces actifs lorsque l’utilisateur est déplacé hors du groupe partagé.
Les actifs créés après l’activation de la fonctionnalité Utilisateurs dans plusieurs groupes restent liés au groupe. Les utilisateurs qui consultent le groupe continuent de voir les actifs créés dans celui-ci après le déplacement de l’utilisateur créateur vers un nouveau groupe principal.
L’activation ou la désactivation de la fonctionnalité Utilisateurs dans plusieurs groupes peut uniquement être effectuée par l’intermédiaire d’un administrateur de compte. Reportez-vous à cet article pour connaître les instructions à suivre pour mettre à niveau votre compte.
Il est possible d’annuler l’activation de la fonctionnalité Utilisateurs dans plusieurs groupes avec les effets notables ci-dessous :
Un utilisateur peut appartenir à 100 groupes maximum.
Les changements au niveau de l’utilisateur sont omniprésents. Tous les utilisateurs qui peuvent se connecter à Acrobat Sign constateront les modifications ci-dessous :
Différences :
Le profil de l’utilisateur affiche entièrement tous les groupes dans lesquels l’utilisateur est inclus et indique spécifiquement le groupe principal.
Si la fonctionnalité Utilisateurs dans plusieurs groupes est activée :
Différences :
Étant donné que l’utilisateur a accès à plusieurs groupes, les modèles et les workflows disponibles sont associés selon le groupe auquel le modèle/workflow est associé.
Si vous utilisez un modèle au niveau du groupe, le groupe est inséré sur la page Envoyer et l’option de modification du groupe est supprimée :
Si vous utilisez un modèle au niveau du compte, le groupe peut être sélectionné (parmi les groupes dont l’utilisateur est membre) :
Différences :
La page Envoyer affiche un sélecteur déroulant en haut de la page, Envoyer à partir de.
Ce sélecteur permet à l’expéditeur de sélectionner le groupe (et toutes les propriétés associées au niveau du groupe) qui régit les propriétés et les options de la transaction.
Éléments à prendre en compte :
Définissez le sélecteur Envoyer à partir de en premier.
Différences :
Tout comme la page Envoyer, la page Signature automatique introduit un sélecteur déroulant dans sa partie supérieure : Sélectionner un groupe.
Ce sélecteur permet à l’expéditeur de sélectionner le groupe (et toutes les propriétés associées au niveau du groupe) qui régit les propriétés et les options de la transaction.
Éléments à prendre en compte :
Définissez le sélecteur Envoyer avec en premier.
Différences :
Un libellé d’identification a été ajouté au menu contextuel de l’accord pour indiquer le groupe à partir duquel l’accord a été envoyé.
Éléments à prendre en compte :
Certaines fonctions sont fortement liées au groupe, comme par exemple les paramètres de reporting et les règles de rétention.
Différences :
Une colonne a été ajoutée à la table des accords affichée sur la page Gérer.
Différences :
Un nouveau filtre permet de filtrer le jeu de données de la page Gérer par Groupe
Différences :
Lors de la création d’un modèle de bibliothèque, l’auteur a la possibilité de définir les propriétés d’accès au modèle et de partager l’accord avec n’importe quel groupe dont il est membre.
Éléments à prendre en compte :
Un utilisateur ayant accès à tous les groupes peut être utilisé comme administrateur de document central.
Un utilisateur habilité à créer des formulaires web peut associer son formulaire à n’importe quel groupe dont il est membre.
Différences :
Un filtre a été ajouté à la page Rapports pour permettre de limiter les rapports aux accords associés à un ou plusieurs groupes.
Le rapport .csv est toujours pourvu de la même colonne Groupe d’expéditeurs, qui permet d’effectuer un suivi lorsqu’un expéditeur bascule entre les groupes :
Si un utilisateur est retiré d’un groupe à partir duquel il a précédemment envoyé des accords, il ne pourra pas déclarer ces transactions.
Ces modifications d’interface ne sont observables que par les administrateurs de compte (autorisés par les commandes d’administration au niveau du compte) :
Le rôle de l’administrateur de groupe est considérablement amélioré, en ce qu’un utilisateur peut à présent être administrateur de plusieurs groupes. Par ailleurs, il n’est pas tenu d’être l’administrateur de tous les groupes dont il est membre.
Les administrateurs de plusieurs groupes peuvent mieux gérer les documents et les workflows pour des équipes plus larges et signaler le contenu de plusieurs groupes, sans avoir accès à l’ensemble des données du compte.
Différences :
Si l’utilisateur est administrateur de plusieurs groupes, les Workflows et les Bibliothèques partagées sont déplacés du niveau supérieur des options de menu de l’administrateur du groupe vers les sous-menus de chaque groupe particulier :
Lorsque la fonctionnalité Utilisateurs dans plusieurs groupes est activée, vous devez d’abord sélectionner le groupe et ouvrir les paramètres du groupe pour accéder aux options et paramètres de menu spécifiques au groupe :
Différences :
Lorsqu’un administrateur de groupe dispose d’une autorité administrative sur plusieurs groupes, il doit d’abord sélectionner le groupe qu’il souhaite configurer :
Différences :
L’administrateur de groupe n’a plus la possibilité de forcer l’affichage des accords pour les utilisateurs nouvellement créés.
Différences :
Pour ajouter un utilisateur à votre compte, vous devez d’abord sélectionner un groupe pour accéder à l’option de menu Utilisateurs dans le groupe
Lors de la création d’utilisateurs individuels, le groupe sélectionné définit le groupe principal de l’utilisateur.
Les administrateurs de groupe n’ont pas le droit de modifier le groupe principal une fois l’utilisateur créé.
Le processus de création d’un utilisateur unique est le même, sans l’option permettant de forcer un partage d’affichage des accords de l’utilisateur (voir ci-dessus).
Éléments à prendre en compte :
La création d’utilisateurs individuels ne permet pas d’inclure l’utilisateur dans plusieurs groupes dans le cadre du processus de création.
Une fois l’utilisateur créé, l’administrateur de groupe peut modifier le profil utilisateur de sorte à inclure l’utilisateur dans d’autres groupes et modifier son autorité d’envoi.
Différences :
Les droits permettant de déterminer si un ID utilisateur peut signer des accords et la possibilité d’installer une règle de délégation automatique pour un ID utilisateur ont été supprimés de l’interface d’administration au niveau du groupe.
Les administrateurs de groupe ont le droit d’autoriser ou de refuser l’appartenance d’un utilisateur à chaque groupe qu’ils gèrent via son profil.
Pour ajouter une appartenance à un groupe :
Les utilisateurs nouvellement placés dans un groupe adoptent deux valeurs d’autorité :
Cochez/décochez les valeurs par groupe si nécessaire
Les administrateurs de groupe n’ont pas le droit de modifier le groupe principal d’un ID d’utilisateur, à moins qu’ils ne disposent de l’autorité administrative dans les deux groupes, à savoir le groupe principal et le nouveau groupe.
Pour supprimer un utilisateur d’une appartenance à un groupe :
Si l’appartenance d’un utilisateur est révoquée pour tous les groupes :
Les administrateurs de groupe qui créent des webhooks peuvent sélectionner n’importe quel groupe dont ils sont administrateurs lors de la définition de la valeur du champ Groupe :
Différences :
Le format du fichier .csv chargé utilisé pour créer/mettre à jour plusieurs utilisateurs a été modifié pour s’adapter aux utilisateurs inclus dans plusieurs groupes et à l’autorité spécifique au groupe. À cette fin, trois colonnes ont été supprimées dans la fonctionnalité Utilisateurs dans plusieurs groupes :
Une colonne a été ajoutée : Groupes
Les administrateurs de groupe ne peuvent pas manipuler les utilisateurs avec la colonne Groupes.
Lorsqu’un administrateur de groupe crée de nouveaux utilisateurs par le biais d’un chargement par lot :
Le contenu ci-dessous est fourni à des fins de sensibilisation, le modèle de téléchargement incluant la colonne Groupes.
La colonne Groupes contient une ou plusieurs Définitions de groupe. Chaque définition de groupe contient le nom d’un groupe, suivi d’une ou plusieurs valeurs d’état entre crochets. Exemple : Nom du groupe[État]
Dans l’exemple ci-dessus :
Différences :
L’action de désactivation d’un ID utilisateur a été limitée pour les administrateurs de groupe afin de s’assurer qu’ils ne désactivent pas les utilisateurs dans les groupes où ils n’ont aucune autorité.
Les administrateurs de groupe peuvent uniquement désactiver les utilisateurs n’appartenant qu’à un seul de leurs groupes et/ou au groupe par défaut.
Seuls les administrateurs de compte ont accès aux éléments ci-dessous :
Différences :
Dans le processus de création d’un utilisateur individuel, le champ Groupe d’utilisateurs a été renommé Groupe principal
Différences :
Comme indiqué dans la section consacrée à l’administration au niveau du groupe, le format du fichier .csv chargé utilisé pour créer/mettre à jour plusieurs utilisateurs a été modifié pour s’adapter aux utilisateurs inclus dans plusieurs groupes et à l’autorité spécifique au groupe. À cette fin, trois colonnes ont été supprimées dans la fonctionnalité Utilisateurs dans plusieurs groupes :
Une colonne a été ajoutée : Groupes
La colonne Groupes contient une ou plusieurs Définitions de groupe. Chaque définition de groupe contient le nom d’un groupe, suivi d’une ou plusieurs valeurs d’état entre crochets. Exemple : Nom du groupe[État]
Dans l’exemple ci-dessus :
Différences :
L’autorité accordée aux administrateurs de groupe (par les administrateurs de compte) a ajouté de la granularité à la fonctionnalité Utilisateurs dans plusieurs groupes.
La capacité précédente d’« ajouter de nouveaux utilisateurs aux groupes » a été divisée en deux options :
Les outils d’administration au niveau de la confidentialité ne sont actuellement pas modifiés par les paramètres de la fonctionnalité Utilisateurs dans plusieurs groupes.
Seule la version 6 de l’API REST sera mise à jour afin de tenir compte de la fonctionnalité Utilisateurs dans plusieurs groupes.
L’API SOAP héritée ne sera pas mise à jour.
L’API SOAP et la version 5 de l’API REST (et des versions antérieures) fonctionneront sans tenir compte de la fonctionnalité Utilisateurs dans plusieurs groupes. Le groupe principal de l’utilisateur sera utilisé.
Les points d’entrée de l’API REST v6 exécutés dans le contexte d’un groupe spécifique ont été développés pour inclure un identificateur ID de groupe facultatif pouvant être transmis à une requête en tant que paramètre de requête, en-tête ou partie du corps de la requête.
Ce paramètre est facultatif. S’il est omis, le code prend par défaut la valeur du groupe principal de l’utilisateur.
Les actions propres aux groupes se répartissent en deux catégories :
Le changement dans la gestion des utilisateurs est lié à la capacité à gérer plusieurs appartenances à un groupe dans un appel d’API, ainsi qu’à l’extension du modèle de sécurité affectant les capacités de l’administrateur de groupe. En effet, l’administrateur de groupe ne doit pas pouvoir effectuer de changements dans un groupe sur lequel il n’a pas l’autorité.
La modification des opérations de ressources correspond au paramètre ID de groupe supplémentaire pour les modèles de requête/réponse. Elle fournit un contexte de groupe aux accords, aux formulaires web et aux événements Envoyer en masse.
Le paramètre ID de groupe n’est ajouté que dans l’API REST v6. Les versions en dessous de 6 utilisent le groupe principal pour la rétrocompatibilité.
Le code de réponse d’erreur commun ID_GROUPE_NON_VALIDE est déclenché lorsque :
Si la fonctionnalité Utilisateurs dans plusieurs groupes n’est pas activée, tous les points d’entrée existants se comportent comme auparavant. Le groupe principal de l’utilisateur est utilisé comme seule appartenance à un groupe valide. Si un autre ID de groupe est transmis à un point d’entrée, le paramètre ID_GROUPE_NON_VALIDE est renvoyé.
L’ajout d’un utilisateur à plusieurs groupes s’effectue de l’une des deux façons suivantes :
Modification d’un utilisateur individuel via :
Cliquez une fois sur l’utilisateur pour afficher l’option Modifier l’utilisateur, puis cliquez dessus
Une fenêtre de gestion de groupe s’ouvre, permettant à l’administrateur de librement ajouter l’utilisateur à n’importe quel groupe sous son autorité en cliquant sur l’icône +.
Une fois l’utilisateur ajouté au groupe, l’administrateur peut activer/désactiver l’autorité de l’utilisateur au sein du groupe en cochant/décochant les cases sous les en-têtes de colonne Administrateur de groupe et Envoyer.
La fonction Créer/mettre à jour plusieurs utilisateurs permet aux administrateurs de compte de rapidement mettre à jour tous les ID utilisateur de leur compte.
Cette option est disponible pour les administrateurs de groupe qui souhaitent notamment modifier les noms, la société, le titre et d’autres informations similaires. Les administrateurs de groupe ne peuvent pas manipuler la valeur d’appartenance à un groupe via le fichier .csv chargé.
Cliquez sur le lien Téléchargez le fichier CSV d’exemple pour télécharger un exemple de fichier .csv avec les différentes propriétés incluses.
Le format du fichier .csv chargé utilisé pour créer/mettre à jour plusieurs utilisateurs a été modifié pour s’adapter aux utilisateurs inclus dans plusieurs groupes et à l’autorité spécifique au groupe. À cette fin, trois colonnes ont été supprimées dans la fonctionnalité Utilisateurs dans plusieurs groupes :
Nouvelle colonne Groupes
La colonne Groupes contient une ou plusieurs définitions de groupe. Chaque définition de groupe contient le nom d’un groupe, suivi d’une ou plusieurs valeurs d’état entre crochets. Exemple : Nom du groupe[État]
Dans l’exemple ci-dessus :
Les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes sont observables dès le début du processus de création d’un nouvel accord.
Si un utilisateur démarre le processus en sélectionnant un modèle ou un workflow sur la page d’accueil > Démarrer depuis la bibliothèque, il doit développer le groupe à partir duquel il effectue l’envoi en premier, puis sélectionner le modèle/workflow dans les options disponibles dans le groupe.
Le fait de sélectionner le modèle/workflow et de cliquer sur Démarrer ouvre la page Envoyer, permettant à l’utilisateur de terminer la configuration.
En démarrant l’accord à partir d’un modèle ou d’un workflow au niveau du groupe, la valeur du groupe est insérée sur la page Envoyer et l’option permettant de modifier le groupe est supprimée.
Si un modèle/workflow au niveau du compte est sélectionné, l’expéditeur a la possibilité de sélectionner la valeur du groupe.
Si l’utilisateur démarre le processus à partir de la page Envoyer, le champ déroulant Envoyer à partir de définit le groupe auquel l’accord est associé.
Une fois le groupe sélectionné, l’accord est limité aux modèles de bibliothèque disponibles pour le groupe sélectionné.
La modification du groupe modifie les propriétés appliquées à l’accord. L’actualisation de la page est forcée et tout contenu de champ saisi est perdu.
Jusqu’à présent, les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes n’ont pas affecté la création et la gestion des workflows personnalisés :
Dans les mises à jour à venir, les administrateurs auront accès aux options d’interface pour associer les workflows qu’ils créent aux groupes individuels sur lesquels ils ont une autorité d’administration, quel que soit leur groupe principal.
La création d’un modèle de bibliothèque réutilisable dans le cadre des règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes comporte une étape supplémentaire pour l’octroi d’une autorisation au niveau du groupe permettant d’accéder au modèle :
Définissez le groupe auquel le modèle de bibliothèque est associé.
L’ID utilisateur d’origine qui crée un modèle est considéré comme son « propriétaire ».
Le propriétaire du modèle a toujours accès au modèle pour les fonctions Envoyer et Modifier. Peu importe le niveau d’autorité de l’ID utilisateur propriétaire ou si le propriétaire est associé au groupe auquel le modèle est exposé.
Les propriétés des modèles de bibliothèque existants peuvent être modifiées via la page Gérer.
Ouvrez le modèle pour le modifier. Si le modèle est partagé avec Tous les utilisateurs de mon groupe, l’éditeur peut modifier l’association de groupe :
La modification de l’association de groupe n’affecte pas l’affiliation de groupe pour les accords déjà créés.
La création d’un formulaire web dans le cadre des règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes comporte une étape supplémentaire :
Définissez le groupe auquel le formulaire web est associé. Pour cela, consultez la partie supérieure de la page.
Le groupe associé ne peut pas être modifié une fois le formulaire web créé.
Les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes n’affectent pas la façon dont les formulaires web existants sont gérés (car le groupe associé ne peut pas être modifié).
La création de rapports en fonction de formulaires web nécessite que le rapport soit exécuté par son créateur ou par un administrateur habilité à utiliser les données du rapport dans le groupe.
Le partage d’un accord ou d’un modèle individuel n’est pas affecté par les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes.
Les comptes qui utilisent le partage de compte standard (partage Utilisateur à Utilisateur uniquement) ne sont pas affectés par les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes.
Le partage de compte avancé permet le partage entre utilisateurs, entre groupes et entre utilisateurs et groupes :
Le partage Utilisateur à Utilisateur n’est pas modifié sous les règles régissant la fonctionnalité Utilisateurs dans plusieurs groupes :
Lorsqu’un l’utilisateur A est partagé avec le groupe X :
Lorsque le groupe A est partagé avec l’utilisateur X :
Lorsque le groupe A est partagé avec le groupe B
Aucun changement n’est attendu pour l’ensemble des outils RGPD en ce qui concerne les modifications apportées par la fonctionnalité Utilisateurs dans plusieurs groupes.
Tous les comptes d’entreprise peuvent activer la fonctionnalité Utilisateurs dans plusieurs groupes, même lorsqu’une (ou plusieurs) intégration est configurée.
Les packages d’intégration Acrobat Sign actuels ne tiennent en aucune façon compte de la fonctionnalité Utilisateurs dans plusieurs groupes. Par conséquent, tous les utilisateurs qui envoient des accords par le biais d’une intégration sont perçus comme appartenant uniquement à leur groupe principal et les paramètres d’envoi s’alignent en conséquence sur les paramètres du groupe principal.
La plupart des points d’entrée de l’API REST v6 ont un paramètre facultatif pour l’ID de groupe ajouté à la méthode.
On suppose actuellement que tout appel d’API REST v6 existant continuera de fonctionner, que la fonctionnalité Utilisateurs dans plusieurs groupes soit activée ou non.
Les versions précédentes de l’API (SOAP et REST) continueront de fonctionner comme prévu et considéreront l’utilisateur uniquement en tant que membre de son groupe principal.
Accéder à votre compte