10

When retrieving profiles for custom objects in a project.xml manifest, the returned profiles do not contain the objectPermissions object for objects that they do not have access to (ie no CRUD permission).

Steps to reproduce:

  • Open a force.com developer edition instance
  • Create an object named Object__c.
  • Create a profile named Profile without any access to Object__c.
  • Retrieve from metadata API (v.28 / eclipse) using the following

package.xml:

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

See that the profile received is as follows:

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

Before the Winter 14 upgrade, the profile contained:

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

Enable read access to the Object__c object for Profile.

Refresh from server, and see that the profile now contains:

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

It seems that since Winter 14 the objectPermissions tag for an object is not retrieved in the profile when the profile has no access to the object.

I have reported this to salesforce who have informed me that it is by design. (And was changed to bring the behaviour into line with permission sets).

I find this behaviour difficult to manage when working with source control. If I remove access to an object from a profile, then when the profile is retrieved to Eclipse it is simply missing the tags, and I have to manually create and commit the tags which set everything to false in order to push this profile change to another environment. Then the next time I refresh from the server in Eclipse, my working directory is full of uncommitted changes as git recongnises my manually created changes as deleted. But if I don't manually create them, then the changes will not be propagated.

Has anyone else encountered this issue, and found a workaround or way of managing it?

Am I alone in feeling that it is a regression, especially as the rest of the objects retrieved in a profile are consistent, e.g. apex class access / vf page access / field permissions all contain all object specified in the package.xml, and not just those with access enabled.

1
  • I agree - this change significantly increases the overhead of profile maintenance. If anyone has found any workaround, please share it.
    – user5323
    Jan 16, 2014 at 11:28

1 Answer 1

1

Take a look at the documentation: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_profile.htm

Indicates which objects are accessible to a user assigned to this profile, and the kind of access available (create, read, edit, delete, and so on). In API version 28.0 and later, this field is only retrieved when allowRead is true.

There is an app on the appExchange called Copado (https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR) that handles profile and permission set deployments really well. You can also deploy false values with the app.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .