Schema.User.SObjectType not supported in OST
Reviewing more of the code inspections noticed that Schema.User.SObjectType is flagged as an error.
Assuming another minor quirk in the OST, possibly related:
aCase.Owner.Email
Also does not know how to resolve .Email even though Owner.Email was listed in the select query.
Comments (13)
-
repo owner -
repo owner Oh, and regarding the second, I'm not sure what version you're on and/or the last time you generated your OST, but polymorphic fields should be supported now. The following resolves fine for me:
Case aCase = [SELECT Id, Owner.Email FROM Case LIMIT 1]; System.debug(aCase.Owner.Email);
When I try to navigate through
Email
inaCase.Owner
on the second line, it shows options for bothUser.Email
andGroup.Email
. Let me know if that doesn't work properly for you after getting onto the latest build of IC2 and updating at least the SObjects portion of your OST. -
reporter regarding issue 2, version 2.0 of IC with Webstorm. I generated the OST about 5mins before...
Does this need to be a separate bug?
-
reporter weird - different project this renders without issue...
-
repo owner Tony, in the project which has the issue, do you mind expanding the OST in the project view and looking for the file
META-INF/PolymorphicRelationshipFields.json
? Assuming it's there (if it's not, that's the problem), open it up and look for the entry with keyCASE.OWNER
. It should look like:"CASE.OWNER": [ "GROUP", "USER" ],
Let me know if any of that looks different from how I've described it. If it's as-described, it must be a bug in how I'm using it somewhere.
-
reporter I cannot find "Case.Owner" in that file... have tried rebuilding a couple of times and now tried deleting the OST file completely to regenerate (still no good).
Would the API version have any impact on this? we are stuck using 37 at the moment as we need to update all the picklists etc to the new format from 38...
-
repo owner That's interesting. It could very well be a side-effect of the earlier API version. You could try generating your OST with a more recent API version, then reverting to the original version for ongoing work...see if that helps. I can also try generating with an older API version, but it'll be a bit before I can do so.
-
reporter I did try changing it but no luck... my next thought would be to start a fresh project...
-
repo owner Okay. Since you've seen the correct behavior in another project and this seems to be related to the org for the project in question, any thoughts on next steps for this reported issue? We can get a detailed OST generation log to see what's coming back from the various API calls to see if the root cause of the issue is in the org.
-
reporter Might try creating a new project for the environment...
-
repo owner Sounds good. Let me know the results, and if the same problem persists let's get a detailed log and see if that helps shed a light on what's happening.
-
reporter New project has cleared this error, the old project was originally started under IC1 and IntelliJ then moved to Webstorm and IC2.
-
repo owner - changed status to resolved
Sounds like this can be resolved then?
- Log in to comment
Thanks, Tony. Man...there are SO MANY ways to express compile-time constants for SObjects and field:
and of course none of these are "normal" in the sense of how Apex normally works. They're all special constructs. I've been supporting the first four. I'll add support for the last one as well. Thanks for reporting!