Autocomplete fieldnames for sObjects in managed packages

[Alexander Johannes]

We are working with code in manged packages. Each developer has its own devorg with its unique namspace prefix (e.g. DEV_NS1). There is also a central staging devorg with its unique namespace prefix (PROD_NS1). If a developer uses the autocomplete feature of IC, all custom objects and fields are getting prefixed with the namespace prefix of his devorg:

DEV_NS1__Object__c obj = new DEV_NS1__Object__c(
  Name = 'Foo',
  DEV_NS1__CustomField__c = 'Bar'
);

The resulting code cannot be integrated to the central staging org, because the namespace of the sObject and its custom fields is different (e.g. PROD_NS1).

The easy solution would be to omit the namespace prefix in classes of the same package:

Object__c obj = new Object__c(
  Name = 'Foo',
  CustomField__c = 'Bar'
);

We would like to see support for that. If it needs to be simple, then just add an configuration option, to always omit the namespace prefix. Because it is easier for us to add a missing prefix (happens almost never), than deleting the extra prefix after each autocomplete (happens almost every time).

[Scott Wells]

Alexander, IC supports exactly this model. In my day job I'm an ISV developing five managed packages with complex base/extension relationships, so one of the things I built into IC from the get-go was a deep understanding of namespaces and when to include/omit them. It's important that you do configure things properly for this to work, though, and I haven't documented that configuration very well since in reality it seems to apply to a smaller set of users.

Let me start with this picture as I think it will help the explanation:

That's a little more complicated than what you're doing, but it should help frame things. In this scenario I'm developing code for two different managed packages in a single development org. One package has an official namespace of base and the other has an official namespace of ext. The ext package extends the base package. As a result, when you're developing you'd expect any references to source in the base package from source in the base package not to require any namespace qualification (and similar with ext references in ext source), but any references to base stuff from the ext stuff must be qualified.

To support that behavior, you can see that in the Advanced section I've specified that the source code for base is in one module, base_package, and that module's source should get deployed into the org under the Base Package development package; similarly the source code for ext is in a second module, ext_package, and that module's source should get deployed into the org under the Extension Package development package.

Because this is my own dev org, I had to register a unique namespace, in this case base_dev as the value for Organization Namespace. Once configured this way, Illuminated Cloud will also automatically translate official namespace qualifications to "local" namespace qualifications on deployment and vice-versa on retrieval. It's worth pointing out that on retrieval, some of the namespace qualifications may be stripped by Salesforce since it doesn't think they're actually required, so exercise caution on retrieval if you're doing this type of multi-package development in a single dev org. If you're just developing for a single package, the configuration above will keep IC from adding namespace qualificaitons on completions so that issue will go away entirely.

Why don't you digest that and see if you can get it configured so that IC doesn't add unnecessary namespace qualifications? It sounds like that will address your concern here. If you're not able to get it working that way, let me know and I'll provide more guidance.

[Scott Wells]

Oh, I should mention that after you reconfigure things, you should regenerate your OST since it will use that configuration info when generating.

[Alexander Johannes]

Scott, your explanation was very helpful. After manually setting the namespace for the managed package and recreating the OST, autocomplete is working as expected. The namespace prefix is getting omitted for local code/local sObjects.

Is it possible to auto-configure that setting, when creating a new project? Or is the local namspace prefix unknown to IC?

[Scott Wells]

Glad that worked for you. Yes, I have a set of pretty extensive changes to how connections are managed in-flight right now (allowing them to be shared across projects), and as part of that I'm always retrieving/populating the Organization Namespace when credentials are successfully entered, then defaulting the value for Namespace to the same as Organization Namespace when modules are configured for that connection. Obviously if the official namespace should be different as in your case, you'd have to edit it, but I have no way of guessing what that would be based only on the connected dev org.

[Scott Wells]

Going to resolve this since it sounds like you're good to go.

[Ruslan Kurchenko]

Hi @RoseSilverSoftware, I have the same issue.

I have the DE Org with the installed namespace and I need to omit this namespace autocompletion while working with IC. Could you explain how it should be done with new IC version (1.7.8)?

[Scott Wells]

Ruslan, this configuration is vastly simplified starting with the version I released yesterday (1.7.8.0). When you use a connection that has an assigned namespace, you should see something like the following in the project-level IC configuration:

Notice the value for Organization Namespace which is derived from the connection. If you're not seeing a value there, open the connection settings and click the Test button which will test the credentials and then, on successful login, retrieve the organization namespace. Note that the value for Official Namespace is the same as the value for Organization Namespace, but notice also that it's blue. That's because I didn't specify that value so it defaulted to the same as Organization Namespace for me.

