Partage et attribution
Dans cet article, nous allons examiner l’accès de sécurité lors du partage et de l’attribution d’enregistrements.
le partage des enregistrements ;
Le partage permet aux utilisateurs d’accorder à d’autres utilisateurs ou équipes le droit d’accéder à des informations spécifiques concernant les clients. Le partage des enregistrements est utile pour partager des informations avec des utilisateurs dont les rôles n’offrent que le niveau d’accès De base. Par exemple, dans une organisation qui accorde aux commerciaux l’accès en lecture et en écriture De base aux comptes, un commercial peut partager une opportunité avec un autre commercial afin qu’ils puissent tous les deux suivre l’avancement d’une vente importante.
Pour des raisons de sécurité, prenez l’habitude de partager uniquement les enregistrements nécessaires, avec un nombre d’utilisateurs le plus restreint possible. Accordez uniquement l’accès minimum nécessaire pour que les utilisateurs puissent effectuer leur travail. Un utilisateur peut avoir accès à un même enregistrement dans plusieurs contextes. Par exemple, un utilisateur peut partager directement un enregistrement avec des droits d’accès spécifiques, et il peut également faire partie d’une équipe dans laquelle le même enregistrement est partagé avec des droits d’accès différents. Dans ce cas, l’ensemble de ces droits constitue les droits d’accès dont dispose cet utilisateur sur l’enregistrement.
Lorsque vous partagez un enregistrement avec un autre utilisateur à l’aide du message GrantAccess, vous devez indiquer les droits d’accès (Lire, Écrire, Supprimer, Ajouter, Attribuer et Partager) que vous souhaitez accorder à l’autre utilisateur. Pour modifier l’accès d’un enregistrement partagé, utilisez le message ModifyAccess. Les droits d’accès sur un enregistrement partagé peuvent être différents pour chaque utilisateur avec lequel l’enregistrement est partagé. Toutefois, vous ne pouvez accorder à un utilisateur des droits dont il ne dispose pas, d’après le rôle qui lui est attribué, pour ce type de table. Par exemple, si un utilisateur ne dispose pas de privilèges de lecture sur les comptes et que vous partagez un compte avec lui, il ne peut pas voir ce compte.
Exemple GrantAccess
Ces exemples montrent l’utilisation du message GrantAccess pour partager un enregistrement avec un autre principal.
La méthode statique ShareRecord suivante affiche comment utiliser la classe PrincipalAccess pour préciser une référence à un principal (utilisateur, équipe ou organisation) avec un ensemble de AccessRights contenant les droits à accorder au principal.
/// <summary>
/// Shares a record with a principal
/// </summary>
/// <param name="service">Authenticated client implementing the IOrganizationService interface</param>
/// <param name="principal">The user, team, or organization to share the record with.</param>
/// <param name="access">The access rights to grant</param>
/// <param name="record">The record to share</param>
static void ShareRecord(
IOrganizationService service,
EntityReference principal,
AccessRights access,
EntityReference record)
{
PrincipalAccess principalAccess = new()
{
AccessMask = access,
Principal = principal
};
GrantAccessRequest request = new()
{
PrincipalAccess = principalAccess,
Target = record
};
service.Execute(request);
}
Exemple ModifyAccess
Ces exemples montrent l’utilisation du message ModifyAccess pour modifier l’accès accordé à un principal pour un enregistrement partagé.
La méthode statique ModifyShare suivante affiche comment utiliser la classe PrincipalAccess pour préciser une référence à un principal (utilisateur, équipe ou organisation) avec un ensemble de AccessRights contenant les droits à modifier pour le principal.
/// <summary>
/// Modifies the access to a shared record.
/// </summary>
/// <param name="service">Authenticated client implementing the IOrganizationService interface</param>
/// <param name="principal">The user, team, or organization to modify rights to the shared.</param>
/// <param name="access">The access rights to modify</param>
/// <param name="record">The shared record</param>
static void ModifyShare(
IOrganizationService service,
EntityReference principal,
AccessRights access,
EntityReference record)
{
PrincipalAccess principalAccess = new()
{
AccessMask = access,
Principal = principal
};
ModifyAccessRequest request = new()
{
PrincipalAccess = principalAccess,
Target = record
};
service.Execute(request);
}
Partage et héritage
Si un enregistrement est créé et que l’enregistrement parent a certaines propriétés de partage, le nouvel enregistrement hérite de ces propriétés. Prenons un exemple : Joe et Mike travaillent sur un prospect prioritaire. Joe crée un nouveau prospect et deux activités, partage le prospect avec Mike et sélectionne un partage en cascade. Mike passe un appel téléphonique et envoie un message électronique concernant le nouveau prospect. Joe constate que Mike a contacté la société deux fois. Joe décide donc de ne pas rappeler.
Le partage est géré pour les enregistrements individuels. Un enregistrement hérite des propriétés de partage de son parent et gère ses propres propriétés de partage. Par conséquent, un enregistrement peut avoir deux ensembles de propriétés de partage : un ensemble propre et un ensemble hérité de son parent.
La suppression du partage d’un enregistrement parent entraîne la suppression des propriétés de partage des objets (enregistrements) héritées du parent. Ainsi, tous les utilisateurs qui pouvaient, au préalable, consulter cet enregistrement ne le peuvent plus. Les objets enfants peuvent encore être partagés avec certains de ces utilisateurs s’ils étaient partagés individuellement, et non pas à partir de l’enregistrement parent.
Attribution d’enregistrements
Toute personne disposant des privilèges d’attribution sur un enregistrement peut attribuer cet enregistrement à un autre utilisateur. Pour attribuer un enregistrement, modifiez la valeur de recherche ownerid pour faire référence à un nouveau principal.
Notes
Le SDK a une classe AssignRequest obsolète. Pour plus d’informations, voir Messages de mise à jour hérités.
Lorsqu’un enregistrement est attribué, le nouvel utilisateur ou la nouvelle équipe ou organisation devient le propriétaire de l’enregistrement et de ses enregistrements associés. L’utilisateur, l’équipe ou l’organisation d’origine perd la propriété de l’enregistrement, mais la partage automatiquement avec le nouveau propriétaire.
Dans Microsoft Dataverse, l’administrateur système d’une organisation peut décider si les enregistrements doivent ou non être partagés avec les propriétaires précédents après l’opération d’attribution. Si Partager les enregistrements réattribués avec le propriétaire d’origine est sélectionné (voir Paramètres système > Général), le propriétaire précédent partagera l’enregistrement avec tous les droits d’accès après l’opération d’attribution. Sinon, le propriétaire précédent ne partage pas l’enregistrement et peut ne pas avoir accès à l’enregistrement, en fonction de ses privilèges. La colonne ShareToPreviousOwnerOnAssign de la table Organization contrôle ce paramètre.
Notes
La table des rendez-vous a une logique spéciale lorsqu’un rendez-vous est attribué à un autre utilisateur. Si le propriétaire actuel est toujours un participant tel que l’organisateur ou un participant, l’enregistrement de rendez-vous est partagé avec cet utilisateur lorsque le rendez-vous est réattribué. Ce comportement se produit même si le paramètre Partager les enregistrements réattribués avec le propriétaire d’origine est désactivé. Étant donné que le rendez-vous peut être partagé avec l’ancien propriétaire, l’utilisateur qui attribue la réunion a besoin à la fois des droits d’accès Attribuer et Partager au dossier.
Révoquer l’accès
Le propriétaire d’un enregistrement peut utiliser le message RevokeAccess pour révoquer (supprimer) l’accès des utilisateurs à l’enregistrement partagé.
La méthode statique RevokeShare suivante montre comment supprimer l’accès partagé d’un utilisateur à un enregistrement à l’aide de la classe RevokeAccessRequest.
/// <summary>
/// Revokes access to a shared record.
/// </summary>
/// <param name="service">Authenticated client implementing the IOrganizationService interface</param>
/// <param name="principal">The user, team, or organization to revoke rights to the shared record.</param>
/// <param name="record">The shared record</param>
static void RevokeShare(
IOrganizationService service,
EntityReference principal,
EntityReference record)
{
RevokeAccessRequest request = new()
{
Revokee = principal,
Target = record
};
service.Execute(request);
}
Plus d’information : Accès partagé.
Déterminer pourquoi un utilisateur a accès
La fonctionnalité Vérifier l’accès dans les applications pilotées par modèle fournit des informations permettant aux utilisateurs de comprendre pourquoi un utilisateur a accès à un enregistrement. Pour obtenir ces informations avec du code, utilisez le message RetrieveAccessOrigin. Lorsqu’il transmet des informations sur un utilisateur et un enregistrement spécifiques, ce message renvoie une phrase décrivant pourquoi l’utilisateur a accès. Voici les réponses possibles lorsque l’opération réussit :
Access origin could not be determined because FCB is disabled.
PrincipalId is object owner (<record ID>)
PrincipalId is member of team (<team ID>) who is object owner (<record ID>)
PrincipalId is member of organization (<organization ID>) who is object owner (<record ID>)
PrincipalId has access to (<hierarchy security principal ID>) through hierarchy security. (<hierarchy security principal ID>) is object owner (<record ID>)
PrincipalId has direct poa access to object (<record ID>)
PrincipalId is member of team (<team ID>) who has poa access to object (<record ID>)
PrincipalId is member of organization (<organization ID>) who has poa access to object (<record ID>)
PrincipalId is owner of a parent entity of object (<child record ID>)
PrincipalId is member of team (<team ID>) who is owner of a parent entity of object (<child record ID>)
PrincipalId is member of organization (<organization ID>) who is owner of a parent entity of object (<child record ID>)
PrincipalId has access to (<hierarchy security principal ID>) through hierarchy security. (<hierarchy security principal ID>) is owner of a parent entity of object (<child record ID>)
PrincipalId has poa access to object's root entity (<child record ID>)
PrincipalId is member of team (<team ID>) who has poa access to object's root entity (<child record ID>)
PrincipalId is member of organization (<organization ID>) who has poa access to object's root entity (<child record ID>)
Access origin could not be found. Access does not come from POA table or object ownership.
Notes
Il n’existe actuellement aucune classe RetrieveAccessOriginRequest ou RetrieveAccessOriginResponse dans le SDK. Pour utiliser ce message, vous devez utiliser les classes OrganizationRequest et OrganizationResponse. En savoir plus sur l’utilisation des messages avec le SDK pour .NET.
/// <summary>
/// Describes why a principal (systemuser or team) has access to a record.
/// </summary>
/// <param name="service">The authenticated IOrganizationService instance to use.</param>
/// <param name="objectId">The unique identifier of a record.</param>
/// <param name="tableLogicalName">The logical name of the table for the record in the ObjectId parameter.</param>
/// <param name="principalId">The unique identifier of the systemuser or team record.</param>
/// <returns>A sentence explaining why the principal has access to a record.</returns>
public static void OutputRetrieveAccessOrigin(IOrganizationService service,
Guid objectId,
string tableLogicalName,
Guid principalId)
{
var parameters = new ParameterCollection()
{
{ "ObjectId", objectId},
{ "LogicalName", tableLogicalName},
{ "PrincipalId", principalId}
};
var request = new OrganizationRequest()
{
RequestName = "RetrieveAccessOrigin",
Parameters = parameters
};
var response = service.Execute(request);
Console.WriteLine(response.Results["Response"]);
}
Sortie de l’exemple : PrincipalId is object owner (e41ac31a-dcdf-ed11-a7c7-000d3a993550)
Voir aussi
Notes
Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)
Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour