Apex Code Development You need to sign in to do that
Don't have an account?
App Dev 18 Dynamic Apex access lost in new managed package
We created and published a managed package, this last version was released in Dec. 2015. From within this package we access both a Custom Settings object that we created as well as make calls to Schema.SObjectType.Contact.fields.getMap(). Everything works fine.
We just made modifications to this managed package. In these modifications we added a new Custom Settings object and we reference the Opportunity SObject to get its field information. The custom settings object is referenced from a class that existed in the original version of the application. The calls to get the Opportunity field information are made from both a previously existing class as well as a new class. None of the new calls work (new custom settings object and calls to get Opportunity field information), although the old calls (acces to the original custom field and calls to get Contact field information) continue to work fine.
Our application requires the non-profit service pack.
During my investigation I created a new managed package that gets the Opportunity field information via dynamic Apex. This code is in a controller behind a visual force page. When I upload this managed package into our test orgs, everything runs fine. When I copy this controller and visualforce page character-for-character into my existing managed package and load it into our test orgs, once again, nothing works.
Just to be clear, these dyanamic Apex calls do not produce and error, they simply return no field information.
In the past I would have expected that setting API_Access to Unrestricted would have solved this problem, however, it appearas that this setting has been removed in Summer 2016.
How do I get this access to work in my existing package. I do not want to create a new package as this will cause all sorts of upgrade problems for our customers.
We just made modifications to this managed package. In these modifications we added a new Custom Settings object and we reference the Opportunity SObject to get its field information. The custom settings object is referenced from a class that existed in the original version of the application. The calls to get the Opportunity field information are made from both a previously existing class as well as a new class. None of the new calls work (new custom settings object and calls to get Opportunity field information), although the old calls (acces to the original custom field and calls to get Contact field information) continue to work fine.
Our application requires the non-profit service pack.
During my investigation I created a new managed package that gets the Opportunity field information via dynamic Apex. This code is in a controller behind a visual force page. When I upload this managed package into our test orgs, everything runs fine. When I copy this controller and visualforce page character-for-character into my existing managed package and load it into our test orgs, once again, nothing works.
Just to be clear, these dyanamic Apex calls do not produce and error, they simply return no field information.
In the past I would have expected that setting API_Access to Unrestricted would have solved this problem, however, it appearas that this setting has been removed in Summer 2016.
How do I get this access to work in my existing package. I do not want to create a new package as this will cause all sorts of upgrade problems for our customers.
Have you checked that the API version of your controller in your new managed package coincide with the API version of the controller you have in your old managed package (the one not working)? Have you upgraded the API version of the class that was previously working?
There have been some changes related to namespaces. Concretelly, in API 29 (winter 14), SObject global describe map was changed to be keyed by DeveloperName, not LocalName: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dynamic_global_describe.htm#apex_dynamic_global_describe
Also in v34 (summer 15) there was another change. Previously, the keys in the fields describe map (e.g. SObjectType.Account.fields.getMap()) used local names as keys. Now, the keys are the qualified name, including namespaces. So if a managed package declares a field (e.g. xxx__MyField) and there is an unmanaged field with the same name (MyField), both fields will now be present in the map.
Can it be something related to these changes?
Regards.