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.