[SalesForce] Profile Metadata Question – False User permissions

One of our QA steps for our release process, is to identify if configuration changes have happened in production, that may have effected our repository metadata, specifically in Profiles.

While evaluating the metadata, we discovered that when you pull the profile metadata (using Eclipse in this case) the <userPermissions> XML section ONLY displays the settings where <enabled>true<true>. The table that stores these settings hold boolean values for all of the settings, so it's not as though the data doesn't exist. In addition, other sections of the file, DOES show 'false' settings.

For example, the following code exists in the file.

<userPermissions>
        <enabled>true</enabled>
        <name>CreateCustomizeReports</name>
</userPermissions>

However, there no example of something like the following:

<userPermissions>
        <enabled>false</enabled>
        <name>CreateTopics</name>
</userPermissions>

Finally, here is an example of an false tag that DOES exist in the file.

<classAccesses>
        <apexClass>AccountTriggerCrossDivSecurityTest</apexClass>
        <enabled>false</enabled>
    </classAccesses>

So the question is, is there a setting or hack for Eclipse, or a perhaps a different tool we should use, that will pull ALL of the XML tags, regardless of true or false, so that we have a complete file for our comparisons?

Best Answer

The Force.com IDE and others use the response handed back from the Metadata API directly. The API itself doesn't return (most) false user permissions. These little nuances can cause problems, especially if you're trying to SVN your profile permissions or want to apply negative profile changes (e.g. removing a permission the user previously had) that was applied in a Sandbox. Generally, the only safe way to deploy profiles are by Change Sets to guarantee that the permissions are correct. Even worse, there's not a comprehensive list of all permissions that are possible, since not all organizations will have all permissions (e.g. you can't use the Single Sign On User permission unless you have Delegated Authorization in your organization). There doesn't even seem to be an Idea for this right now, but perhaps some day they'll include a way to either list all available permissions in an org, or revert back to returning all user permissions when a profile is retrieved.

Related Topic