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>
The pkg/translations TranslationHelper is first-write-wins on cache
hits: if two callers pass the same key with different fallback
strings, only the first fallback is remembered. Both ListIssueFields
(MS-aware) and ListIssueFieldsLegacy shared the translation key
TOOL_LIST_ISSUE_FIELDS_DESCRIPTION, so at runtime the second-registered
variant (legacy) inherited the first's description — leaking the
MS-flavoured 'single_select, multi_select' text into the FF-off surface.
Only list_issue_fields was affected: issue_write and list_issues use
identical top-level descriptions across variants (their MS-vs-legacy
differentiation is in InputSchema property descriptions, which are
hardcoded strings not routed through the translation helper).
Fix: give the legacy variant its own translation key
(TOOL_LIST_ISSUE_FIELDS_LEGACY_DESCRIPTION). Simplify buildListIssueFields
to accept the already-resolved description string, so the two variants
resolve their translation before calling the shared builder.
Live-verified against a local binary:
- FF off: description no longer contains 'multi_select'
- FF on: description contains 'multi_select'
Regression test: Test_ListIssueFields_LegacyDoesNotLeakMSDescription
UnderRealTranslationHelper uses an in-test cache that mimics the real
helper's first-write-wins behaviour. Confirmed the test fails if both
variants share a key and passes with them split.
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>
* Annotate read tools with ifc labels
* Dont automatically enable IFCLabels in insiders mode
* ifc: don't label unpublished repo advisories as public
Repository security advisory listings can include draft/triage/closed
advisories (via the state filter), which are not world-readable even on a
public repository. Deriving confidentiality from repo visibility alone
under-classified those results as public.
LabelRepositorySecurityAdvisory now takes an allPublished flag and only
returns a public label when the repo is public AND every returned advisory
is published; otherwise it is private. list_repository_security_advisories
computes allPublished from the response state; the org-wide listing stays
private-untrusted. Adds unit + handler regression tests covering the
draft-advisory-on-public-repo case.
Addresses PR review feedback.
* ifc: fix confidentiality under-classification in releases, collaborators, get_me
Audit for the same bug class as the repo-advisory fix (confidentiality
derived from a coarse signal that misses access-restricted items) found
three more under-classifications:
- Releases (list_releases, get_latest_release, get_release_by_tag): draft
releases are visible only to push-access users and are not world-readable
even on a public repo. New LabelRelease(isPrivate, hasDraft) returns public
only for a non-draft release on a public repo; handlers compute hasDraft
from the response (Draft flag / per-item scan).
- list_repository_collaborators: a collaborator roster requires push access
to list, so it is never world-readable, not even on a public repo. New
LabelCollaboratorRoster() is always PrivateTrusted (mirrors LabelTeam),
replacing the repo-visibility-derived label.
- get_me: the result includes private_gists / total_private_repos /
owned_private_repos, which are not part of the public profile. LabelGetMe
is now PrivateTrusted instead of PublicTrusted.
Verified the remaining public-capable labels are sound: Actions logs are
world-readable on public repos; branches/tags are public metadata; gist,
project, search, and starred-repo labels read per-item visibility and join.
Adds ifc unit tests for the new/changed labels and a get_release_by_tag
handler regression test (draft on public repo -> private); updates the
get_me handler test to assert private.
* ifc: document why list results use one joined label, not per-item
Explain on LabelSearchIssues (and cross-ref from LabelGistList) that a tool
result is delivered as one opaque payload and the IFC engine makes one
allow/deny decision per flow at egress, so the only sound bound for a list is
the meet of every item's label. Per-item labels would only be load-bearing if
the engine could partition a result and route items to different sinks; until
then they would invite unsafe declassification of a public item that arrived
alongside private data. Doc-only change.
- Expose fullDatabaseId (BigInt) in list_issue_fields
- Add issue_fields parameter to issue_write for setting field values
- Support single-select fields via field_option_name resolution
- Add REST API field value extraction in get_issue responses
- Update minimal types with IssueFieldValue for REST responses
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* feat(issues): gate issue-fields features behind remote_mcp_issue_fields flag
Gates the recently merged issue-fields work (list_issue_fields tool,
field_values enrichment on list_issues/search_issues, and field_filters
input on list_issues) behind a new feature flag, also enabled in
insiders mode.
- list_issues splits into two same-named registrations: the field-aware
variant requires the flag, while LegacyListIssues (FeatureFlagDisable)
preserves the prior schema and GraphQL selection set so disabled
callers don't pay the extra wire/server cost.
- search_issues skips the field-values lookup when the flag is off.
- list_issue_fields requires the flag to be registered at all.
- Adopts <tool>_ff_<flag>.snap naming for flagged toolsnap variants so
same-named duplicates each get a distinct snapshot.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: address PR review on issue-fields gating
- docs generator: install a no-flags feature checker so README reflects
the default user experience (tools enabled with no special flags),
fixing duplicate `list_issues` and removing granular/flagged-only
tools that were never meant to appear in the default docs.
- csv_output: drop the FeatureFlagEnable/Disable exclusion in
isCSVOutputTool. Wrapping happens before the per-request flag filter
picks the live variant, so flag-gated list_* tools wrap safely; this
restores CSV conversion for `list_issues` and enables it for
`list_issue_fields` when both flags are on.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add custom field filtering to list_issues
* Flatten schema
* add repo fields flag
* test fix
---------
Co-authored-by: Sam Morrow <sammorrowdrums@github.com>
* Add list_org_issue_fields tool
* Clean up code
* complete struct fields & rename option type
* Drop created_at/updated_at from IssueField and IssueSingleSelectFieldOption
* Address feedback
* Address Copilot review: close resp.Body, set expectError=true for missing org test
* Adjust to list_issue_fields
* Add feature flag
* Allow tool to support read:org or repo
* Docs
* address comments
* Add repo_issue_fields flag
---------
Co-authored-by: Michael Jacholke <46944669+michaeljacholke@users.noreply.github.com>
Copilot