You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
/groups/:id/members/all for cli does not contain correct parameters #848
Description of the problem, including code/CLI snippet
When using the CLI command: gitlab group-member all [...] the accepted parameters are incorrect. The all "endpoint" should operate just like the list, allowing paging, etc. instead, it seems to have some other specific commands that aren't necessary.
Expected Behavior
Being able to use commands such as,
gitlab group-member all --group-id 212 --page 2
gitlab group-member all --group-id 212 --per-page 2 --page 10
etc.
Actual Behavior
gitlab group-member all only accepts:
-h, --help show this help message and exit
--group-id GROUP_ID
--sudo SUDO
--id ID
as specified in the gitlab docs--id is not necessary and you should actually be able to search (probably something to add for the normal list as well.
I believe this is related to #593 about the runner all verb as that behaves in the same way.
I used the group member code to work out why the runner all JSON support was broken but couldn't address the spurious --id argument. I added some thoughts on ticket #593, e.g. an all-runners list alternative object type, and a pointer about where in the CLI handling it might be making the assumption around why the --id argument is mandatory, but know too little at present to make a serious proposal 🙂.
I can envisage a possible "hack" where a custom action named all would bypass the logic around looking for an object's id attribute. This would potentially fix both cases but maybe there is some cleaner way of signalling that all is more like list and acts on an entire collection instead of a single item?
Activity
chrisoldwood commentedon Jan 30, 2020
I believe this is related to #593 about the
runner allverb as that behaves in the same way.I used the group member code to work out why the
runner allJSON support was broken but couldn't address the spurious--idargument. I added some thoughts on ticket #593, e.g. anall-runners listalternative object type, and a pointer about where in the CLI handling it might be making the assumption around why the--idargument is mandatory, but know too little at present to make a serious proposal 🙂.I can envisage a possible "hack" where a custom action named
allwould bypass the logic around looking for an object'sidattribute. This would potentially fix both cases but maybe there is some cleaner way of signalling thatallis more likelistand acts on an entire collection instead of a single item?pvshingala1997 commentedon Oct 17, 2020
Can you assign this to me?
fix(members): use new *All objects for *AllManager managers