fix(jira): gate the project selector to operations that use it - #6768
fix(jira): gate the project selector to operations that use it#6768mzxchandra wants to merge 1 commit into
Conversation
`projectId`/`manualProjectId` had no `condition`, so Select Project rendered on all 30 operations, including the 9 whose Jira endpoint accepts no project and whose visible fields do not depend on one. Both members now share one positive condition composed from two hoisted lists: PROJECT_PARAM_OPERATIONS (write, read-bulk, get_project, whose tools declare a projectId param) and ISSUE_KEY_OPERATIONS (the 18 single-issue operations, where the project scopes the issue picker). 21 shown, 9 hidden. ISSUE_KEY_OPERATIONS also replaces four verbatim copies of the same 18-element array previously pasted across issueKey/manualIssueKey's condition and required, which is why those lists drifted apart in the first place. Relabels Read Issue to Get Issue and Read Bulk Issues to Get Bulk Issues to match the sibling Get X convention. Operation ids and tool ids are unchanged, so stored workflows are unaffected; integrations.json is regenerated.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview Visibility is driven by hoisted lists: Labels move from Read to Get for read/read-bulk in the dropdown, canvas sentences, and Adds Reviewed by Cursor Bugbot for commit 7a1d73d. Bugbot is set up for automated code reviews on this repo. Configure here. |
Greptile SummaryThe PR limits Jira’s project selector to operations that consume a project or expose an issue picker scoped by one, while preserving stored operation and tool identifiers.
Confidence Score: 5/5The PR appears safe to merge; no concrete blocking or independently actionable non-blocking issues were identified. The selector remains visible for every operation that requires a project or displays the project-dependent issue picker, hidden values are excluded during serialization, and the label changes preserve operation and tool identifiers.
|
| Filename | Overview |
|---|---|
| apps/sim/blocks/blocks/jira.ts | The new project-selector conditions match project-consuming tools and issue-picker dependencies while keeping basic and advanced canonical fields synchronized. |
| apps/sim/blocks/blocks/jira.test.ts | The tests derive gating expectations from actual tool contracts and guard against unresolved tool mappings, hidden dependencies, and canonical-field divergence. |
| apps/sim/lib/integrations/integrations.json | The generated catalog updates only the two renamed Jira operation labels and remains aligned with the block configuration. |
Reviews (1): Last reviewed commit: "fix(jira): gate the project selector to ..." | Re-trigger Greptile
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 7a1d73d. Configure here.
Problem
projectId/manualProjectIdcarried arequiredcondition but nocondition, so Select Project rendered on all 30 Jira operations, including ones whose endpoint accepts no project at all.That is cosmetic until a workspace is forked. After a fork these empty selectors sit next to genuinely unmapped credentials, so they read as "something you still have to fill in", and the natural way to make the warning go away is to hardcode a project id into a workflow that was supposed to be portable.
The split: 21 shown, 9 hidden
Both members of the canonical pair now share one positive
condition, composed from two hoisted lists in theclickup.tsidiom:PROJECT_PARAM_OPERATIONS=write,read-bulk,get_project. The tool itself consumesprojectId:jira_writeposts it,jira_bulk_readresolves it into aproject = "KEY"JQL clause,jira_get_projectaddresses it directly.ISSUE_KEY_OPERATIONS= the 18 single-issue operations. The endpoint takes only the issue key, butissueKey.dependsOnincludesprojectId, so the project still scopes the issue picker and hiding it would break the picker.PROJECT_SCOPED_OPERATIONS= the spread of both.Hidden (9):
search,search_users,get_users,list_projects,get_fields,create_link,delete_link,delete_attachment,list_issue_types. Each takes no project parameter and has no visible field that depends on one.The lists are not hand-maintained against the UI. Exactly three Jira tools declare a
projectIdparam (bulk_read.ts:31,get_project.ts:35,write.ts:29) and exactly 18 declareissueKeyasrequired: true, matching the two lists member for member.Two corrections to the original bug report
read-bulk. That is wrong.tools/jira/bulk_read.ts:31declaresprojectIdrequired: trueand resolves it into the JQL clause. Hiding it breaks the operation outright. Verified live: it returns real issues with the selector present.read-bulkstays visible and required.list_issue_types. That is also wrong. That tool calls site-wide/rest/api/3/issuetypeand takes no project. It is in the hidden set.De-duplication
ISSUE_KEY_OPERATIONSreplaces four verbatim copies of the same 18-element array, previously pasted acrossissueKeyandmanualIssueKey'sconditionandrequired. That duplication is why the lists drifted apart in the first place. Net 98 lines deleted from the block.Labels
Read IssuetoGet Issue,Read Bulk IssuestoGet Bulk Issues, matching the siblingGet Xconvention. Canvas sentences updated to match.Operation ids and tool ids are unchanged (
read,read-bulk,jira_retrieve,jira_bulk_read). Labels are never persisted, only resolved at render time, so stored workflows are unaffected.integrations.jsonis regenerated for the two label strings; no other consumer references them.Stored values on newly hidden operations
serializer/index.ts:86,98gates every param onevaluateSubBlockCondition, so aprojectIdstored against an operation that is now hidden is excluded from the serialized params while the value itself survives in block state. Confirmed live: a storedprojectIdunder a hiddensearchproduced a tool input with noprojectIdkey, and the value reappeared intact when switching back toread.Verification
81 tests in the new
blocks/blocks/jira.test.ts. They derive expectations from the tool contracts rather than hand-copied operation lists, so adding an operation that consumes a project fails the suite until the block'sconditionis widened. They import tool configs directly rather than through@/tools/registry, whichvitest.setup.tsmocks to{}for import cost, and a guard test fails loudly if any operation resolves to a tool the file does not import, so no assertion can pass vacuously.Mutation-checked: stashing the block change makes 10 of the 81 fail.
Live E2E against
sim-testing.atlassian.net: all 30 operations swept in both basic and advanced mode and diffed byte-identical;search,write(created SCF-5), andread-bulkall executed successfully.Gates:
lint,type-check,check:api-validation,tool-metadata:check,integration-catalog:check,docs:checkall pass. 896 tests acrossblocks/, 106 acrosslib/integrations/.Not in this PR
tools.config.paramspassesprojectIdtojira_retrieve(read) andjira_update(update), neither of which declares that param. It is pre-existing, harmless (the executor drops undeclared keys), and identical before and after this change, so it is left alone rather than widening the diff.confluence.tshas the same class of gap and is a separate PR.