pnp
Add `type` option for `aad user list`
Add option type
The idea is to add an extra option to the aad user list command.
| Option | Description |
|---|---|
--type [type] |
Filter the results to only users of a given type: Member or Guest. By default, all users are listed. |
-p, --properties [properties] |
Comma-separated list of properties to retrieve. |
API request
GET https://graph.microsoft.com/v1.0/users?$filter=userType eq 'Member'
Docs
Let's add a link in the docs to the user properties: https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0#properties
When the properties option includes values with a slash, for example: manager/displayName, an additional $expand query parameter will be included on the manager object.
Check out the implementation of aad group user list for more info on that.
Add extra property to output
The current output of the aad user list command is:
[
{
"userPrincipalName": "[email protected]",
"displayName": "John Doe"
}
]
I suggest that we add 2 more properties:
- ID (always useful to use in other commands)
- Mail (can be useful when dealing with guest users)
Hi @milanholemans, may be nice if we align the functionality of this command with group user list:
- add -f, --filter [filter] as well
- support expanding properties using slashes
userType with only two values Member or Guest can be tricky. Azure AD introduced the property userType in 2014, so users created before 2014 can have empty value. At least in our tenant we have a lot of users who are members and have empty userType. filter seems to be more flexible.
userTypewith only two valuesMemberorGuestcan be tricky. Azure AD introduced the propertyuserTypein 2014, so users created before 2014 can have empty value. At least in our tenant we have a lot of users who are members and have emptyuserType.filterseems to be more flexible.
Thank you for the feedback @MartinM85. However, according to me, we can still implement the type option for easy filtering. Users without a userType are edge cases and won't break the filter. If people want to list users with an empty value, they should retrieve them all and do the filtering themselves.
It may be a good idea to add @MartinM85's comment as a remark on the docs so the users are aware that userType can be empty. Besides that, the issue looks good to be opened up.
What's confusing to me is what's the difference between type and filter? If type ends up in the filter but we also have filter, aren't they both the same?
What's confusing to me is what's the difference between
typeandfilter? Iftypeends up in the filter but we also have filter, aren't they both the same?
Yes, in that case, that could lead to problems. We could drop the type filter, but it's a very user-friendly way to filter on specific users. We use the same option to list teams, spo sites, groups, ...
--propertiesoption already exists for theaad user listcommand
Yes true, but we have to enhance it to use slashes e.g. manager/id.
We could make an optionSet of type/filter...
While I'm sure we could make it work technically, I wonder about the rationale behind exposing two ways of filtering. I understand that they're not equal, but it seems odd to me that we'll expose the raw OData filter in this specific command but not in others. If it's something that we feel we should have, then we should think of a structural way of exposing it on all list commands.
We have a few list commands that expose the raw OData filter, but the majority of them don't do this indeed. I understand that this could be a useful option for developers, but not sure if people that write scripts know how to use them.
Not everyone would know how to use it, true. But it does give some flexibility if you do. Even Power Automate has it by the way, in at least one SharePoint action. And that tool is more focused on business users. The CLI is targeted at IT-admins and devs, it would not be a bad thing to have it in a lot of places.
I would not be against exposing this on all commands @waldekmastykarz... But even if we do, we'd have situations like this where we expose multiple options that allow a user to filter. Some chosen because they're quick to use and relevant in the situation, like the type option here.
I would not be against exposing this on all commands @waldekmastykarz... But even if we do, we'd have situations like this where we expose multiple options that allow a user to filter. Some chosen because they're quick to use and relevant in the situation, like the
typeoption here.
If we choose to expose OData $filter as an option, then we'd have some duplication with existing convenience options, which is fine. However, as this is something that all commands would benefit from, I'd like us to think about it CLI-wide rather than introduce in separate commands and then have to rework all implementations to a central one.
What if we remove the filter option on this command for now, and discuss the potential CLI-wide option separately?
What if we remove the filter option on this command for now, and discuss the potential CLI-wide option separately?
That's a good plan. Let's do that
