Querying for groups with min_access_level filter returns sub-groups that do not meet the criteria

/api/v4/groups?min_access_level=40
PRIVATE-TOKEN in the header

For groups where the authorized user does have the required permissions (maintainer in the example above), the query is also return subgroups for which the user does not have the required permissions. e.g. When the user has maintainer to group foo, but developer to group foo/bar, the query is returning foo/bar as one of the results of the min_access_level filtered query.

The way the docs are written, this sounds like a bug. Shouldn’t the query results include only groups/sub-groups for which the user has equal or greater permissions than those designated in the min_access_level parameter?

Hey there!

From my experience, I don’t believe there’s a way to administer access levels on a single “subgroup” level. I believe the only way you can do so is on a “group” level.

Are all subgroup projects being returned when you make the query or only a few of them?

If it’s only a few, it’s likely a bug. If it’s all of them, it’s likely that the Maintainer access granted at the Group level is overriding any access levels granted in the other projects.

1 Like