Overview

The core need is to be able to better filter pull request on the home page at repository level. The requested filters are:

• Keyword (title + description)
• Actor (author/reviewer)
• Target branch
• Dates

Proposal

In the mock-up below you can try out the following scenario: looking for PRs authored by Dwight.

https://www.figma.com/proto/it3BHQkoGPDLTPIV8V6i3h/Git---Pull-requests?type=design&node-id=2052-26093&t=0LP8nD4ai2EsS9q8-0&scaling=min-zoom&page-id=2052%3A25157&starting-point-node-id=2052%3A26093

Notes:

• search term are cumulative (AND). For instance, having a filters Author: john doe Keyword: foo means that we are looking for PR whose title or description contains foo AND author is john doe.
• search are not persisted, when someone hit F5 or navigate away from the page, the search is lost.

Implementation steps

Remark: we thought to leverage on "Full text" capabilities to fulfill the need but, at this stage, it involves a big step up in the way items are stored to tailor a research to subset of data (today data are indexed to be searchable at site level). Further investigations are needed to see how this could be done and it would be preferable to do that on something that we already index (tracker/artifacts) to reduce the complexity.

Search are performed by the backend and all the search capabilities are exposed via REST API (see below for details).

Step 1 - Base

Build the new, dedicated, app based on Vue3 (as it was done for new overview). At this stage, it's the same feature set than the current new home page with:

• new technical base
• display of reviewers
• new design

We cannot build upon the existing app because it was done in AngularJS (EOL since january 2022).

Technical side: need to add reviewers in /git/:id/pull_request representation.

Step 2 - Sort

Sort on creation date, by default, newest are shown first.
Add sort param to /git/:id/pull_request: {“order”: “asc|desc”}
Add Newest/latest select box on the view & apply selection.\

Step 3 - Author

We can only search on one author (like github or gitlab). The list is made of all pull request authors of the current git repository. When one author is already selected, no other authors can be added to the filters.

• Add to query parameter object of /git/:id/pull_request route: {“authors”: [{“id”: int }] }
• Add new route GET /git/:id/pull_request_authors with offset & limit parameters. Returns a collection of user representation. It lists all pull requests authors.
• Scaffold new graphical component (see figma)
  • add to TLP
  • use in PR and apply filter

Step 4 - Reviewer

We can only search on one reviewer (like github or gitlab). This list is made of all pull request reviewers of current git repository. When one reviewer is already selected, no other reviewers can be added to the filters.

• Add to query parameter object of /git/:id/pull_request route: {“reviewers”: [{“id”: int }] }
• Add new route /git/:id/pull_request_reviewers with offset & limit parameters. Returns a collection of user representation. It lists all pull requests reviewers
• Add “Reviewer” section to the graphical component and apply filter.

Step 5 - Related to me

Related to me corresponds to “Author = myself OR reviewer = myself”.
When there is an “Author” or “Reviewer” filter already selected and one attempts to toggle “Related to me”, there is a confirmation/warning “thing” (Mockup to be added). After “confirmation”, the existing “Author” and “Reviewer” filters are removed and “Related to me” is applied.
When “Related to me” is toggled, it’s no longer possible to select “Author” or “Reviewer” filter.\

• Add to query parameter object of /git/:id/pull_request route: {“related_to”: [{“id”: int }] }

Note: it’s not possible to re-use “author” & “reviewer” parameters of query because they are additive. When I set “author: me, reviewer: me” it gets pull request I’m author AND reviewer of. While “related_to” means I want pull requests I’m author OR reviewer.

Step 6 - Target branch

It’s only possible to search on target branch (like gitlab). It’s only possible to search on one branch at time.

• Use /git/id/branches to get the list of branches
• Add to query parameter object of /git/:id/pull_request route: {“target_branches”: [{"name": string}] }
• Use existing graphical component & filter according to selection

Note: we limit the search on target branch because getting the list of source branches is way more complex and we'd like to see what are the use cases (if they exist) for something very complex before implementing it.

Step 7 - Labels

It’s possible to search on several labels. Search is additive (label = emergency, label = easy means I want to see only pull requests emergency AND easy).

• Use /projects/id/labels to get all possible labels.
• Add to query parameter object of /git/:id/pull_request route: {“labels”: [{“id”: int }] }
• Use existing graphical component & filter according to selection

Step 8 - Keyword

Plain text search on title and description.

It’s possible to search several time on Keyword. Example:

1. Type “foo bar” + enter, this adds a “Keyword: foo bar” in the selected filters
2. Type “zeng stuff” + enter, there is now “Keyword: foo bar” and “Keyword: zeng stuff” in the selected filters.

This search for pull request where title OR description are matching “foo bar” AND “zeng stuff”

• Add fulltext index on pull_request_review.title & pull_request_review.description fields.
• Add to query parameter object of /git/:id/pull_request route: {“search”: [{"keyword": string}] }
• Add “magnifying glass” 🔎 component for search (search triggered by hitting enter or click)
• The search term are listed with “Keyword: ...”
• Apply search