Improve PermissionSet comparisons by providing an option to ignore fieldPermissions when their editable/readable are set to false
Current Metadata Behavior:
When a new object is added, objectPermissions are only added to a PermissionSet only if one of allowCreate, allowDelete, allowEdit, modifyAllRecords, viewAllRecords are set to true
When a new field is added, the new fieldPermission is added to all PermissionSets by default (with editable and readable set to false).
NB. PermissionSets are additive in behavior and can only open up access not revoke. Values of false have no meaning and are only noise.
Current Gearset Comparison Behavior:
Comparing PermissionSets show these new fieldPermssions as New Items even when default values for editable, readable are set to false. There is no way to filter these out for comparison and need to be reviewed manually.
Desired Gearset Comparison Behavior:
Ability to filter out fieldPermissions when editable, readable are set to false, resulting in more accurate PermissionSets comparisons.
New fieldPermissions are being added to all PermissionSets are causing excess noise/comparison time. If reviewing a PermissionSet fieldPermission change consumes anywhere from 1-2 minutes, a 10 project team consisting of 5 developers per team with an average of 5 PermissionSets per team results in each team spending 25-50 minutes daily reviewing non-relevant changes (5 developers each reviewing changes applied to their team's 5 PermissionSets). 10 teams results in nearly 250-500 minutes (4-9 hrs) daily consumed in this exercise.
This is what we are experiencing.
Eric Kintzer commented
I've noticed that deploying a NEW permission set, that Gearset is implicitly fetching the FLS for:
* All custom object custom fields (including excluded managed packages) - regardless of whether edit/read are both FALSE
Gearset does not fetch for NEW PS the FLS for standard objects (standard fields or custom fields)
Thus, behavior is inconsistent. NEW PS should exclude all FLS where both editable/readable are false. This avoids issues where you want a NEW PS to only include fields ready to deploy and not WIP fields.
Andrew Sim commented
Ok, it appears that these fieldPermissions are only included when you include CustomObjects in your metadata retrieve(). Logging a case w/ salesforce to determine if this is intended behavior or not. fieldPermission behavior when using a metadata retrieve() without any CustomObjects behaves as expected when retrieving PermissionSets.
Stephen Krieger commented
Let's do this!