10 February 2014

You can retrieve if you want to, you can leave your friends behind

I had the following question come up twice recently, once on the salesforce stackexchange: Are profile and permission set metadata files getting all objectPermissions?

You can get a better sense of what's supported and how profiles/permission sets behave with the Metadata API (MdAPI) through the SalesforceHacker blog posting: Dude, Where's My Permission?

The short answer here is that, as a general rule, we try to retrieve only enabled permissions through the MdAPI. This helps reduce the size of the .profile or .permissionset file and also keeps the focus on what the user has rather than what they don't. Since we are firm believers in positive permissions, this helps us keep track of what we are rather than what we are not.

Keep in mind that retrieve is very different from deploy where permissions are concerned in the MdAPI.

Retrieve has very specific behaviors, many of which require a junction object in the payload/package.xml to retrieve 'custom' permission settings (e.g. Foo__c CRUD will be retrieved *only* if the Foo__c custom object is also in the payload).

As a result, custom permissions in particular will only be retrieved *if* there is both an enabled permission *and* the junction object is specified in the manifest. For instance the following will only retrieve CRUD on Foo__c if at least Read permission is enabled:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>Standard User</members>
        <name>Profile</name>
    </types>
    <types>
        <members>Foo__c</members>
        <name>CustomObject</name>
    </types>
    <version>30.0</version>
</Package>

However, deployment doesn't require the concept of junction. I can declare whatever permission I want (e.g. Foo__c CRUD = false across all object permissions). As a result, If I create a prototypical profile or permission set with *all* permissions enabled and retrieve it, I will know the syntax of every permission that is allowed within my deployment.

For instance, I can now define something like Foo__c CRUD = false across all CRUD permissions for that object and when I deploy it, I will revoke Foo_c CRUD in my target org for that profile or permission set:

<?xml version="1.0" encoding="UTF-8"?>
<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
    <custom>true</custom>
    <objectPermissions>
        <allowCreate>false</allowCreate>
        <allowDelete>false</allowDelete>
        <allowEdit>false</allowEdit>
        <allowRead>false</allowRead>
        <modifyAllRecords>false</modifyAllRecords>
        <object>Foo__c</object>
        <viewAllRecords>false</viewAllRecords>
    </objectPermissions>
    ...
</Profile>

As a result, I have a lot more control over deployment of permissions including revoking them if I modify the .profile or .permission set files before deploying my permissions.

No comments:

Post a Comment