Include undeployed local custom fields on standard Salesforce objects in the generated OST

[Nochum Sossonko]

The symbol table should include whatever is in the project, regardless of whether it is found in the org or not. Just like with Apex classes. This will be very helpful when there are multiple sandboxes in different states of synchronization with production (among other scenarios)

UPDATE: The core issue here is that while IC2 will stub OST entries for undeployed local custom SObjects and their fields, it is not properly adding undeployed local custom fields to standard (and likely custom) SObjects that it also finds in the org.

[Scott Wells]

Hi. IC2 uses the Salesforce API to query all SObjects and fields from the org, though that API only includes the ones that are readable/accessible by the configured connection’s user. There is an option you can configure on the connection called Ensure field read access that will automatically make all SObjects and fields accessible by the connection user. It is documented here:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/wiki/User_Guide/Configuring_Connections

Note, though, that in order to do so, it updates the connection user's Salesforce profile to make those SObjects and fields readable which may not be permissible in the target org, particularly if it's a shared org like a sandbox or, more importantly, a production org. In those orgs, you must generally use a permission set or similar to make the missing SObjects and fields readable by your user without adversely affecting the security model of other users in the org.

Unfortunately this is the only way I've found -- including long discussions on the topic with Salesforce folks directly -- to have those APIs include all SObjects and fields.

[Nochum Sossonko]

I think you misunderstood the request. I’m asking for IC2 to inject the sobjects and fields into the OST regardless of it they’re in the org or not. If I have valid object/field metadata in the project they should automatically be recognized. Just like if I create a new Apex class locally in my IDE, even before I deploy to my org, IC2 recognizes it.

[Scott Wells]

Ah, okay. Well, IC2 will include local-only .object[-meta.xml] and .field-meta.xml files in the generated OST even if not deployed into the org already. But, you must generate the OST to have them included. It doesn’t pick them up on-the-fly as you create them. Put differently, you could check a project out of version control with a large number of SObjects and fields, not deploy that project to the org, generate your OST, and they’ll be included.

I’m guessing that’s still not what you’re asking for, though. I imagine you’re asking for IC2 to include those SObjects and fields immediately upon the local files being created without the OST having to be generated, correct?

[Nochum Sossonko]

Well I guess two requests:

1. I’m not seeing this behavior. When I pull down new fields from git they always show up in red (not found) even after generating OST
2. Would be nice to implement the on-the-fly addition as well!

‌

[Scott Wells]

Thank you. I’d consider the second item an enhancement request (as filed here), but if you’re not seeing local-only custom objects/fields in the generated OST, I’d consider that a bug or project misconfiguration. Can you please enable debug logging for Offline Symbol Table Generation, generate your OST, and provide the resulting idea.log file for review? You may need to provide all idea*.log* files as the logs may roll. If you’d prefer not to attach them here for privacy reasons, feel free to email them to [e-mail].

[Nochum Sossonko]

Sent to email. FYI this never worked for me in any project.

[Scott Wells]

Issue tracker grooming. In all honestly, the remaining portion -- including undeployed local custom fields without OST generation -- gets very complex, and the alternative -- regenerating only the SObjects portion of the OST -- is quite simple and generally quite quick these days.