SEL* is generating duplicate system fields in the field list

[Alan Birchenough]

Here is a field list generated into a query in the Apex editor using the SEL* live template:

SCMC__Active__c
SCMC__Address__c
SCMC__Create_New__c
CreatedById
CreatedById
CreatedDate
CreatedDate
CurrencyIsoCode
SCMC__Default__c
SCMC__Holding_Address__c
SCMC__ICP__c
Id
SCMC__ILS_List_Type__c
SCMC__ILSMart_Listing__c
IsDeleted
IsDeleted
LastActivityDate
LastModifiedById
LastModifiedById
LastModifiedDate
LastModifiedDate
LastReferencedDate
LastViewedDate
Name
Name
OwnerId
SCMC__RecordType__c
SystemModstamp

You can see that the following fields are duplicated:

CreatedById
CreatedDate
IsDeleted
LastModifiedById
LastModifiedDate
Name

This is causing compilation errors which I must fix by editing out the duplicate fields by hand.

[Scott Wells]

Wow, that's weird. Let me take a look at a fix I just put into IC2 and see if I also need to put it into IC1. Both of the problems you're seeing seem to be potentially related to SObject inheritance relationships, and that's exactly what I just fixed. More to come soon...

[Scott Wells]

It does look like IC1 should have the same fix. Creating a test build now of 1.8.1.6 with this fix that I'll attach here if you wouldn't mind seeing whether it helps with either/both of your reported issues. I'll attach the build with instructions on how to install very shortly.

[Scott Wells]

Okay, you can install this by downloading the .zip file and using Settings>Plugins>Install plugin from disk. You can always go back to the official build, and it won't prevent you from getting automatic updates. It's the exact same as 1.8.1.6 except that it includes a fix for an issue with how inheritance hierarchies are computed. Since all concrete SObject types are inherently part of a three-level inheritance hierarchy (type => SObject => Object), I'm curious to know whether this addresses the issues you're seeing.

After installing the IDE will need to restart, then it'll rebuild an index. You'd probably do well to rebuild your OST, but I don't think it's required.

Please let me know whether this test build addresses this issue and/or the other one around completion namespace prefixing.

Thanks!

[Alan Birchenough]

Thanks. I am currently on 1.8.1.6-idea14, BTW, but the pick list in BitBucket doesn't have that version for selection.

[Alan Birchenough]

Thanks. I will get back to you, hopefully today.

[Scott Wells]

Ah, thanks for letting me know. I'll add that version for selection. And as for timing, whenever is convenient for you. I appreciate you taking the time to report this stuff and hopefully help figure out whether this is a good fix or not!

[Alan Birchenough]

This was a definite improvement. I attach an XLSX file with the list of generated fields, where the ones that had to be removed before the query would compile are marked in red. You will see that:

• The duplication of LastModifiedById and CreatedById has been fixed. However, the fields CreatedBy and LastModifiedBy are not recognized in the context of a SOQL query field list;
• Lookups ending in underscore underscore "c" compile fine, but any generated counterparts ending in "r" do not;
• FirstPublishedLocation and Parent would not compile.

In case it helps, I have also attached the OST zip file itself.

I hope you will find this information useful in refining the behavior of this function. Please let me know if you have any further questions.

[Alan Birchenough]

Here's the OST after running with the ZIP-based plugin.

[Alan Birchenough]

Here is the XLSX with the generated and flagged field list in it.

[Scott Wells]

Alan, I'm taking a look. All of the remaining issues seem to be related to relationship fields that are being included in the SEL* expansion but should not be. Thanks for sending your OST as I should just be able to drop it into place to see if I can reproduce the issue using it. I've never seen this behavior before, but hopefully it's something very simple to diagnose and/or fix.

[Scott Wells]

Okay, so the problem is that your OST is missing some key SObjects, in particular User. As a result, IC isn't able to determine that a field like Owner which is of type User is in fact a reference to another SObject to omit it from the list of fields in the SEL* expansion.

The key question now is why your OST is missing so many key SObjects. I could provide a complete listing, but among others it's also missing Case, Document, EmailTemplate, Group, ListView, PermissionSet, UserRole, etc.

Do you know about any authorization restrictions your login might have that would prevent you from being able to "see" these SObjects via the API? That's the only thing that comes to mind right now.

If you'd like, you can enable debug logging during OST generation as documented here:

http://www.illuminatedcloud.com/support/debuglogging

regenerate at least the SObjects portion of the OST, and send that to me for review. My guess is that I just won't see these objects included in the API response from the server when listing SObjects, but at least that would confirm my suspicion about what's going on.

Please let me know how you'd like to proceed.

Regards, Scott

[Alan Birchenough]

I will check what level of access they gave me. Normally we insist on having the System Administrator profile during implementations, but clients sometimes try to nickel and dime us down to something less capable, usually with bad results.

If my profile is System Administrator I could try logging during OST generation as you suggest.

[Scott Wells]

Okay, let me know. I'm 99% sure that's what's happening here. There are just too many standard SObjects omitted from your OST. Oh, and Sys Admin by itself won't give you access. The objects/fields also need to be visible to your user either via profile or permission set. File under the category of "when is sys admin not sys admin"...

[Scott Wells]

Any update on this, Alan? Seemed to be a config/perms issue when we last chatted, but I figured I'd check in before resolving it.

[Alan Birchenough]

Yes, I have been heavily multitasking and did not have a chance to close the loop on it. Please give me one more day to report back.

Thanks.

[Scott Wells]

Sure, take your time. I happened to be "in the neighborhood" of this issue and figured I'd check in.

[Alan Birchenough]

I think you should mark this one as closed. I have used SEL* on a number of occasions recently and have not had any further issues. If I do run into trouble again I can always reopen it.

Thanks, -- Alan.