API des autorisations effectives

La page API effectivePermissions indique à un client MCP ce que l'utilisateur connecté peut faire dans Microsoft Dynamics 365 Business Central, avant que le client n'essaie. Elle renvoie une ligne par page API de l'environnement, avec les verdicts de l'appelant pour la lecture, l'insertion, la modification, la suppression et l'exécution. Un client MCP tel que le connecteur BC MCP Pro l'utilise pour masquer les outils qu'un utilisateur ne peut pas utiliser, en un seul appel au lieu d'essayer chaque page.

La page est en lecture seule. Elle ne fait que rapporter : rien de ce qu'elle renvoie n'élargit ni ne restreint ce qu'un utilisateur peut faire. Business Central reste celui qui applique les règles.

Le point de terminaison

GET https://api.businesscentral.dynamics.com/v2.0/{environment}/api/vangelderSolutions/mcpguard/v1.0/companies({companyId})/effectivePermissions

La page est MCP Guard Eff. Permissions (73633175). L'utilisateur a besoin de l'ensemble d'autorisations MCP GUARD - USER. Pour la proposer à un client MCP, ajoutez la page à la configuration MCP avec Allow Read activé. Voir Configurations MCP.

Les champs

Champ	Signification
`pageId`, `pageName`	La page API, par exemple `30009`, `APIV2 - Customers`.
`apiPublisher`, `apiGroup`, `apiVersion`, `entitySetName`	L'emplacement de la page dans l'API.
`sourceTableId`, `sourceTableName`	La table source de la page.
`canRead`	Si l'utilisateur peut lire la table source. Les ensembles d'autorisations, les groupes de sécurité et les droits de licence sont pris en compte.
`canInsert`, `canModify`, `canDelete`	Si les ensembles d'autorisations de l'utilisateur accordent une autorisation directe sur la table source.
`canExecute`	Si l'utilisateur peut exécuter la page elle-même. Sans cela, chaque appel échoue, quelles que soient les autorisations sur la table.
`hasSecurityFilter`, `securityFilter`	Si un filtre de sécurité s'applique à la table source pour cet utilisateur, et lequel.

Les verdicts sont calculés au moment de l'appel, pour l'appelant uniquement. Un utilisateur ne peut pas lire les verdicts d'un autre utilisateur.

Comment les verdicts sont déterminés

La lecture provient de Business Central lui-même : elle reflète donc tout ce que Business Central applique à une lecture, à savoir les ensembles d'autorisations, les groupes de sécurité et les droits de licence.

L'insertion, la modification, la suppression et l'exécution proviennent des ensembles d'autorisations attribués à l'utilisateur dans la société en cours. Seule l'autorisation directe compte. L'autorisation indirecte ne compte pas, car une page API exécute l'opération directement. Un utilisateur disposant de l'ensemble d'autorisations SUPER obtient vrai pour toutes.

Le filtre de sécurité est le filtre sur l'autorisation de lecture de l'utilisateur pour la table source. Lorsque l'un des ensembles d'autorisations de l'utilisateur accorde la table sans filtre, Business Central n'applique aucun filtre, et la page n'en rapporte aucun.

Ce que la page ne peut pas voir

Les droits de licence pour les opérations d'écriture. Une licence peut encore bloquer une insertion que l'ensemble d'autorisations autorise.
Les tables qu'une page API lit dans le code en plus de sa table source.
Les filtres qui résident dans le code de l'application.

Ainsi, canRead faux et canExecute faux sont fiables : le client MCP peut masquer l'outil. canRead vrai signifie que la table source est lisible, et non que chaque appel réussira. Considérez les verdicts d'écriture comme « l'ensemble d'autorisations l'autorise ». Lorsque Business Central refuse un appel, ce refus est définitif.

Coût