Are profile and permission set metadata files getting all project objectPermissions?

Question

I have a project in development. There about 45 new SObjects to the org but there is also a couple of new profiles for the org. The permissions on several existing SObjects have been specifically setup for these new profiles.

Now I need to migrate these changes to the test sandbox. In this case, there is a large amount of code and configuration changes to be deployed as part of the effort. Because of this, the decision was made to utilize the SFDC ANT migration tool to migrate these changes instead of SFDC Change Sets. Since we are using MavensMate and Force.com IDE as our code editors, the package.xml for the project elements can be maintained easily.

In my case, I have a total of 108 SObjects setup in my package.xml. The reason for this was grab all of the objects (new or old) where we have have made some sort of object permission level change to the new profiles.

Here is the issue. The metadata extracted from the development org for the profiles only has a random number of entries in it. It does not have the complete list of SObjects. The permission sets also have a random list of tags and it does not appear to be consistent between various profiles or permission sets.

I have even tried using the ANT Force.com Migration Tool's sf:retrieve target but the results are the same.

Has anyone seen this behavior before?

Is this a bug or is there some obscure rule in the Metadata API / Tooling API that is driving this behavior?

Any suggestions on how to correct / workaround this issue?

Thanks for all the help.

Cheers!

John

Answer 1

this is not a solution, just a comment, as I do not have enough reputation to post comments.

When you retrieve profiles, does you package.xml also include relevant objects? The reason for this question is that retrieving Profiles only works properly when you specify objects and fields in the same request. i.e. if you retrieve objects first, and then profiles then you will not get full profile information. See "fields" section here: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_profile.htm#heading_2_

The content of a profile returned by Metadata API depends on the content requested in the RetrieveRequest message. For example, profiles only include field-level security for fields included in custom objects returned in the same RetrieveRequest as the profiles

Answer 2

In the end, this turned out to be an issue where the SObjects that were missing from the metadata had their objectPermissions set to no CRUD permissions at all.

It turns out that when a profile has no CRUD permissions on a SObject, the metadata for that profile will not contain any reference to that SObject at all. This is true for both profiles and permission sets.

I suspect that this is "feature" because a profile and permission set cannot be used to reduce the amount privileges on a SObject when deployed to another environment. This is true regardless of using the ANT Migration tool, Eclipse Force.com IDE, MavensMate IDE, or SFDC Change Sets.

My issue was that I was trying to introduce a new profile to an environment and was trying to restrict access on certain pre-existing SObjects via a profile deployment. That won't work and I need to deploy the profile and manually set the CRUD permissions on that profile instead.

Answer 3

@johnDTheMaven is not too far off.

You can get a better sense of what's supported and how profiles/permission sets behave with the Metadata API through the SalesforceHacker blog posting - Dude, Where's My Permission.

The short answer here is that we try to retrieve only enabled permissions through the Metadata API. This helps reduce the size of the .profile or .permissionset file and also keeps the focus on what the user has rather than what they don't.

Keep in mind that retrieve is very different from deploy where permissions are concerned. Retrieve has specific behaviors, many of which require a junction object in the payload to retrieve 'custom' permission settings (e.g. Foo__c CRUD will be retrieved only if the Foo__c custom object is also in the package.xml/payload). As a result, custom permissions in particular will only be retrieved if there is both an enabled permission and the junction object is specified in the manifest. Also, keep in mind, if an object has many permissions, we expect the least of them (Read in the case of a custom object) to define whether we return the entire object entry.

However, deployment doesn't require the concept of junction. I can declare whatever permission I want (e.g. Foo__c CRUD = false across all permissions). As a result, If I create a prototypical profile or permission set with all permissions enabled and retrieve it, I know know the syntax of all permissions that are allowed within my deployment. I can now define something like Foo__c CRUD = false across all CRUD permissions for that object and when I deploy it, I will revoke all Foo_c CRUD in my target org.

Answer 4

Yes. I was having the same problem and I confirm that retrieving a profile will skip any reference to an object that has no permissions granted in the source org. So far so good, but the real issue comes when you deploy that profile to another org, then all objects that has no object Permissions defined in the xml will default to full access (read, edit and create) which for me is a security problem. And also very inefficient since implies manual tasks. There is a great solution, Copado Deployer, https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR, which has something call "Full profiles" deployments, that will take care of everything and copy a profile from one org to another, even when orgs has differences in terms of objects, fields, etc.

worth take a look. It actually solves the problem.