cli-microsoft365: Bug report: m365 aad o365group user list --groupId returns the wrong membership information if a user is member and owner
Description
When using the m365 aad o365group user list --groupId you are receiving a misleading list of memberships when dealing with the Microsoft 365 Group if a user is in the members and owners list.
When interacting with Teams an owner is part of the owners and members list at the same time while a member is just part of the memberslist. Calling the alias of m365 aad o365group in the context of teams returns the correct information by hiding these details. On the other hand, when dealing with the Microsoft 365 Group interface I shouldn’t follow this logic.
Steps to reproduce
- Create a Microsoft 365 Group
- Add a user as owner and member
- Run m365 aad o365group user list --groupId
- You will see that the user is returned with “userType”: “Owner” only
Expected result
When using the m365 aad o365group user list command I am expecting to get back two entries and not one. On the other hand, when using the teams command I am expecting the behavior we are seeing today.
My suggestion is to separate the m365 aad o365group user list command and m365 teams user list command. Keep the current logic for the teams command but change the logic in the o365group command.
Actual result
User is listed only once
Environment
Latest CLI version
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 29 (29 by maintainers)
Commits related to this issue
- Fixes 'o365group user list' command. Closes #2374 — committed to garrytrinder/cli-microsoft365 by garrytrinder 3 years ago
- Fixes 'o365group user list' command. Closes #2374 — committed to garrytrinder/cli-microsoft365 by garrytrinder 3 years ago
- Fixes 'o365group user list' command. Closes #2374 — committed to garrytrinder/cli-microsoft365 by garrytrinder 3 years ago
- Fixes 'o365group user list' command. Closes #2374 — committed to garrytrinder/cli-microsoft365 by garrytrinder 3 years ago
- Fixes 'o365group user list' command. Closes #2374 — committed to garrytrinder/cli-microsoft365 by garrytrinder 3 years ago
I am going to create a couple of issues to track all the required changes for all affected commands and a summary issue to link them.
I’ll take a look at this.
@waldekmastykarz absolutely, I suggested raising those tasks when the PR is merged 👍🏻
@garrytrinder, also, let’s add tasks for the breaking changes that we should include in v4
Agreed. I will create a separate issue for all other crud commands
Yes, that makes sense, happy to make the required changes.
@plamber do you agree on the next steps?
teams user listwhich has bothgroupIdandteamIdoptions to match theo365group user listcommand and ensure we don’t introduce a breaking change, the new command will work as theo365group user listcommand does todayo365group user listcommand to return owners as members (this issue)teamIdoption fromo365group user listin v4groupIdoption from theteams user listcommand in v4-i) forteamIdoption inteams user listcommand in v4Hi @garrytrinder, I would rather separate the old business logic with the new one. The old one (suitable for teams) should go in a separate interface instead of being used as alias.
For V4 I would then remove the teamId option as parameter from the command.
Does it make sense to you?
“Later this evening” came quicker than I expected 😄
Got it, so back to @garrytrinder question, the answer is ‘yes’, we want to do exactly that.
You have to check the membership under the aad groups overview in the azure portal. The Teams UI hides what is happening in the background
@waldekmastykarz:
You must be a member of the members Group if you want to seamlessly collaborate in Teams with different apps. Therefore, whenever you are being added as owner in Teams, you are automatically added to the members Group.
This requirement does not exist for “normal” Microsoft 365 Groups