We are running a self-hosted GitLab instance currently running version
The problem we face is that when filtering issues in an issue board, users with access to the project via a group cannot be selected as a filter criterion for the issue’s assignee.
To illustrate, we have the following structure: Two groups, A and B, one repository within group A, and some users (a1 and a2 as members of A, as well as b1 and b2 as members of B).
Additionally, group B was given access to the repository, which grants b1 and b2 access to the repository as well.
Naturally, a1 and a2 have access to the repository and can be used as a filter criterion in the issue board when filtering for assignees.
However, b1 and b2 can not be used there, which is the problem we are seeing.
If b1 and b2 are additionally added as direct members of the repository, the problem is solved. However, this creates unwanted redundancy in user management.
Is this the intended behavior, or should it be possible to use members of transitive groups as a filter criterion?
This is indeed an interesting question and I can understand how this could be a bit confusing. Let’s dive into it.
What you’re experiencing is actually the intended behavior of GitLab. When you’re filtering issues by assignee in an issue board, GitLab only considers direct members of the project, not members who have access via a group. This is because the issue board is tied to a specific project, and its filters are designed to work with the project’s direct members.
The reason for this is to maintain a clear separation of concerns. A group’s members might have access to many projects, and including all of them in each project’s issue board could potentially make the board unwieldy and difficult to manage. By only including direct members of the project, GitLab ensures that the issue board remains focused and manageable.
I understand that adding
b2 as direct members of the repository solves the problem, but as you mentioned, it creates redundancy in user management. Unfortunately, as of the current version of GitLab (15.11.3), there’s no way around this. If you want to be able to filter by
b2 in the issue board, you’ll need to add them as direct members of the project.
However, I would recommend keeping an eye on the GitLab issue tracker. GitLab is always evolving, and it’s possible that this behavior could change in a future version. If this is a feature you’d like to see, consider creating a new issue to suggest it. The GitLab team is always open to feedback and suggestions from the community!
Thanks for the quick reply.
I have two follow-ups on it.
(1) You mentioned that filters work only for direct project members, but of course, members of the project’s group are also recognized (a1 and a2 in my example).
(2) When assigning issues, b1 and b2 can indeed be assigned, which leaves me wondering if not being able to filter for them is an inconsistency. They can be assigned to, but not filtered for.