It turns out that what we call the 'System Administrator' standard profile actually maps to the Admin.profile file in the MdAPI. This means, when retrieving the System Administrator profile, you'll find all of the permissions and settings in the Admin.profile file in the profile directory.
Here's where it goes a little sideways. If you create a custom profile called 'Admin', there's some ambiguity when you try to migrate permissions for the 'System Administrator' standard profile which goes by the same name.
As a result, given the right order of operations, the System Administrator profile will be ignored when migrating permissions for the custom Admin profile using the MdAPI.
The same is true for any of the standard profiles:
Standard Profile Name in the User Interface | Standard Profile File Name in the MdAPI |
System Administrator | Admin.profile |
Standard User | Standard.profile |
Marketing User | MarketingProfile.profile |
Contract Manager | ContractManager.profile |
Solution Manager | SolutionManager.profile |
Read Only | ReadOnly.profile |
Customer Portal Manager | CustomerManager.profile |
Customer Portal User | CustomerUser.profile |
High Volume Customer Portal | HighVolumePortal.profile |
Partner User | Partner.profile |
Authenticated Website | PlatformPortal.profile |
Standard Platform User | StandardAul.profile |
Give it a try - steps to reproduce:
- retrieve 'Admin' profile in MdAPI which retrieves the 'System Administrator' profile
- add an assigned app visibility to the .Admin profile file and deploy
- System Administrator profile updates with additional app visibility
- clone System Administrator profile and call it 'Admin'
- retrieve 'Admin' profile in MdAPI which retrieves the cloned/custom 'Admin' profile thereby ignoring the 'System Administrator' profile
- add an assigned app visibility to the .Admin profile file and deploy
- custom Admin profile updates with additional app visibility, System Administrator profile is ignored
- log into workbench
- add the ability to query parent relationships by going to Workbench > Settings and enabling 'Allows SOQL Parent Relationship Queries' before selecting 'Apply Settings' button at the top of the screen
- run the following query by going to queries > SOQL Query:
SELECT Profile.Id, Profile.Name FROM PermissionSet WHERE
(Profile.Name = 'Admin' OR
Profile.Name = 'Standard' OR
Profile.Name = 'MarketingProfile' OR
Profile.Name = 'ContractManager' OR
Profile.Name = 'SolutionManager' OR
Profile.Name = 'ReadOnly' OR
Profile.Name = 'CustomerManager' OR
Profile.Name = 'CustomerUser' OR
Profile.Name = 'HighVolumePortal' OR
Profile.Name = 'Partner' OR
Profile.Name = 'PlatformPortal' OR
Profile.Name = 'StandardAul')
As a result of this edge case, the best practice is to name custom profiles something different from what the MdAPI understands as a standard profile name in order to effectively migrate permissions between environments.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.