Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Does the Modify All Data or View All Data permission allow a user/profile to ignore the FLS settings for an object? The documentation would seem to suggest that this is the case, but I've found conflicting results.

Using Schema.SObjectField.getDescribe().isUpdateable() to perform a FLS check will return return false if the 'Edit' permission isn't granted for the field. This behavior holds while running as a user with the View All Data or Modify All Data permission.

This would seem to indicate that FLS is independent from the Modify All Data and View All Data permissions. However, I can write a unit test that runs as a user with the Modify All Data and successfully perform an update to the field that the FLS check said wasn't updatable.

share|improve this question

4 Answers 4

up vote 5 down vote accepted

Modify All Data and View All Data do not, in any way, affect Field Level Security. The only permission that affects Field Level Security is Edit Read Only Fields. Apex Code generally ignores Field Level Security, while Visualforce generally honors Field Level Security. This is the reason why the "isAccessible" calls are available. The "with sharing" and "without sharing" keywords refer to record visibility and record editablity, not field accessibility.

share|improve this answer

It's worth noting that apex does not enforce field level security, even if run with sharing. Typically visualforce handles enforcement of these for you by doing things like not rendering apex:inputField or apex:outputField tags referencing a field the user has no FLS access to.

This automatic enforcement of FLS is only done at the presentation layer by the platform, enforcing it within apex contexts must be done explicitly in your classes (with isAccessible(), isUpdatable(), etc) if you want it to be done at all.

Thus regardless of the running user's access to a field your apex tests would be allowed to read and write said field.

share|improve this answer
    
Good point--this is the reason I'm writing security checks for my APEX code in the first place. I thought using the RunAs() method would enforce user permissions, but it's simply running the code under a specific user or profiles context. –  csnullptr Mar 16 at 23:34
    
@csnullptr runAs does, or at least should, enforce running user's permissions. If it's not I'd classify it as a platform bug (of which I've stumbled into a couple when using runAs) –  ca_peterson Mar 16 at 23:36
    
It does enforce sharing permissions! FLS is something you check. Think of Apex Code like Workflow rules. They can modify fields users have no access to, but not records the user has no access to. –  sfdcfox Mar 17 at 0:30

Yes. MAD and VAD override anything else. However, in general, when writing tests, I never assume that a user has MAD or VAD, as I create a new user for each test and run as that user.

The exception is when one wants to access the Organization object, which requires VAD, but here I digress...

share|improve this answer
    
MAD doesn't override FLS. Apex Code simply happens to not enforce it. POC: Set up a profile with MAD, but not EROF (Edit Read Only Fields). Make a field read-only, then try to edit that field through the UI. You can't. But, you can still run Apex Code that could modify the field's value. –  sfdcfox Mar 17 at 0:21
    
@sfdcfox: I actually just tried this prior to seeing your post and came to the same conclusion. –  csnullptr Mar 17 at 0:40

Yes, this is one of the reasons that I normally ratchet down all record access and functionality for ALL users to start with and then "build up" based upon their requirements (leveraging profiles, roles, permission sets and sharing rules). This normally starts by removing MAD and VAD.

For me the only exception to this would be some form of Administrator account.

Some security options such as MAD and VAD are quite often too powerful and I shy away from using them.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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