0

I've created a custom profile for SF admins in our org. There are fields on every object that the profile doesn't have read access to because of field level security.

Rather than going through the profile editing UI on SF and changing field permissions on each object, I thought I'd download the profile metadata using my IDE (mavensmate on sublime), and just edit the field permissions.

the *.profile metadata includes a bunch of different tag categories, such as

<classAccesses>
<fieldPermissions>
<objectPermissions>
<recordTypeVisibilities>

etc.

A typical fieldPermissions entry looks like this: 

<fieldPermissions>
    <editable>false</editable>
    <field>Contract.Contract_End_Date_New__c</field>
    <readable>false</readable>
</fieldPermissions>

That 'readable' attribute is unique to the fieldPermissions category, so I figured I could do a 'search and replace all' and replace all instances of <readable>false</readable> with <readable>true</readable>.

When I attempted to save my changes directly into production, the profile seemed to save successfully.. but when I pulled the metadata file again, all tag categories had disappeared from the metadata file except the <userPermissions> category! There was no metadata on field permissions, object permissions, anything.

And the wierd thing was that those permissions were still correct and visible via the profile UI - it's disappeared from the metadata but it still seems to be retained by the system!

Anyone have any idea what's going on here?

Improve this question
2
  • Have you created new fields in our sandbox ? And did you tried to deploy those fields? Or the fields existed in production already ?
    – Mihai Neagoe
    Aug 24, 2015 at 16:42
  • @MihaiNeagoe I didn't deploy the profile metadata from sandbox, I edited it directly in production. It seems like deployment from sandbox isn't necessary for profile changes (given that you can make them in production using UI).
    – smohyee
    Aug 24, 2015 at 18:44

1 Answer 1

Reset to default
2

There is an exceptional default behavior of Metadata Type Profile:

It does not retrieve permissions which have false value in it.

In your case you are doing the same, you are setting the permission false and it would disappear from the profile then.

One more exception:

Profile permissions like field, custom object, Apex classes etc only retrieved if those associated metadata types are also part of same payload request. So, you need to retrieve custom object with profile to get that custom object permission in profile xml.

Improve this answer
5
  • I'm not seeing the exceptional behavior you describe - when I look at my actual profile metadata, they do contain listed permissions set to false. It's only once I attempt to set them to true that the permissions disappear from the metadata. Regarding the second exception, I am pulling all metadata within this same request, so that shouldn't be a problem.
    – smohyee
    Aug 24, 2015 at 18:46
  • Well your approach is correct then. If all permissions disappear except user permission then can you check that auto-update package or retrieve flag is not creating this problem when you send deploy request. @smohyee
    – Ashwani
    Aug 24, 2015 at 18:54
  • @smohyee i should have ask you first, how are you doing these ? IDE or custom apex code
    – Ashwani
    Aug 24, 2015 at 18:56
  • IDE (mavensmate on sublime). I suppose I can attempt to debug the deployment package being sent from my IDE, but I would assume its deploying the metadata exactly as I've saved it prior to deployment.
    – smohyee
    Aug 24, 2015 at 19:06
  • @smohyee sublime still have many bugs.. so it may not support the correct way of handling all metadata types, especially profiles. But cant say officially. But I am using it for months.
    – Ashwani
    Aug 24, 2015 at 19:09

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.