fix: correct field access in isFieldSubquery check and fieldMetadataSubquery lookup#1644
fix: correct field access in isFieldSubquery check and fieldMetadataSubquery lookup#1644
Conversation
There was a problem hiding this comment.
Pull request overview
Fixes two incorrect property accesses in the UI data table column-definition logic that could cause subquery metadata/handling to be skipped.
Changes:
- Corrected
isFieldSubquerydetection to index intoresults.parsedQuery.fieldsrather than the query object. - Updated subquery field metadata lookup to traverse the nested
Record<string, Record<string, Field>>structure.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
a1c1e05 to
88af1f5
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Build a set of subquery relationship names for reliable lookup | ||
| // (positional index is unreliable because getFlattenedFields uses flatMap, e.g. TYPEOF expands to multiple entries) | ||
| const subqueryRelationshipNames = new Set( | ||
| results.parsedQuery?.fields?.filter(isFieldSubquery).map((f) => f.subquery.relationshipName) || [], | ||
| ); | ||
|
|
||
| // Base fields | ||
| const parentColumns: ColumnWithFilter<RowWithKey>[] = getFlattenedFields(results.parsedQuery || {}).map((field, i) => | ||
| getQueryResultColumn({ field, queryColumnsByPath, isSubquery: isFieldSubquery(results.parsedQuery?.[i]), fieldMetadata }), | ||
| const parentColumns: ColumnWithFilter<RowWithKey>[] = getFlattenedFields(results.parsedQuery || {}).map((field) => | ||
| getQueryResultColumn({ | ||
| field, | ||
| queryColumnsByPath, | ||
| isSubquery: subqueryRelationshipNames.has(field), | ||
| fieldMetadata, | ||
| }), |
There was a problem hiding this comment.
subqueryRelationshipNames is built with relationship names as-is, and the Set.has(field) check is case-sensitive. Elsewhere in the codebase relationship names are compared case-insensitively (e.g., using .toLowerCase()), and Salesforce SOQL/metadata is generally case-insensitive. Consider normalizing both sides (store relationshipName.toLowerCase() in the set and check field.toLowerCase()) so subquery detection doesn’t fail when the query uses different casing.
… metadata Ensure subquery restore is not case-sensitive
88af1f5 to
08c16a8
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Two incorrect property accesses in
data-table-utils.tsxcaused subquery column metadata to be silently dropped.Changes
isFieldSubqueryindex fix:results.parsedQuery?.[i]was indexing the query object as an array — corrected toresults.parsedQuery?.fields?.[i]to match the actual structure used elsewhere in the file.fieldMetadataSubquerytwo-level lookup:fieldMetadataSubquery?.[field]was using a flat field string against aRecord<string, Record<string, Field>>structure — corrected tofieldMetadataSubquery?.[parentField.subquery.relationshipName]?.[field.toLowerCase()]to properly traverse both levels.Original prompt