Incorrect SOQL/standard object fields handling

[Phil W]

I have the following query:

List<Site> sites = [SELECT Subdomain, UrlPathPrefix FROM Site WHERE Name LIKE '%Some%Value%' LIMIT 1]; // CRUD/FLS False Positive: This data is not displayed to the user.

This is followed by:

if (!sites.isEmpty()) {
    Organization org = [SELECT InstanceName, IsSandbox, OrganizationType FROM Organization]; // CRUD/FLS False Positive: This data is not displayed to the user.

    siteURL = 'https://' + sites[0].Subdomain + '.';
    siteURL += (org.IsSandbox || org.OrganizationType == 'Developer Edition' ?
            (org.InstanceName.toLowerCase() + '.') :
            '') +
            'force.com';

    if (String.isNotBlank(sites[0].UrlPathPrefix)) {
        siteURL += '/' + sites[0].UrlPathPrefix;
    }
} else {
    // Could not determine the site's URL. Give up quietly but in such a way that a repeat call
    // to this method in the current session will not perform any further queries
    siteURL = '';
}

I see the following errors reported by IC2:

Cannot resolve symbol 'Subdomain'

Cannot resolve symbol 'UrlPathPrefix'

Cannot resolve symbol 'UrlPathPrefix'

The editor shows:

Salesforce does not have any problem with this code.

[Scott Wells]

I believe this is the same issue as #1627 where the name Location is ambiguous because it occurs as an SObject in the implicit Schema namespace and as an Apex type in the implicit System namespace. I was actually going to work on that this week.

[Scott Wells]

I coincidentally committed a fix for this one just the other day, though not in the context of this bug. I happened to find the same issue in another project. The fix will be delivered in this week's build (typically Thursday morning).

[Scott Wells]

Well, turns out that the fixes in 2.1.6.9 do not completely address this. I'll keep working on it for the next build.

[Scott Wells]

More testing to do, but the next build should address this. It does so by properly moving the OST Apex stub classes for SObjects that are reported by the APIs without namespaces into the Schema namespace. As a result, an OST regeneration will be required by everyone after this next update.

[Scott Wells]

Delivered in 2.1.7.2. Requires OST regeneration.