CI/CD → Runners page returns "No runners found" if user does not explictly have the "Owner" role directly in the group, but instead is an "Owner" via an invited subgroup

Status update (2023-11-17)

This will be solved by Allow developers invited through group to read ... (!137041 - merged) • Pedro Pombeiro • 16.7

Summary

When viewing the CI/CD → Runners page / attempting to View and manage group runners within a group as a user that has the Owner role via inheritance rather than directly in the group, the Runners info table simply outputs No runners found instead of populating. The Online runners, Offline runners and Stale runners values will still be populated.

Steps to reproduce

Example scenario:

1. Create a group and register a group runner to it.

2. Configure a group with SAML/SSO, and set the Default membership role for provisioned users to Minimal Access.

   • In this example the group is jr-ultimate-test on GitLab.com SaaS.

3. Create a subgroup with the Max Role set to Owner, and then invite this group into the previously created group.

   • In this example, the subgroup account-owners was created underneath jr-ultimate-test, and then invited to the jr-ultimate-test group's member list via Group Information → Members → Invite a group.

   

4. Provision a new user to the top level group. They should automatically be assigned a Max Role of Minimal Access the reflect the Default membership role set earlier.

   • In this example, the user jrtesting was provisioned into the jr-ultimate-test group, which is the top level group.

   

5. Invite the user to the created subgroup, with the Max Role value set to Owner.

   • In this example, the user jrtesting was added to the account-owners group.

   

6. At this point, the created user will still appear to have a Max Role of Minimal Access at the top level group, however due to the inheritance situation, they'll be able to perform actions from the top level group and downwards that are normally restricted to users with the Owner role.

7. If the created user now tries to view the CI/CD → Runners page for this group / View and manage group runners, they'll see a count of runners, but the actual table of Runners will be missing, and simply show a message that states No Runners found. Despite this, the user can still register new runners on the screen, but they can't actually see them, manage them, delete them etc.

   

8. If the created user has their Max Role changed to be an Owner directly in the top level group (and they'd have permissions to make this change themselves at this point), then the table of Runners will populate as expected.

   

What is the current bug behavior?

The ability to View and manage group runners from the CI/CD → Runners page appears to be restricted to only users with a direct Owner role in the group. Owner permissions via an inheritance situation does not seem to work for this ability, however it does seem to work for other features across GitLab, so the user experience becomes inconsistent.

To add to the inconsistency, a user in this situation can still register new runners into the group, but they cannot actually see them, manage them, delete them etc.

What is the expected correct behavior?

From a user perspective, if this kind of group role arrangement allows a user to perform actions restricted to the Owner role for other GitLab features, then this should also be the case for the CI/CD → Runners page.