fix: custom queries don't work with scoped labels
This MR is preparing the ground for extending the GitLab TreeView. Namely, for showing changed files for each MR (#263 (closed)).
The TreeView is a perfect candidate for an object-oriented implementation where each type of item has it's own object. However, the current project implementation was just a few if
-controlled methods in the issuable
provider.
This MR breaks that logic into two separate "Item" classes.
-
Before: The tree view items were only storing the query, but all the fetching and decision logic has been done by the
issuable
data provider -
After: The
issuable
data provider has minimal responsibility and the newCustomQueryItem
has both the context about the query and it performs the query as well.
Multi-root workspaces
One tricky part of the MR is how it represents the Multi-root workspace. In such a workspace you can have multiple projects. And the query (e.g. "MRs assigned to me") can be executed for each project.
The hierarchy is what makes this tricky.
We show Query name
-> Project
-> Query results
.
But when we have only a single project (not multi-root), we show: Query name
-> Query results
.
You can see that the parent item for the query results can have either project label or query name. This could be removed by making the project the top-most item, but It seemed more useful to me to keep the hierarchy as-is.
The following table shows the GitLab TreeView before and after. They are the same (with an exception of small icon fix) which is expected and desired since this MR only changes the code structure and not functionality.
before | after |
---|---|
![]() |
![]() |
The following table tries to illustrate the difference between
- normal workspace, where the
CustomQueryItem
can have the query name as a label - multi-root workspace, where the query needs to be executed for each project and so we prepend the
MultirootCustomQueryItem
.
normal workspace | multi-root workspace |
---|---|
![]() |
![]() |
As a side note: the new classes weren't implemented in TypeScript because they are importing older JavaScript modules. But They will be easily converted once the underlying logic is in TypeScript.
Part of #263 (closed)