pnp
Enhancement: extend `spo group list` to retrieve associated groups
Extend the command spo group list to retrieve all associated groups.
| Option | Description |
|---|---|
--associatedGroupsOnly |
Get only the associated visitor, member and owner groups of the site. |
Examples
List all associated groups for a specific site
m365 spo groups list --webUrl https://contoso.sharepoint.com/sites/project-x --associatedGroupsOnly
Additional Info
Request
GET https://tenant.sharepoint.com/sites/project-x/_api/Web?$expand=AssociatedOwnerGroup,AssociatedMemberGroup,AssociatedVisitorGroup&$select=AssociatedOwnerGroup,AssociatedMemberGroup,AssociatedVisitorGroup
Following my comment on #3545, what would you think if we added an extra option to spo group list instead?
Using something like spo group list --associatedGroups, we'd get all associated groups.
I'd like an additional opinion before we go on this. @pnp/cli-for-microsoft-365-maintainers ?
I am not sure if this is exactly the thing we are looking for but if we do --withGroups option in m365 spo web get we will get the same thing I guess 🙂
example outcome in my case
> m365 spo web get --webUrl https://tenanttocheck.sharepoint.com/sites/hr-life --withGroups
{
"AssociatedMemberGroup": {
"Id": 5,
"IsHiddenInUI": false,
"LoginName": "Benefits Members",
"Title": "Benefits Members",
"PrincipalType": 8,
"AllowMembersEditMembership": true,
"AllowRequestToJoinLeave": false,
"AutoAcceptRequestToJoinLeave": false,
"Description": null,
"OnlyAllowMembersViewMembership": false,
"OwnerTitle": "Benefits Owners",
"RequestToJoinLeaveEmailSetting": ""
},
"AssociatedOwnerGroup": {
"Id": 3,
"IsHiddenInUI": false,
"LoginName": "Benefits Owners",
"Title": "Benefits Owners",
"PrincipalType": 8,
"AllowMembersEditMembership": false,
"AllowRequestToJoinLeave": false,
"AutoAcceptRequestToJoinLeave": false,
"Description": null,
"OnlyAllowMembersViewMembership": false,
"OwnerTitle": "Benefits Owners",
"RequestToJoinLeaveEmailSetting": ""
},
"AssociatedVisitorGroup": {
"Id": 4,
"IsHiddenInUI": false,
"LoginName": "Benefits Visitors",
"Title": "Benefits Visitors",
"PrincipalType": 8,
"AllowMembersEditMembership": false,
"AllowRequestToJoinLeave": false,
"AutoAcceptRequestToJoinLeave": false,
"Description": null,
"OnlyAllowMembersViewMembership": false,
"OwnerTitle": "Benefits Owners",
"RequestToJoinLeaveEmailSetting": ""
},
"AllowRssFeeds": true,
"AlternateCssUrl": "",
"AppInstanceId": "00000000-0000-0000-0000-000000000000",
"ClassicWelcomePage": null,
.....
besides that I suppose the spec is ok 👍
I am not sure if this is exactly the thing we are looking for but if we do
--withGroupsoption inm365 spo web getwe will get the same thing I guess 🙂 example outcome in my case> m365 spo web get --webUrl https://tenanttocheck.sharepoint.com/sites/hr-life --withGroups { "AssociatedMemberGroup": { "Id": 5, "IsHiddenInUI": false, "LoginName": "Benefits Members", "Title": "Benefits Members", "PrincipalType": 8, "AllowMembersEditMembership": true, "AllowRequestToJoinLeave": false, "AutoAcceptRequestToJoinLeave": false, "Description": null, "OnlyAllowMembersViewMembership": false, "OwnerTitle": "Benefits Owners", "RequestToJoinLeaveEmailSetting": "" }, "AssociatedOwnerGroup": { "Id": 3, "IsHiddenInUI": false, "LoginName": "Benefits Owners", "Title": "Benefits Owners", "PrincipalType": 8, "AllowMembersEditMembership": false, "AllowRequestToJoinLeave": false, "AutoAcceptRequestToJoinLeave": false, "Description": null, "OnlyAllowMembersViewMembership": false, "OwnerTitle": "Benefits Owners", "RequestToJoinLeaveEmailSetting": "" }, "AssociatedVisitorGroup": { "Id": 4, "IsHiddenInUI": false, "LoginName": "Benefits Visitors", "Title": "Benefits Visitors", "PrincipalType": 8, "AllowMembersEditMembership": false, "AllowRequestToJoinLeave": false, "AutoAcceptRequestToJoinLeave": false, "Description": null, "OnlyAllowMembersViewMembership": false, "OwnerTitle": "Benefits Owners", "RequestToJoinLeaveEmailSetting": "" }, "AllowRssFeeds": true, "AlternateCssUrl": "", "AppInstanceId": "00000000-0000-0000-0000-000000000000", "ClassicWelcomePage": null, .....besides that I suppose the spec is ok 👍
Aw I totally missed that. According to me it's not really logical to use the web command to get associated groups. Otherwise I wouldn't have missed it :smile:
@milanholemans I suppose it was added to spo web command as it was closest to what we have on SP API 🤔.
if you are interested I think it was all decided here 👉 https://github.com/pnp/cli-microsoft365/issues/2219#issuecomment-858373096
Anyway for me it's totally fine if we also add it to spo group list command and have it in both places for now. As a user I would also look for possibility to get associated groups somewhere in spo group command rather then spo web 👍.
So we ma have it in both places I suppose and after some time decide what should we do with the one on the web (if we deprecate or leave it, I would personally leave it as it's always more convenient to have additional options to get something more along the way 😉).
I have nothing more that I may add 😉.
@martinlingstuyl the stage is yours again 😋
@waldekmastykarz , @plamber maybe you want to also comment on this as you were on the initial conversation to add this info on the spo web level 👍
Pardon me for coming to the party pretty late.
Initial thought process in the discussion over here was not bring Associated Groups to the group details since logically that is part of the Web even the API as well.
I would like to bring in a different angle here. IF my understanding is correct, if we give the parameters --associatedGroups, result will fetch only the associated groups and not all the groups which is the objective of this command. This would be useful for a scenario if you are trying to get only associated groups. But this would typically be used in a Migration use case where you are looking to get the list of SP Groups in the site.
That being the case, I would rather be getting the list of groups with an Associated Type along with the groups.
So the result set may look something below
| ID | Title | Associated Group Type |
|---|---|---|
| 1 | Microsoft 365 CLI Members | Members |
| 2 | Microsoft 365 CLI Owners | Owners |
| 3 | Microsoft 365 CLI Visitors | Visitors |
| 4 | Random SP Group 1 | |
| 4 | Random SP Group 2 |
With this approach, we will get the list as well as the associated groups in a single command. If the development effort for the same is too high and does not quantify the effort in the usage of this command, then we can go with suggestion which is already specced.
I will let other @pnp/cli-for-microsoft-365-maintainers chime in as well
I would like to bring in a different angle here. IF my understanding is correct, if we give the parameters --associatedGroups, result will fetch only the associated groups and not all the groups which is the objective of this command. This would be useful for a scenario if you are trying to get only associated groups. But this would typically be used in a Migration use case where you are looking to get the list of SP Groups in the site.
That being the case, I would rather be getting the list of groups with an Associated Type along with the groups.
Since you can have only one of each group type, I think adding a property that would be empty for all but three groups wouldn't be intuitive.
If the scenario is to retrieve information about groups associated with the specific site, then we could either consider using the existing functionality of spo web get, which I understand is not intuitive if groups are top of mind for you, or extend the spo group list command with something like --associatedGroupOnly where the Only part of the flag indicates that it's a filter.
Since you can have only one of each group type, I think adding a property that would be empty for all but three groups wouldn't be intuitive.
My thought process was in same line like that of a ✅ kind of output where you can get the associated groups as well. But yeah, like you said, if there are say 10 groups, this gets applicable only to 3 groups which will be less intuitive.
If the scenario is to retrieve information about groups associated with the specific site, then we could either consider using the existing functionality of spo web get, which I understand is not intuitive if groups are top of mind for you, or extend the spo group list command with something like --associatedGroupOnly where the Only part of the flag indicates that it's a filter.
Personally I would not mind getting the associated groups within the scope of Web. But totally get the opinions of other users since groups are expected to be under the hood of spo group. So that being the case having the option of --associatedGroupOnly as a flag option would make sense and I am with that.
Personally I would not mind getting the associated groups within the scope of Web. But totally get the opinions of other users since groups are expected to be under the hood of spo group. So that being the case having the option of --associatedGroupOnly as a flag option would make sense and I am with that.
We can expose both options and over time could measure which one is used more frequently.
So short summary:
So we can introduce a new option --associatedGroupsOnly to the command spo group list. This will list only the associated groups of the specified web.
I think it can be opened up?
