5

Problem

The <objectPermissions> tags are missing from my custom profiles when I pull from a scratch-org using SFDX or MDAPI.

Steps to reproduce

  1. Create a new Scrach-org.
  2. Create a custom profile, say "Support".
  3. Add some Standard Object Permissions to the profiles. Looks like this:

enter image description here

  1. Use SFDX pull or MDAPI Retrieve.

The Support.profile-meta.xml contains all the settings I added to the profile, except for <objectPermissions>. The missing tag should look like this: 

 <objectPermissions> <allowCreate>true</allowCreate> <allowDelete>true</allowDelete> <allowEdit>true</allowEdit> <allowRead>true</allowRead> <modifyAllRecords>true</modifyAllRecords> <object>Account</object> <viewAllRecords>true</viewAllRecords> </objectPermissions>

If I now push the profile to a new scratch org, then the profile will be missing some permissions such as View All and Modify All since the tags are missing. Looking like this:

enter image description here

Questions

How can I use SFDX or MDAPI to retrieve the missing tags? Or, do some workaround exist?

Improve this question

3 Answers 3

Reset to default
9

Note: this works for api version 44.0

Turns out there's a trick to doing this with the Metadata API

If your package.xml file only contains 

 <types> <members>Support</members> <name>Profile</name> </types>

Then it only retrieves user permissions, license information and whether or not it's custom. My best guess is because of the dependencies on the other metadata.

With that being said, simply add the remaining metadata components you're looking to retrieve that are related to the profile to the package.xml file:

 <types> <members>Account.Custom_Record_Type</members> ... <members>Task.Custom_Record_Type</members> <name>RecordType</name> </types> <types> <members>Account</members> ... <members>Task</members> <name>CustomObject</name> </types>

And the result of your profile metadata api retrieval will look like this:

 ... <objectPermissions> <allowCreate>true</allowCreate> <allowDelete>false</allowDelete> <allowEdit>false</allowEdit> <allowRead>true</allowRead> <modifyAllRecords>false</modifyAllRecords> <object>Account</object> <viewAllRecords>true</viewAllRecords> </objectPermissions> <recordTypeVisibilities> <default>false</default> <recordType>Account.Custom_Record_Types</recordType> <visible>false</visible> </recordTypeVisibilities> ... <recordTypeVisibilities> <default>false</default> <recordType>Task.Custom_Record_Type</recordType> <visible>false</visible> </recordTypeVisibilities> ... <tabVisibilities> <tab>standard-Account</tab> <visibility>DefaultOn</visibility> </tabVisibilities> ... <userPermissions> <enabled>true</enabled> <name>ViewRoles</name> </userPermissions> </Profile>

All of the steps in how to do this are listed here in this article.

Improve this answer
8

Kai Tribble answered nicely for metadata api.

If you are using source format, you should pull all other the metadata with the profile that aught to be in it. For example, this would get the Profile and any permissions for CustomObjects and Apex Classes:

sfdx force:source:retrieve -m "Profile, CustomObject, ApexClass"

Improve this answer
0
3

On the whole, SFDX doesn't work well with profiles.

If you're using unlocked packages with SFDX to break your system into modules, the problem is that a single profile may need to have permissions relating to many modules. So each package would need to write to the same profile, and they can't all own the profile.

So, the usual approach is to use permission sets to handle the permissions on a per-module basis. Or ignore the permissions in SFDX and just set up the profiles after installing into the target org.

It's one of the areas where SFDX is a bit underdeveloped at the moment.

Improve this answer
3
  • Permission sets is definitely the way to go Commented Aug 29, 2019 at 8:39
  • While the response and comment are useful, I'm not sure they answer the question. I'm looking to do the same thing, and it seems like there's currently not a way to retrieve these settings using the mdapi and sfdx. I'd try using an IDE (or go back into the vault and use MavensMate) that uses the Tooling API for retrieval. Commented Jan 31, 2020 at 17:28
  • There's a VS Code plugin that lets you navigate metadata and build a package marketplace.visualstudio.com/… Commented Mar 7, 2021 at 1:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.