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.


However, there no example of something like the following:


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


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?


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.

  • Here is the biggest problem with this approach. Consider this scenario: I have a permission, say CreateTopics set to true in Production. Then I turn it off in my UAT sandbox (which essentially removes that tag from the metadata response when I retrieve the userPermissions). Now, when I try to push that "updated" metadata to production, it will NEVER update CreateTopics permission (meaning it will never turn it off as the XML which sets it to false is missing. So, I am left to manually handle this by recognizing that this permission has been turned off. Hope this makes sense. -- Sridhar
    – Sridhar
    Jan 16 '15 at 17:56
  • 1
    Change Sets can turn off permissions. That gives them a big advantage over using the XML files. I'm working on a solution to this independently, because it's causing a big mess in our setup, too. We have some odd dozen sandboxes we try to keep in sync, and it's just not manageable as the solution exists today.
    – sfdcfox
    Jan 16 '15 at 18:35
  • There is an idea here to vote now - success.salesforce.com/ideaView?id=08730000000DnbFAAS May 31 '18 at 7:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.