List all resource members, including inherited members

[MrSnoozles]

Hello,

as far as I can see ProjectMembers.all() only returns the members added to a project but not all members. The API endpoint for this is /projects/:id/members/all instead of /projects/:id/members. The endpoint is documented here https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project-including-inherited-members

As far as I could see there is no way to retrieve all members yet. Did I maybe miss anything?

[jdalrymple]

Oops! I'll fix this tonight!

[MrSnoozles]

Awesome, thanks for the super quick reply

[jdalrymple]

const membersIncludingInherited = await ProjectsMembers.all(id)
const membersWithoutInherited = await ProjectMembers.all(id, {excludeInherited: true})

Does this work for you :) ?

[MrSnoozles]

I'm pretty sure your changes are correct, but it doesn't work for my Gitlab 11.1.2. instance. It seems like this API endpoint is coming in 11.2: https://gitlab.com/gitlab-org/gitlab-ce/commit/046796cc3a98068e99abed152145e76c4636959c

Thank you so much for the quick response. I'm going to report back if it works once the endpoint becomes available :)

[max-wittig]

@jdalrymple I guess we can add this feature again, but I would vote to fall back to the old behavior in-case where the endpoint doesn't exist.

[jdalrymple]

Hmm, its supported in the latest Gitlab version right? For older behaviour wouldnt using an older version of the package make more sense. Ill finish up merging the typescript changes and then add this change as a breaking change. At least that way it will be obvious in the changelog

[max-wittig]

@jdalrymple Maybe a hint in the README would also be useful, that it only supports 11.2 and up.

[MrSnoozles]

I would probably keep things backwards compatible and give an option to `IncludeInherited` instead of excluding them. That way it would still work for old versions of the API. Kind of makes sense too, because it's closer to Gitlabs behaviour (/members Vs explicitly calling /members/all) Max Wittig <[email protected]> schrieb am Di., 4. Sep. 2018, 07:09:

…

@jdalrymple <https://github.com/jdalrymple> Maybe a hint in the README would also be useful, that it only supports 11.2 and up. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQr6EKbSOgr2OCGGDW22Q11QUFbyLQt0ks5uXgsSgaJpZM4Vyxs3> .

[jetersen]

I agree with @MrSnoozles don't change the behavior of how it used to work otherwise this is not semantic releasing 😅 Your of course welcome to bump the version number if you were to change the behavior but I still think IncludeInherited since GitLab view of members with inheritance is awful that's why we use this function (where inherited are excluded) to get a better overview of projects.

[jdalrymple]

@Casz Its definitely semantic if i release a major version, though its a little extreme for this addition lol. Sounds good though, ill change it to be inclusive as opposed to exclusive!

[jetersen]

Well when I updated you broke my project overview, and I had to either revert or fall in line.

Just to clarify my previous statement:

The semvar.org clearly says:

MAJOR version when you make incompatible API changes,

This commit should have been marked breaking in my honest opinion, since it broke my project overview (that depended on NO inheritance), cause it broke the previous default behavior also it did not help that it was missing from the current API (but that was more of a GitLab issue 😅)

[jdalrymple]

Yea i messed it up when i first did it! I would do it properly for the next time.

[jdalrymple]

🎉 This issue has been resolved in version 4.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