Groups not on par with Projects regarding visibility

[dsebastien]

Description

1. For projects, it is possible to directly pass the "visibility" option in order to by visibility (public/internal/private). It is not possible for groups, although the GitLab API supports it.

2. Side question: why is the visibility property of GroupSchema and ProjectSchema a string and not something like 'public' | 'internal' | 'private'?

Possible solutions

• Add a possibility to directly filter groups by visibility. Thus add visibility?: boolean to AllGroupsOptions
• Modify the GroupSchema and ProjectSchema types to narrow the type of the visibility property

[jdalrymple]

1. The inclusion of a parameter is primarily dependant on what i see in the docs. If their docs dont include it, i didnt include it. So for visibility, it isnt located in this list as far as i can see.

2. I overlooked that. Its like that for the Project schema, just not the group one.

[dsebastien]

Hello Justin,

For visibility, I thought it was supported, but you're right, it doesn't seem to be yet. Bummer :p

[dsebastien]

I have introduced an issue to request this: https://gitlab.com/gitlab-org/gitlab/-/issues/429314

[dsebastien]

For now I'll continue doing it on the client side:

import { GroupSchema, Camelize, Gitlab } from 'https://esm.sh/@gitbeaker/rest?dts';

export async function getInternalGroups(gitLabClient: InstanceType<typeof Gitlab>): Promise<(GroupSchema | Camelize<GroupSchema>)[]> {
  // TODO refactor once improved upstream: https://github.com/jdalrymple/gitbeaker/issues/3442
  const allGroups = await gitLabClient.Groups.all();

  return allGroups.filter(group => "internal" === group.visibility);
}

[jdalrymple]

Also note, if it works ill add it, all im saying is that it isnt documented. Have you tested this filter in an api call?

[jdalrymple]

:rocket: Issue was released in 40.1.0 :rocket: