The reviewer prompt branch checked reviewerSearchFunc != nil directly
instead of useReviewerSearch, making the fetch and prompt decisions
inconsistent. This mirrors how the assignee path already uses
useAssigneeSearch at both the fetch and prompt gates.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The expression was redundantly re-checking whether assignees or
reviewers were chosen. RepoMetadata already gates on
input.Assignees || input.Reviewers before consulting
ApiActorsSupported, so passing state.ApiActorsSupported directly
is sufficient.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Aligns the feature detector field name with the downstream
ApiActorsSupported flag introduced in the previous commit, so the
signal has one consistent name from detection through to consumption.
Also consolidates leftover TODO tags (actorIsAssignableCleanup,
requestReviewsByLoginCleanup) under the single // TODO ApiActorsSupported
tag so there's exactly one thing to grep for.
Pure rename with no logic changes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The CLI had two per-entity flags (ActorAssignees on EditableAssignees and
IssueMetadataState, ActorReviewers on IssueMetadataState) threaded through
different layers of the stack to distinguish github.com from GHES. Both
flags were always set from the same source (issueFeatures.ActorIsAssignable)
and never had different values, but they were carried independently on
different structs. This led to a confusing asymmetry where:
- EditableAssignees had ActorAssignees but EditableReviewers had nothing
- The PR edit flow piggybacked on editable.Assignees.ActorAssignees to
make reviewer mutation decisions, which was misleading
- RepoMetadataInput only had ActorAssignees with no reviewer equivalent
This commit replaces all per-entity flags with a single ApiActorsSupported
bool hoisted to the shared level on Editable, IssueMetadataState, and
RepoMetadataInput. Both assignees and reviewers now key off the same signal.
Every branch site is marked with // TODO ApiActorsSupported so we can grep
for cleanup sites when GHES eventually supports the actor-based mutations
(replaceActorsForAssignable, requestReviewsByLogin).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Wire up MultiSelectWithSearch for assignees in MetadataSurvey, replacing
the static MultiSelect that required bulk fetching all assignable actors.
This applies to both gh pr create and gh issue create interactive flows
when selecting assignees via the 'Add metadata' prompt.
Changes:
- Add assigneeSearchFunc parameter to MetadataSurvey
- Skip assignee bulk fetch when search func is available
- New SearchRepoAssignableActors API function for repo-level search
(create flows have no issue/PR node ID yet)
- New RepoAssigneeSearchFunc in shared editable.go
- Refactor actorsToSearchResult helper shared by both search functions
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Mark the legacy static MultiSelect reviewer path for cleanup once
GHES supports requestReviewsByLogin and search-based selection can
be used universally.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Gate search-based reviewer selection on both state.ActorReviewers
and the search function being available, consistent with the
ActorAssignees pattern used for assignees.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Refactored the MultiSelectWithSearch function and related interfaces to use a MultiSelectSearchResult struct instead of multiple return values. This change improves clarity and extensibility of the search function signature, and updates all usages, mocks, and tests accordingly.
Initial implementation of MultiSelectWithSearch:
- Implement by survey and accessible prompters. They use the same internal func under the hood.
- Implement in `gh preview prompter` for initial testing and demonstration
- Implement interface changes across the codebase and mocks to satisfy compiler.
- Implement tests for new MultiSelectWithSearch prompter
This commit enhances the following scenarios to include organization teams as pull request reviewers:
1. Interactive `gh pr create` during additional metadata
2. Tab completing `gh pr create --reviewer`
3. Tab completing `gh pr edit --add-reviewer`
4. Tab completing `gh pr edit --remove-reviewer`
Additionally, a new `gh pr create` test case for ensuring that teams show up within interactive prompts has been added.
- updated command documentation for new `--assignee @copilot` syntax
- updated `gh issue create` logic with feature detection for actor availability
- fixed bug where `--assignee` would not select default assignees due to login vs display name mismatch
- updated survey prompt logic to avoid parsing prompt options in favor of correlating with assignee / actor source
One thing that is not included in these changes is incorporating the GraphQL mutation to replace assignees with actors, which I will continue iterating on.
Currently, the prompter doesn't enforce the requirement of a title for PR
and Issue creation. However, that creates the UX where a user can enter a
blank title, spend time filling out a detailed body, then fail to create
the issue or pr when the request is sent to the api because the title is
blank. This attempts to handle that before sending a request to the api,
enforcing that, when prompting, the title of an issue is not blank.