System.Location confused with new Location entity (Schema.Location)

[Michael Hoefer]

We have a new entity called Location (Schema.Location), which conflicts with the apex object Location (System.Location)

‌

Repro:

API version 48.0

insert new Schema.Location(Name = 'California');   

Result:

Syntax/parse error: Expected type [SObject, List<SObject>]; found [Location, Schema.Location]

Using just new Location() should not and does not work. But Schema.Location should work, does compile in SFDC, but shows the error in IC.

[Scott Wells]

Thanks, Michael. These types of order-of-precedence for symbol resolution--especially when implicit namespaces like System and Schema come into play--can be tricky. I'll take a look at the resolution strategy shortly and update it accordingly.

[Scott Wells]

Issue #1795 was marked as a duplicate of this issue.

[Scott Wells]

Fix committed for inclusion in the next build (currently targeting Thursday morning).

[Scott Wells]

Delivered in 2.1.6.9.

[Scott Wells]

Michael, this wasn't quite addressed in the previous build. I've implemented some changes for the next one that get much, much closer. I've verified those changes with System.Site vs Schema.Site, but I don't have access to an org with the Schema.Location object. Is there an easy way to spin up a scratch org with that object via features/settings? I'd like to see how these changes hold up with that object as well if possible.

[Michael Hoefer]

Hey Scott. You can use the "WorkplaceCommandCenterUser" feature. This enables the new Work.com employee experience entities, and pulls in Location as well.

[Scott Wells]

Thanks, Michael. I'll set one up and make sure it takes care of this resolution ambiguity.

[Scott Wells]

Created a scratch org with that setting. With the changes I've made for the next feature build, this all works properly:

insert new Schema.Location(Name = 'California');
Location loc = Location.newInstance(10.0, 20.0);
System.debug(loc.getLatitude());

I was concerned that insert new Location(Name = 'California') would also need to resolve to Schema.Location, but turns out that both IC2 and the Apex compiler resolve that as System.Location, so all good there as long as you qualify the SObject as Schema.Location even though Schema is an otherwise implicit namespace.

Because of the release of the 2021.1 JetBrains IDEs this week, the next feature release will be next week.

[Scott Wells]

Reopening to track the proper fix as delivered with the next build.

[Scott Wells]

Another dumb question for you, Michael. Can I enable this feature in an existing DE org? If so, any tips on how to do so?

[Michael Hoefer]

It should already be available on DE orgs by default. Are you not seeing it on a newish one?

[Scott Wells]

Oh, this is my pet DE org from 5-6 years ago. I have perhaps 3-4 static orgs with various things deployed to them, and of course another 5-6 scratch orgs with other test projects such as NPSP, fflib, etc. I just happen to be very fond of this particular one and wanted to have the feature enabled in it if possible. However, I don't see the Schema.Location SObject, nor do I see anywhere to turn on anything Work.com related. No big thing if I can't in this old org, though.

[Michael Hoefer]

Yep, that makes sense. When new licenses are added to the DE template it doesn’t affect existing orgs, only new ones. We exposed Location with the Work.com feature last Summer. It can be enabled manually though, if you share the org id I can get that done for you.

[Scott Wells]

Sure, I'll take you up on that. The org ID is 00D2E000001HHwOUAW. Let me know if you need anything else. Thanks!

[Michael Hoefer]

This turned out to be a ball of red tape. Not likely to work out…

[Scott Wells]

No problem at all. I can certainly do this in scratch orgs. Thanks for checking!

[Scott Wells]

Delivered in 2.1.7.2. Requires OST regeneration.