1

I'm trying to build a "no permissions" baseline profile in a sandbox I just spun up from my production org before playing with a new integration (so I can assign permissions in a "least privilege" way).

I got all the object-level CRUD turned off for every object, but when I go into the field-level permissions for each object with that new profile -- be it in the web-based Setup panel or within Welkin Suite -- there are fields that are editable or readable.

Cool, cool ... I want to blast those all away, too, as a "belt and suspenders" kind of thing.

Editing them in web or Welkin propagates the change to the other, but I'm getting sick of going object by object.

In theory, these are all just fieldPermissions tags in the NewProfile.profile XML file that should be on my hard drive (thanks to having all profiles in my package.xml). I should be able to open Notepad++, erase them all, and deploy it back to Salesforce ... done.

In practice, there're no such tags in that file.

In fact, I did a file search on my hard drive in the entire folder I downloaded all the XML files into for an unusually named custom field that was showing up editable for a custom object (yes, the object itself is "None" access), and there's nothing on my hard drive mentioning that field at all.

  1. Where are they, if not in the Profile XML file? They're somewhere if Welkin can see that this new profile has the ability to view all fields on Contact, for example...
  2. How do I get around this problem and turn off all those field-by-field viewability issues in one fell swoop?

Note: No SFDX or anything going on here, just classic org-based development.

Improve this question
3
  • 1
    You'll need to include all of your CustomObjects in the package.xml in which you retrieve all Profiles, since Profiles files don't come with any field/objectPermissions attributes when you retrieve unless you include those objects/fields in the same package.xml. Relatedly, deploying .profile metadata without attributes for field/objectPermissions won't remove the Profile's field/object permissions. In order to make those "destructive" changes to the profile, you'll need to change the field/objectPermissions to false, e.g. <readable>false</readable> and <allowCreate>false</allowCreate
    – Brent Bowers
    Aug 22, 2019 at 17:20
  • Okay, so I actually already did step 1 (probably why Welkin can see the field permissions), but if I want to roll my own "none-er," I'll need to loop over all those objects' XML, grab a list of fields, and build a HUGE profile.xml to push?
    – k..
    Aug 22, 2019 at 17:28
  • Yes, you will need to fetch all objects, classes, pages, layouts, applications, tabs along with profile(s) to get a full matrix. Then you have to iterate through them to turn it all off before deploying them. The sucky part, however, will be that if/ when you retrieve this "none-er" profile XML again, a lot of the XML will be left behind as some parts of Profiles are sparse. Instead of creating this "none-er" profile, have you considered the supposed to be baseline Standard User or Standard Platform User profile?
    – Sridhar
    Aug 22, 2019 at 21:07

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .