Plus de droits d’accès aux champs sur les Profiles, vraiment ?
Vous avez commencé votre transition des Profiles vers les Permission Sets, mais malgré cela il existe toujours un détail très pénible. A chaque fois que vous créez un nouveau champ, Salesforce continue à vous proposer d’ajouter les droits de lecture/écriture sur les Profiles. Non seulement vous (et vos collaborateurs) devez penser à décocher les droits attribués par défaut sur cette page, mais en plus vous devez ensuite aller dans les Permission Sets concernés et y ajouter manuellement les droits des nouveaux champs, pénible !
Le premier problème est d’autant plus gênant qu’en ajoutant un droit par mégarde sur un Profile, vous risquez de donner des droits supplémentaires non voulus à vos utilisateurs finaux. Si vous utilisez un gestionnaire de source comme GitHub ou GitLab, vous pourrez au moins y détecter un changement sur le(s) Profile(s) et revenir en arrière, sinon le changement pourrait être déployé sans que personne ne s’en rende compte.
Le deuxième problème ajoute surtout un risque d’oubli, si vous créez 10 champs, que vous devrez ajouter ensuite à plusieurs Permission Sets, le risque d’oublier de reporter les droits correctement ensuite et réel. Et celui d’entendre votre équipe se plaindre de ce processus contraignant encore plus 🤯
Un nouveau paramètre à la rescousse
Heureusement, depuis la release Winter ’23, il est possible de changer ce fonctionnement et d’activer un paramètre permettant d’afficher les Permission Sets à la place des Profiles auxquels ajouter les droits des champs lors de leur création. Voilà qui résout les deux problèmes !
Pour l’activer, rien de plus simple, rendez-vous dans Paramètres de gestion des utilisateurs (User Management Settings) et cochez Sécurité au niveau du champ pour les ensembles d’autorisations pendant la création de champs (Field-Level Security for Permission Sets during Field Creation).
Si vous utilisez des Scratch Orgs, il vous suffira de modifier votre fichier de définition de Scratch Org (project-scratch-def.json) pour activer le paramètre, via userManagementSettings/permsetsInFieldCreation. Cela vous donnera un fichier tel que celui-ci:
{« orgName »: « Texeï »,« edition »: « Developer »,« features »: [« EnableSetPasswordInApi »],« settings »: {« lightningExperienceSettings »: {« enableS1DesktopEnabled »: true},« mobileSettings »: {« enableS1EncryptedStoragePref2 »: false},« userManagementSettings »: {« permsetsInFieldCreation »: true}}}
Attention, cette fonctionnalité est encore en Beta, mais bonne nouvelle c’est qu’il est possible de la désactiver si elle ne vous convenait pas 🙂
Si vous avez manqué l’article de Maher du jour 20 du Tex’Calendar, c’est ici.
