Can I restrict a client System Administrator field access in a managed package?

Question

I'm writing a managed package, and I'm using a number of fields that are controlled by the system and written to from apex.

Of course, I can restrict access to the fields via a profile, but I don't know how this works with System Administrators in the client's org.

My question is: If I mark a field in my Managed Package as readonly to a system administrator profile, and subsequently deploy that profile when installing the package in a Client's org: Will the system administrator be able to write to that field?

Additionally: Will the client org be able to write their own apex to write to that field?

How do you guys deal with this?

thanks -JN

Answer 1

I'm seeing two issues (one in your question and one raised by @sfdcfox):

For the custom roll-up field, you can combat this by putting a trigger on the CHILD (rolled-up) object and one on the PARENT (holding the field) object. You would definitely need to worry about recursion, so plan on having a class with a static boolean to avoid that, but it can be done. Then, any time someone edits that field, it just resets to its proper value.

For the issue sfdcfox raised, that's a use-case for custom settings. I like to make a List setting with the following fields: ValueBoolean__c, ValueText__c, etc. Then just store whatever you want in a key-value fashion.

Answer 2

The person that installs a managed package will determine the field level security during installation (and anybody with "View Setup and Configuration" + "Manage users" can subsequently change these). So you won't be able to protect your fields that way.

Plus generally sysadmins bypass the field level security anyway because of the "modify all data".

Generally I think that when admin wants to do something, he'll find a way. It would help if you'd write why you want to protect some stuff, what's your scenario.

If it's a custom setting - you can mark it as hidden. Could be handy if you intend to charge by amount of records created or something like that...

One thing that comes to mind is to have a helper class with static Boolean flag. Then in every controller you have - set this flag before doing any DML. And make the triggers check that flag first and complain if one of your special fields is created / modified without that flag.

This will effectively mean the standard ways to create records (standard page layout, Data Loader, Chatter actions...) become useless and people are forced to use your VF page + controller (or maybe some global helper method you've exposed so client code can call it - you'd let them set only the fields you want).

But it sounds like a bad end user experience, I'm not sure whether what you're trying to do is "right". Remember that Force.com platform is successful because (among others of course) it's so extensible - and you want to lock your customers down.

Answer 3

I've developed a simple system to control the write access against certain fields, on certain records.

The primary class - WriteAccessControl. This class is instantiated with a set of restricted fields that can be checked against in your objects validator class/method.

public class WriteAccessControl{

//The fields that have Write restrictions
public set<string> Fields {
    get {
        if(Fields == null) {
            Fields = new set<string>();
        }
        return Fields;
    } private set;
}

//the storage of permissions against fields against ids
private map<id,map<string,boolean>> WriteMap {
    get {
        if(WriteMap == null) {
            WriteMap = new map<id,map<string,boolean>>();
        }
        return WriteMap;
    }
    set;
}

//Set the access of an id, and field
public void SetAccess(id pId, string pField, boolean pAccess) {
    if(Fields.Contains(pField.ToUpperCase())) {
        if(WriteMap.get(pId) == null) {
            WriteMap.put(pId, new map<string, boolean>());
        }
        WriteMap.get(pId).put(pField.ToUpperCase(),pAccess);
    } else {
        throw new JNHException(JNHSystem.MessageCodes.Get('WRITE_CONTROL100'),pField.ToUpperCase());
    }
}

//Get the write access of the field:
//  pass in the Id of the record in question, and the name of field
//  Get back a boolean of TRUE if the field can be written to, or FALSE if not
public boolean GetAccess(id pId, string pField) {
    system.debug('UDBG:::WriteAccessControl.GetAccess: ENTERED with id: ' + pId + ', and field: ' + pField);
    boolean b = false;
    system.debug('UDBG:::WriteAccessControl.GetAccess: fields are currently: ' + fields + '. Does it contain ' + pField.ToUpperCase() + '? ' + (Fields.Contains(pField.ToUpperCase())));
    if(Fields.Contains(pField.ToUpperCase())) {
        //Check that we are in the write map
        if(WriteMap.get(pId) != null) {
            //And check the field is in the list
            if(WriteMap.get(pId).get(pField.ToUpperCase()) != null) {
                //And finally the boolean
                b = WriteMap.get(pId).get(pField.ToUpperCase());
            }
        }
    } else {
        throw new JNHException(JNHSystem.MessageCodes.Get('WRITE_CONTROL100'),pField.ToUpperCase());
    }
    return b;
}

//Construct with your set of fields
public WriteAccessControl(set<string> pFields) {
    for(string s : pFields) {
        Fields.add(s.ToUpperCase());
    }
}

}

To instantiate this in your validator class:

public static JNHSystem.WriteAccessControl WriteAccessControl{
get {
    if(WriteAccessControl == null) {
        WriteAccessControl = new JNHSystem.WriteAccessControl(new set<string>{
            'MyCustomField__c',
            'MyOtherCustomField__c'
        });
    }
    return WriteAccessControl;
}
private set;
}

And finally, when you need to access this via a validating method at the end of your business automation:

//The following field(s) are not writable at this time
public void PO116(){
    for(integer i : Context.NewRecords.KeySet()) {
        for(string field : PurchaseOrder_val.WriteAccessControl.Fields) {
            if( ((Context.IsNew(i) && Context.GetRecord(i).Get(field) != null) ||
                (Context.Ischanged(i,field))) && !PurchaseOrder_val.WriteAccessControl.GetAccess(Context.GetRecord(i).Id, field)) {
                Context.GetRecord(i).AddError(
                    new JNHException(
                        GetMessageCode('PO116'),
                        field
                ),false);
            }
        }
    }
}

Don't be confused by the above method - I have a class that serializes triggers and gives me helpers like "IsNew" or "IsChanged". the principle is that you want to check all records in context, and what circumstances you deem necessary.

I hope others find this useful.