Skip to content

Support type, status and source/target branch/project fields in GLQL

What does this MR do and why?

Support type, status and source/target project fields in GLQL

Add support for fields in presenter:

MRs:

  • sourceBranch (as code)
  • targetBranch (as code)
  • sourceProject (as link)
  • targetProject (as link)

Issues/WorkItems:

  • status (as custom status, EE only)
  • type (as type)

Also upgrades @gitlab/query-language-rust to v0.13.1. See CHANGELOG.

References

Closes gitlab-org/gitlab-query-language/glql-rust#51

Screenshots or screen recordings

Query Screenshot

Merge request fields:

```glql
display: table
fields: title, sourceProject, targetProject, sourceBranch, targetBranch
query: type = MergeRequest
limit: 5
```

CleanShot 2025-07-11 at 02.15.16.png

Issue / work item fields:

```glql
display: table
fields: title, status
query: group = "gitlab-org" and type = Issue
limit: 5
```

CleanShot 2025-07-11 at 02.18.40.png

Querying by status:

```glql
display: table
fields: title, status
query: group = "gitlab-org" and type = Issue and status = "To do"
limit: 5
```

CleanShot 2025-07-11 at 02.17.58.png

Displaying issue/work item type

```glql
display: table
fields: type, title
query: group = "gitlab-org" and type = Issue
limit: 5
```

CleanShot 2025-07-11 at 02.41.54.png

How to set up and validate locally

  1. Enable custom statuses feature flag:

    echo "Feature.enable(:work_item_status_feature_flag)" | rails c
  2. In an issue description enter all the queries mentioned in the "Screenshots" section.

  3. The tables should display as expected.

  4. Enable GLQL work items feature flag

    echo "Feature.enable(:glql_work_items)" | rails c
  5. The tables should still display as expected with an "Experiment" badge.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Himanshu Kapoor

Merge request reports

Loading