[SalesForce] Issue with GlobalDescribe Field Results and Managed Package

Situation:

  1. Managed Package
  2. Class is global class
  3. Field Named NS__Field_Name__c

  4. Running in subscriber org
    code:

      String fld = 'NS_Field_Name__c'; 
  Map<String,sobjectField> flds = object__c.sobjecttype.getDescribe().fields.getMap();
  Boolean test1 = flds.containsKey(fld);
  Boolean test2 = flds.containsKey(fld.replace('NS__',''));

In the above the result of

test1 = FALSE

test2 = TRUE

What is going on??? Why do I have to remove the namespace for the field to be found? When doing merge fields etc the name space MUST be included…..

Yes, all subscriber custom fields still show up in the field map.

To make it even worse, since subscriber (local) field show up, if the subscriber creates a field with the same name, then the Display Types are messed up because the field only shows up ONCE in the map…

Additionally this actually returns the value of the field yet the field describe says this field does not exist

    objectRecord.get('NS_Field_Name__c')

How can a developer dynamically get fields identified by the subscriber from the package to get describe information if the namespace has to be removed….

(Use case, custom merge documents where the subscriber uses field API Names including namespace to display information. Display types is used for formatting)

Is this a bug???

@sfdcfox –

If I have a field of type DATE – NS__Field__c
Customer creates a field of type BOLEAN Field__c

When I in the namespaced managed package get the field map the DisplayType of the field obtained using Field__c comes back as BOOLEAN instead of my namespaced type of Date.

@Daniel & @sfdcfox

It seems that it is documented so it is not a bug. However, when a package is installed in a subscriber org a field in their org with the same name will cause issues with the getMap() method since there is no namespace for their org.

Daniel was kind enough to point out the last paragraphs of the following document:

http://www.salesforce.com/us/developer/docs/dbcom_apex230/Content/apex_dynamic_describe_objects_understanding.htm#apex_describe_object_all_fields

Thanks for the discussion, not really solved as the problem is still there, but it is a documented problem…..

Cheers.

Best Answer

This isn't a bug. It's working as documented. Fields and objects do not return their namespace when code from the same namespace calls it. It's a type of scoping mechanism. And yes, subscribers that build a field that duplicates one of your fields will find that your code cannot access it, query it, or in any way interact with it, short of calling the REST or SOAP API without the namespace. And, for the record, you should not be using the namespace for merge fields within your package, but the subscriber would need to use the namespace in their own org's configuration (e.g. validation rules).

The mechanism is meant to protect your code from changes that subscribers might do to break your code (e.g. create a field without a namespace that your code references of the wrong data type, suddenly causing your code to get confused and crash). However, that protection comes at a cost, and that cost is a bit of inaccessibility (shadowing objects and fields), and a bit of confusion. All you need to remember is that your namespace should not be referenced in your code anywhere. Your code is walled off from the subscriber's configuration (more or less), so any request for anything that comes from your own package will always belong to your package.

There are a few obscure namespace bugs, though, that I don't think they've ever sorted out. Notably, "bare" merge fields need to have namespace references in Visualforce pages, but those that are inside tags, like apex:outputText, will be magically patched when it arrives in the subscriber org. Try looking at the source for a Visualforce page in a subscriber org and you'll see what I'm talking about. Your namespace will magically appear in the merge field, even when it was not in the original source.

Related Topic