Getting false result when using Schema.SObjectField

Question

I am using Schema.SobjectField to get all the fields of Account object.

I am getting correct result in my development org. But when i add the class in a package and install it in another sf org, i am not getting correct fields result.

Let me explain where i getting wrong result:

Ex:My package abc contain a custom field (let say xyz_c for account object). My subscribing org also containing the same field (xyz_c) but both are differ with respect to namespace prefix as package field Api name becomes abc_xyz_c after installation. When my code is executed like this:

//....................Some code......................
List<String,String> fieldList = new List<String,String>();
Map<String,Schema.SObjectType> gd = Schema.getGlobalDescribe();
Map <String, Schema.SObjectField> fieldMap = gd.get('Account').getDescribe().fields.getMap();
for(Schema.SObjectField sfield : fieldMap.Values()){
     schema.describefieldresult dfield = sfield.getDescribe();    
     String name = dfield.getname();
     String label =dfield.getLabel();
     fieldList.add(name,label);
}
//.....................Some code.....................

The resultant fieldList showing all the fields including abc_xyz_c except xyz_c (which is the subscribing org existing field).

Can anybody help me why it is working like this and how can i resolve this issue?

Answer 1

There is no way to access an organization's field that has the same name as the managed package. This applies to custom fields on standard objects, and custom fields on custom objects that your package references that also have the same name as the managed package. For example, if you have a managed package with a field called Foo__c on an object called Bar__c, and the administrator creates another field called Foo__c on your object after installation, then the organization's field will not be available. Surprise when "Accessing All Field Describe Results for an SObject" in a managed package is one such blog entry where someone else discovered this behavior.

The behavior has also been mentioned in the salesforce.com documentation, but I cannot seem to find it right now. I've also mentioned this previously on other questions here at SFSE, as I myself have encountered the issue. I once heard that this is on the roadmap to be fixed, but, of course, finding anything about salesforce.com's roadmap is fleeting, at best. The only solution at the moment is to tell your clients that they must change the name of the custom field so it does not conflict with the name in your package.