Retrieving and Deploying Document permissions on profiles/permission sets?

[Chris Stark]

I ran into an issue this week with attempting to deploy a permission set that required the Read Document permission, and I'm wondering if IlluminatedCloud or any of its users have encountered this or have an approach or workaround I could adopt. Some quick background...

When you request profile metadata, Salesforce only returns permissions related to the objects included in package.xml used for the request. For example, retrieving metadata using the following package.xml will result in the permission set containing mostly metadata around SomeObject__c:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">

    <!-- custom objects -->
    <types>
        <name>CustomObject</name>
        <members>SomeObject__c</members>
    </types>

    <!-- permission sets -->
    <types>
        <name>PermissionSet</name>
        <members>SomePermissionSet</members>
    </types>

    <version>37.0</version>
</Package>

The file structure you would have returned looks like this:

/src/objects/SomeObject__c.object
/src/permissionsets/SomePermissionSet.permissionset (contains info about SomeObject__c only)

If the permission set requires some other permission (i.e. Read Account), the normally the change is simple. Adding the object to the package.xml and re-pulling metadata will return the appropriate chunks of the permission set metadata, like so:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">

    <!-- custom objects -->
    <types>
        <name>CustomObject</name>
        <members>Account</members>
        <members>SomeObject__c</members>
    </types>

    <!-- permission sets -->
    <types>
        <name>PermissionSet</name>
        <members>SomePermissionSet</members>
    </types>

    <version>37.0</version>
</Package>

The file structure now looks like:

(contains info about Account and SomeObject__c)


With all that background, this becomes more complicated when using specifically the Document type, as Document is not a retrievable metadata object:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">

    <!-- custom objects -->
    <types>
        <name>CustomObject</name>
        <members>Document</members>
        <members>SomeObject__c</members>
    </types>

    <!-- permission sets -->
    <types>
        <name>PermissionSet</name>
        <members>SomePermissionSet</members>
    </types>

    <version>37.0</version>
</Package>

The file structure now looks like:

(contains info about Document and SomeObject__c)


Importantly, the Document chunks of the permission set are properly returned from the MDAPI, but Document.object metadata is not. When you try to deploy using this package.xml, you will receive an error indicating that Document.object is specified in the package.xml but not present in the deploy package.

It seems like one workaround might be to keep a separate "retrieve" package.xml from a "deploy" package.xml, but that seems like a maintenance nightmare for larger projects. The problem with this would be that on-deploy, permission set and profile chunks related to entities not present in the deploy package are ignored.

Any thoughts about how to attack this problem? Has anyone else here run into this issue before?

[Chris Stark]

Apologies, the second file structure should look like this:

/src/objects/Account.object

/src/objects/SomeObject__c.object

/src/permissionsets/SomePermissionSet.permissionset (contains info about Account and SomeObject__c)

And the third should look like this:

/src/objects/SomeObject__c.object

/src/permissionsets/SomePermissionSet.permissionset (contains info about Document and SomeObject__c)

[Scott]

Chris, I believe the root cause of this issue is this:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/586/allow-document-and-pushtopic-objects-to-be

The Metadata API doesn't actually include Document and PushTopic in the response to listMetadata("CustomObject"), so IC isn't including them in metadata deployment/retrieval operations.  Of course, as you've noticed, you need them to be specified if you want to work with other metadata types that reference them.

I'm planning to address that issue in the next few days.  For the moment your workaround of a package.xml file that does include that type should get you working, and I'll provide a more seamless solution very soon.

Best regards,

Scott Wells

[Chris Stark]

Great, I'll be really curious about how that works! Appreciate the quick response as always Scott.

[Scott]

Chris, I've linked to your described scenario in that issue to ensure that I verify the correct/expected behavior before declaring victory.  Thanks for providing the details!

[Scott Wells]

FYI, I've delivered the fix for this in 1.7.9.2 that was released today.

Regards,

Scott