Add transform to remove invalid references from profiles #3688
Conversation
…ub.com/SFDO-Tooling/CumulusCI into feature/clean-profiles-deploy-mutation
…ub.com/SFDO-Tooling/CumulusCI into feature/clean-profiles-deploy-mutation
…ub.com/SFDO-Tooling/CumulusCI into feature/clean-profiles-deploy-mutation
…ub.com/SFDO-Tooling/CumulusCI into feature/clean-profiles-deploy-mutation
There was a problem hiding this comment.
@aditya-balachander This looks great. Appreciate the depth of research you put into edge cases here. I have a few questions about aspects I didn't understand. We might actually be doing more than we need to!
cumulusci/tasks/salesforce/Deploy.py
Outdated
| @@ -220,6 +226,9 @@ def _get_package_zip(self, path) -> Union[str, dict, None]: | |||
| "clean_meta_xml": process_bool_arg( | |||
| self.options.get("clean_meta_xml", True) | |||
| ), | |||
| "clean_profiles": process_bool_arg( | |||
| self.options.get("clean_profiles", True) | |||
There was a problem hiding this comment.
Let's think this through - defaulting to True is sort of a breaking change. @jstvz what are your thoughts? @sumeet-parmar? @jkasturi-sf?
Say we have an existing project. Today, it will fail to deploy into an org that is missing specific features to expose permissioned components in its metadata bundle. If we default this to True, that project may begin to deploy cleanly.
What's the state of the user's org, then? In most or all cases, I think it will simply work. That's because the success of the deploy will only change if the Profile or PermSet reference was the only reference to the missing component. Anything else would cause a failure that we would not stop here (nor would we want to).
I'm leaning towards agreeing with the decision to default this to True.
There was a problem hiding this comment.
The clean_invalid_ref defaults to False. Again sorry for not removing the old code
There was a problem hiding this comment.
Ohh shall I keep it to True?
|
Most of the corner cases resolved. There is still an issue with some of the UserPermissions not being retrieved (in certain API versions). This is because in core, these UserPermissions either have a The problem occurs because the SOAP call to retrieve the profile/permissionset gives all the UserPermissions regardless of which API Version is mentioned. However when we make a rest/tooling API call to retrieve these UserPermissions, only the ones present in that particular API version are retrieved. @davidmreed kindly review the PR |
jstvz
changed the title
W-11744607
W-11744695
Implemented Functionality to clean profiles and permission sets of invalid references.
Issues (corner cases that are not supported currently)
i. Couple of sObjects (some of which are not supported, and Document which is a metadata of it's own but comes under ObjectPermissions)
ii. Couple of tabs (These tabs are permissioned in the profile but are not present in the TabDefinition table or the tabs page in setup of the org. Most likely these are linked tabs as part of applications or other metadata types)
iii. Couple of fields (which are permissioned in the org but are missing in the sObject itself)
i. Some UserPermissions are dependent on other UserPermissions. Say permission A depends on B (both A and B are present in the target org). There is no current check to see if B is present when A is present in the profile or permissionset file. Without B, deployment fails when you try to deploy A.
We have created a WI to resolve these issues: W-14363935