Open MartinM85 opened 2 months ago
Hi @MartinM85, to improve friendliness, I suggest that we use 2 options displayName
and newDisplayName
.
Same question here. Do you want to work on it, or should we open it up?
@milanholemans Spec updated. I can take it
Thinking a bit more about this command, how about we add an option for --groupId
? It might be more informative to update a community using its groupId
rather than communityId
. What do you think, @milanholemans, @MartinM85?
In that case, shouldn't people just use the entra m365group
commands? If you change the description, display name or privacy there, it should sync to Viva Engage as well.
That’s a good point, but I’m not sure everyone would know that. If you’re working within the viva engage
command space, they might not think to check Entra commands. It’s a bit of an edge case, so I’m not sure if it’s worth the effort 😄.
We should also strive for consistency. This means that when we add this option to one command, we should add it to all viva engage
commands. I'm not sure if this is feasible, for the viva engage community get
command for example, we are unable to use the Viva Engage APIs when we only have the group ID.
It would be a bit of a workaround to get it working with just the groupId
, but not impossible. If we have a way to do it, might be useful to add the method to a central util for the community commands since I also specced out the user
commands with groupId
. Alternatively, we could just remove them from the spec and we can stick with communityId
and communityName
. I'm good with either.
I would start with the version without the groupId
.
@Jwaegebaert maybe we should agree on whether we user groupId
or not before reviewing:
I can live with both stances to include it, or not. But IMO if we include it, we should name it entraGroupId
to make it a bit more clear. What do you think @pnp/cli-for-microsoft-365-maintainers?
I also don't have a strong opinion about the group option as long as it is somehow clear, either in option name like @milanholemans mentioned to use entraGroupId
, or in option description. Other than that I think we may add such an option if possible 👍
Would entraGroupId
make it clearer? The community groups are strictly M365 groups, and while M365 is part of all types of Entra Groups, using entraGroupId
wouldn’t add much clarity. The description already specifies that it only accepts M365 groups.
Ok, spec updated.
Usage
m365 viva engage community set [options]
Description
Updates an existing Viva Engage community
Options
-i, --id [id]
id
,displayName
orentraGroupId
, but not multiple.-d, --displayName [displayName]
id
,displayName
orentraGroupId
, but not multiple.--entraGroupId [entraGroupId]
id
,displayName
orentraGroupId
, but not multiple.--newDisplayName [newDisplayName]
--description [description]
--privacy [privacy]
public
, andprivate
.Examples
Update info about the community specified by the community id
Update info about the community specified by name
Update info about the community specified by the Microsoft Entra group id
Default properties
No response
Additional Info
API https://learn.microsoft.com/en-us/graph/api/community-update?view=graph-rest-1.0&tabs=http