1

I've installed a managed package (released version) on a sandbox and it doesn't work because Namespaces are not removed on the Custom fields API name from Lightning component controllers :

From my dev org or any enterprise org where I've installed the package, the app works just fine: Namespaces are removed on Custom fields API name when receiving data: Apex actions return Custom_field__c instead of Mynamespace__Custom_Field__c.

But when testing on Sandbox, namespaces are not removed and my app just crashes: Custom_Field__c is undefined everywhere I expect data from apex actions.

EDIT:

From my dev org this why i get:

...
    var results = a.getReturnvalue();
     var name = results.record.Custom_field_name__c
console.log(name) ; //display John Doe
... 

From a sandbox org, i get this

... 
var results = a.getReturnvalue();
     var name = results.record.Custom_field_name__c
console.log(name) ; //display undefined

And if i do console.log(results) from the dev org i have:

{record : {''Custom_field_name__c'': '' John Doe''}} 
... 

And from the sandbox...

{record : {''MyNameSpace__Custom_field_name__c'': '' John Doe''}} 

Could you please advise how I can solve this? Any advice will be very much appreciated! A 1000 thanks!

9
  • I'm not sure what is meant by namespaces being removed. I'm not familiar with anywhere in the platform where explicit namespace references are removed. Could you please add some code and a concrete example? – David Reed Mar 26 at 21:51
  • I've just edited the question with an example of code simplified. – Bryce Mar 26 at 22:59
  • Is the dev org in your question your packaging org? – David Reed Mar 26 at 23:15
  • Yes, dev org is the packaging org. I've been testing on 'a Enterprise edition org and it behaves the same as on the dev org: no namespace issue... – Bryce Mar 27 at 8:04
  • Do you mean Lightning Components in the package itself do not work? Or components added to the org? If the latter this is exactly what should happen. – Phil W Mar 27 at 8:14
2

The org edition or sandbox status is not what's determinative here. The key is how your code is installed: whether it is or is not installed as part of a managed package, and if not, whether or not you are in a packaging org.

In a context where your code is deployed unmanaged (not as part of a managed package, but simply a source deployment), including the packaging org and potentially other orgs where you deploy the bare source code, your code that references Custom_field_name__c will work just fine. This is not exactly because namespaces are removed, but because in that context either there is no namespace at all (some arbitrary org with unmanaged code) or because you're in an org that is inherently namespaced (packaging) and you've deployed your components without an explicit namespace.

When your code is installed in a managed package, your components are all namespaced, and are distinct from the components outside your managed package, which do not have a namespace. In some contexts, such as Apex code, the platform automatically resolves references to packaged components without a namespace to the correct namespaced component. However, the platform doesn't automatically munge field references in JavaScript to cope with the presence of the namespace. You can adopt one of several different strategies to manage this:

  1. You can include explicit namespace references in your code. This is explicitly endorsed in the Aura developer guide, although I personally disagree with this advice. Using explicit namespace references in your code means you cannot deploy it unmanaged to an org that does not itself have that namespace, limiting you to doing development in packaging (bad practice! don't do that!) or in namespaced scratch orgs.
  2. You can implement your Apex controller to do all communication with your JavaScript using an Apex wrapper class rather than actual sObject instances. Since the fields on Apex classes do not receive a namespace prefix, this can allow your code to be context-agnostic. Your Apex code would then be responsible for translating between wrapper instances and actual sObjects; in Apex code, the platform handles resolving references to your namespaced components appropriately.
  3. Your component can introspect the data it is working with to dynamically determine at runtime whether or not the sObjects with which it is interacting have a namespace prefix, and adjust field accesses accordingly. This makes your code resilient to run in both managed and unmanaged environments.
  4. You can build Lightning Web Components instead of Aura. LWCs don't completely remove the namespace problem, but they can make it easier because you can use imports to retrieve the schema and Apex class information from the platform, where namespaces are managed for you and it's easy to introspect against imported fields to determine whether they are namespaced.

Whatever you choose to do, it's critical to be clear about the managed code versus unmanaged code distinction.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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