If you had to change any config to get your connection looking like that, make sure to generate your OST. This is because the namespace configuration is taken into account during OST generation when IC decides whether to generate stub Apex classes for things in the org based on whether they're also present locally.

Please let me know if this explanation doesn't get it working the way you want.

[Ruslan Kurchenko]

Scott, the configuration window is exactly as you shared, but how can I actually configure setting to use any namespace, just plain SObject/SObject fields/Classes names?

[Scott Wells]

Ruslan, I apologize but I'm not 100% sure what behavior you're wanting. Let me explain how various settings in that window work and perhaps that will help.

If your Organization Namespace is base_dev and you leave the value for Official Namespace blank, as I mentioned the value is implicitly the same...base_dev. Once you generate your OST you'll find a subdirectory, base_dev, containing stub Apex classes for all of your custom SObjects. If you then try to complete a class from your project, it will be displayed in the completion dialog with namespace base_dev but will not prefix with that namespace. If you try to complete a custom SObject from your project, same thing...it will be displayed in the completion dialog with namespace base_dev but will complete with no namespace prefix. Same with custom SObject fields.

If your Organization Namespace is base_dev and you set the value for Official Namespace to something else, e.g., base, what you're doing is saying "I'm developing content for managed package base, but my personal dev org has namespace base_dev; please translate that for me." Once you generate your OST you'll find a subdirectory, base, containing stub Apex classes for all of your custom SObjects. If you then try to complete a class from your project, it will be displayed in the completion dialog with namespace base but will not prefix with that namespace. If you try to complete a custom SObject from your project, same thing...it will be displayed in the completion dialog with namespace base but will complete with no namespace prefix. Same with custom SObject fields.

If you're set up this way and are still seeing auto-completion prefixing your project's classes, SObjects, and fields, look in your OST and make sure you see the correct subdirectory for your configured namespace. If not, you should definitely regenerate your OST. Of course, if all of that looks correct and it's still not behaving properly, that's a bug. Please let me know and I'll get it fixed. The entire goal of this auto-prefixing of namespaces was to make Salesforce development easier, not to get in the way.

Regards, Scott

[Ruslan Kurchenko]

Scott, great explanation, thanks. The problem for me is that I can't set Official Namespace blank. When I try to double click on it to consequently edit, it opens modal with Connections settings.

[Scott Wells]

Ah, yes. You're right...I did miss one critical thing. In order to set a custom value for Official Namespace, right now you do need to create a development package in your org and choose that for the module. Here's another screenshot:

The reason that's the case is that I've optimized it right now for a much more complex use case of multi-package development in a single dev org. I'm glad we had this discussion because that shouldn't be required for the normal/simple use case where you're just trying to develop content for a single namespace. I'll fix that ASAP so that you don't need the development package, but for now you can get it working the way you want by creating a development package in your org and choosing it for the module. Thanks for bringing this to my attention!

[Scott Wells]

Ruslan, I just fixed this. In the next build you won't need to use a development package to set a value for official namespace.

[Ruslan Kurchenko]

Ok, I did exactly what you suggest me and here is the result:

I've created a Dummy package and chose it in the setting. Also, I set the Official Namespace to dummy, just for the test:

After generating OST I have the next Account object field prefix:

Ok, I think that it is an expected result, but when I've set the value of Official Namespace to blank:

And recreate OST from scratch, here is the result on the Account object, where you can see a prefix trnc1srk1__ that is based on Organization Namespace:

And it is not that I expected.

Please, correct me if I doing something :) Thanks.

[Scott Wells]

Ah, okay. I see what you're referring to now. You're talking about the custom fields on standard objects being prefixed. You know...I think that may be an oversight in all of this, though I'd need to confirm it. I believe I'm fully-qualifying those right now to be clear about the namespace vs. the default namespace for standard objects/fields, but the completion is going to be the entire string even in that namespace. Let me look into that as well. I think I still want to generate it into the OST that way, but when you reference it in your own code, it should offer an unqualified completion if that's appropriate. More to come on this, though likely later today as I have a few meetings starting soon.

[Ruslan Kurchenko]

I think that with custom objects it is work as expected... Ok, I will wait for your next comments. Thank you for your job, IC really nice!

[Scott Wells]

Okay, I think I have this completely fixed now. It'll be in the next build.

[Ruslan Kurchenko]

Great, thanks:)

Waiting for it!

[Scott Wells]

Delivered in 1.7.8.1. Please let me know if it's not working as expected now.