CodeQL / Analyze (actions) (push) Has been cancelled
CodeQL / Analyze (javascript) (push) Has been cancelled
Build and Test Go Project / build (macos-latest) (push) Has been cancelled
Build and Test Go Project / build (ubuntu-latest) (push) Has been cancelled
Build and Test Go Project / build (windows-latest) (push) Has been cancelled
Resolves conflicts from merging origin/main into the multi-select branch.
main added the `fields_param` feature which also split `list_issues` into
flag-gated variants, colliding with this branch's
`remote_mcp_issue_fields_multiselect` split.
Rather than gate `list_issues` on two independent flags (which the inventory's
single FeatureFlagEnable can't express for the "both on" case), the multi-select
feature flag is removed entirely — multi-select is now unconditional, matching
the already-unconditional read paths:
- issue_write / list_issue_fields collapse to their single multi-select-aware
variant; the legacy siblings and issues_legacy_multiselect.go are deleted
- list_issues adopts main's fields_param split (ListIssues / LegacyListIssues)
with the multi-select `values` slot always advertised
- optionalIssueWriteFields / resolveIssueRequestFieldValues / parseRawFieldFilters
drop the now-constant multiSelectEnabled bool and their dead single-select-only
branches
- FeatureFlagIssueFieldsMultiSelect const, allowlist and insiders entries removed
- toolsnaps + generated docs regenerated
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Multi-select issue fields ride on the existing custom-fields surface:
- issue_write (consolidated) and set_issue_fields (granular) gain
multi-select inputs (field_option_names / multi_select_option_ids)
- list_issues field_filters gain a 'values' slot for multi-select
filtering with AND semantics
- list_issue_fields advertises multi_select in its description and
surfaces multi-select definitions
- Read paths (IssueFieldValueFragment, list_issues enrichment, etc.)
decode multi-select values when an org has them
The write surface is gated behind a new FF
remote_mcp_issue_fields_multiselect. When the flag is off, the legacy
variants of issue_write, list_issues, and list_issue_fields are served
— same handler bodies, but their schemas and descriptions omit
multi_select. Read paths stay unchanged: orgs that have dotcom-side
multi-select enabled continue to see multi-select VALUES surfaced,
matching what the dotcom UI shows.
The granular tools (set_issue_fields) are not separately gated — they
are already behind FeatureFlagIssuesGranular, which is itself a
user-opt-in rollout flag. Double-gating adds complexity without
proportionate benefit for users who have already accepted experimental
territory.
Per the user's preference for code duplication over interleaved
branching:
- IssueWrite and IssueWriteLegacy are full siblings (issues.go +
issues_legacy_multiselect.go). The shared parser and resolver
(optionalIssueWriteFields, resolveIssueRequestFieldValues) take a
single multiSelectEnabled bool and reject multi-select inputs/fields
when false.
- ListIssues / ListIssuesLegacy share a buildListIssues helper that
swaps in the right descriptions and adds/removes the field_filters[]
values slot.
- ListIssueFields / ListIssueFieldsLegacy share a buildListIssueFields
helper that swaps the description (handler is identical).
Snapshot naming follows the established convention: legacy variants own
the canonical <name>.snap; MS-aware variants own
<name>_ff_remote_mcp_issue_fields_multiselect.snap.
Stacked on #2755 (the universal delete-fix half of the original PR).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot