- marked as enhancement
Many system types in the OST lack proper field type information
Trying to reference nested fields on DuplicateRuleHeader
of DMLOptions
object is flagged as unresolvable entity even though it's valid.
I think this stems from the auto-generated DMLOptions
class' properties are type Object
instead the specific types like AssignmentRuleHeader
, DuplicateRuleHeader
, etc.
I manually modified the OST such that the on the DMLOptions class:
global Object DuplicateRuleHeader;
became
global DuplicateRuleHeader DuplicateRuleHeader;
and that made the field resolvable again.
Any chance when the DMLOptions class is generated it can have its properties typed rather than just Object?
Comments (25)
-
reporter -
repo owner Yep, I ran into a few of these over the weekend as well, in my case in
Messaging.InboundEmail
. The fields/properties of these system types are reported as completely untyped by the Salesforce APIs. In cases where there are strongly-typed accessor methods in the same type, I adjust at OST generation time to render a more strongly-typed OST overall, but in cases like this I just don't have anything to use for better type information.I've reported this to Salesforce and they know about the general class of issue, but I have no idea if/when it will be addressed. I actually do have a mechanism to fix these types of things in a hard-coded form during OST generation and do so for a small subset of commonly-accessed system types, but when I looked into doing the same thing for this pervasive issue...honestly, I found myself a bit overwhelmed and decided to wait for someone to report them here.
Let me follow up again with Salesforce. It's possible with the new Apex Language Server they do have a better solution for this now. Cross your fingers!
-
repo owner Okay, I pinged them. We'll see what they say. In the interim, it seems like
DMLOptions
is important enough to warrant hard-coded corrections during OST gen. I'll work that one into an upcoming build. -
reporter Thanks for the quick follow up Scott. Hopefully Salesforce fixes the issue in the API
-
repo owner Issue
#820was marked as a duplicate of this issue. -
repo owner - marked as bug
- changed title to Many system types in the OST lack proper field type information
- marked as major
-
assigned issue to
- changed component to Offline Symbol Table
-
reporter Found another scenario:
ApexPages.PageReference
-
repo owner Yep. Ignoring the
ConnectApi
namespace which is FULL of these things (and frankly just doesn't seem entirely baked in terms of online documentation, etc.), here are the classes which seem to have this issue in some form (ordered by number of fields of typeObject
descending):Messaging.InboundEmail - 28 Metadata.Layout - 23 Metadata.DeployResult - 23 Metadata.PlatformActionListContextEnum - 19 Metadata.LayoutItem - 14 Database.DMLOptions - 14 Metadata.DeployMessage - 13 WaveTemplate.VariableTypeEnum - 12 Process.PluginDescribeResult - 12 Metadata.FeedLayoutComponentType - 11 Metadata.FeedLayout - 10 Metadata.AnalyticsCloudComponentLayoutItem - 10 Metadata.SidebarComponent - 9 TxnSecurity.Event - 8 Metadata.ReportChartComponentLayoutItem - 8 Canvas.Test - 8 Metadata.Container - 7 ApexPages.Component - 7 Metadata.SummaryLayout - 6 Metadata.RelatedListItem - 6 Metadata.LayoutSection - 6 Metadata.SummaryLayoutItem - 5 Metadata.PlatformActionListItem - 4 Metadata.CustomMetadata - 4 Metadata.ConsoleComponent - 4 WaveTemplate.VisibilityEnum - 3 UserProvisioning.CollectingBatchable - 3 Reports.FormulaType - 3 Reports.CsfGroupType - 3 Reports.BucketType - 3 Process.SparkPlugParameter - 3 Process.SparkPlugApi - 3 Metadata.PlatformActionList - 3 Metadata.FeedLayoutFilter - 3 Metadata.FeedLayoutComponent - 3 ApexPages.ComponentIteration - 3 VisualEditor.DesignTimePageContext - 2 Metadata.SubtabComponents - 2 Metadata.RelatedList - 2 Metadata.PrimaryTabComponents - 2 Metadata.MiniLayout - 2 Metadata.LayoutColumn - 2 Metadata.DeployDetails - 2 Metadata.CustomMetadataValue - 2 Metadata.CustomConsoleComponents - 2 Messaging.InboundEnvelope - 2 Messaging.InboundEmailResult - 2 EventBus.TriggerContext - 2 Workflow.Context - 1 System.Continuation - 1 Support.Org62LEXFeedbackController - 1 Schema.DescribeFieldResult - 1 Process.PluginResult - 1 Process.PluginRequest - 1 Metadata.RelatedContentItem - 1 Metadata.RelatedContent - 1 Metadata.QuickActionListItem - 1 Metadata.QuickActionList - 1 Metadata.Metadata - 1 Cache.Session - 1 Cache.Org - 1
Some of these are almost certainly correct as type
Object
, but most are not...in particular in those in classes with high counts.I'm still trying to decide if I just bite off adding explicit corrections for these during OST generation. As noted above, ideally Salesforce provides a proper fix. I think it just depends on how long that takes...
-
repo owner Doug, I just looked at what you posted again and am not sure I understand. What's missing/wrong in
ApexPages.PageReference
? Sorry if I'm missing the obvious... -
reporter Thanks for the details, Scott.
Regarding
ApexPages.PageReference
I meant that IC2 gives the same "cannot resolve symbol" error. I've re-generated a full OST twice andApexPages.PageReference
doesn't exist. -
repo owner Ahhhhhh....I see. So here's what's strange....according to Salesforce,
PageReference
is in theSystem
namespace:and it's not in the
ApexPages
namespace at all:Having said that,
ApexPages.PageReference
is still accepted by the Apex compiler, but it's not reported by the API that's used to build out the system types portion of the OST (the Tooling API'scompletions
REST resource).I'd prefer to keep that issue separate from this one as it's categorically different. I'll log another bug shortly on the topic, and I want to follow up with Salesforce as to how it should be handled. I'm not sure whether to stub out the
ApexPages
version for development, tell folks to start using theSystem
version instead, or what. -
reporter Well that is interesting. Strange that it lets the code compile and run with ApexPages namespace. A google search and I find code samples, even on Salesforce's own blog posts, that will use ApexPages.PageReference. Strange indeed!
-
repo owner Issue
#1008was marked as a duplicate of this issue. -
I've just started leveraging dml options more heavily in my org, and I am running into this issue as well. Is there any update as to if a fix for this is possible and where it falls on the roadmap?
-
repo owner I spoke with the Salesforce Tooling team at length about this while at Dreamforce this year. They know the root cause of the issue, but evidently it's more complex than expected because of how they assemble the set of system Apex types from various teams/products. Let me follow up with the primary person who was going to look into this and see if he has any update to provide.
-
Is there any way to ignore an issue like that if the class saves to the server and compiles correctly (which is a clear indicator that it's a false error)?
-
repo owner Yes, you can suppress the code inspection. Take a look at this documentation for suppressing code inspections in the editor:
https://www.jetbrains.com/help/idea/suppressing-inspections.html
Please let me know if you have any questions after reviewing it.
-
repo owner Partial fix delivered in 2.0.5.5 and 1.8.4.7 for IC2 and IC1 respectively. After updating and regenerating your OST, all properties in
Database.DMLOptions
should have proper type information. I'll look at updating other system types that are missing type information in future updates based on prevalence of usage. TheMetadata
namespace is a key candidate, but I'd love to hear from users about what else might be most useful. -
reporter Thanks, Scott!
-
repo owner In 2.0.7.0, all instances of this issue in the
Messaging
namespace have been addressed. -
Not sure if helpful to your process, but the VSCode extensions pull from https://github.com/forcedotcom/salesforcedx-vscode/blob/develop/packages/salesforcedx-vscode-apex/out/apex-jorje-lsp.jar (open in 7Zip and browse /StandardApexLibrary/*)
-
Hi Scott, not sure if this is totally related but custom metadata relationships are not coming through properly (coming through as Strings rather than SOBjectTYpe.
e.g.
so when you select or use it it looks like:
thanks
-
repo owner Sorry, Justin. Playing catch-up. That's not likely related to the problem in this particular issue. What I'll likely need you to do is enable debug logging for OST generation, generate the SObjects portion of your OST, and provide the resulting
idea.log*
files from the span of time during which the OST was generating. Feel free to email that to me for review. -
repo owner This will be pretty much resolved in the next build. Missing classes such as those in the
DataSource
namespace will be present, and all properties in the OST should be strongly-typed with the notable exception of those inConnectApi
namespace classes. That's because there are SO MANY of them with SO MANY properties, and they're just not very well-documented. I've addressed many of them, but there are many more in that namespace that are not addressed.Once I publish the next build, you'll need to regenerate your OST to pick up the changes.
-
repo owner - changed status to resolved
Delivered in 2.0.9.5:
Issue 821 - I finally broke down and filled in the gaps in the OST around system types that either aren't included in the Tooling API completions resource or are included with untyped properties. The one notable exception is the ConnectApi namespace which was updated as much as possible given the limited documentation available, but many properties still lack type information. Otherwise all properties should now be strongly-typed, and the totally missing DataSource namespace types should now be present and accurate.
NOTE: You must regenerate your offline symbol table to pick up these changes.
- Log in to comment
Changed to enhancement, not bug