Explicitly set object-level permissions, even if these are omitted from XML provided by Salesforce API
Valerio recommended that I post this suggestion following a discussion on 29 August 2019.
Issue reference:
https://docs.gearset.com/en/articles/3226459-a-note-on-deploying-custom-object-permissions-on-new-profiles
Issue:
1. Remove all object-level access for "Lead" from a custom profile in a source org
2. Deploy this profile to a target org
3. The profile in the target org will have access to the "Lead" object ENABLED, because this access is included in the Standard User profile (see document link above)
The workaround (deploying and then deploying again) is cumbersome and not always practical, e.g. if making automated, one-step deployments outside of Gearset. Failing to make a second deployment means that users with the profile will have access to objects that they should not, which is a major security risk.
I suggest that you add the option to explicitly add permissions to the XML, even where these are not provided by the Salesforce metadata API. So in this example, if the Lead object's permissions are omitted from the profile, generate the explicit XML definition for that and let me commit that definition to the target repository.
Copado offers this option, albeit for all permissions within the profile:
https://docs.copa.do/article/ob0eyv4wk6-commit-full-profiles-and-permission-sets
Relevant part from link above: "The Full Profiles & Permission Sets feature does not follow the standard behavior of the metadata API during the retrieve of system permissions. Unlike the regular profile or permission set commits, the turned off system permissions will be committed in the XML with the tag enabled as false."
Robert Fay
shared this idea
-
Dafydd Johns commented
The Knowledge Article about custom object permissions begins to explain well what the issue is, but I just thought I was missing something. Why can't Gearset, with knowledge that certain permissions are not returned when set to false, just explicitly set them. The article seems to suggest that it just isn't possible.
Because we typically work with a selective scope of metadata in source control, we don't deploy deletions, but annoyingly any second deployment sees these as deletions (rather than a change) so never go through (even though Gearset knows that the lack of existence of a tag means it is false)