Get-MgIdentityGovernanceAccessReviewDefinition -Search

[insomniacc]

Microsoft.Graph.Identity.Governance 2.8.0

First time using this module, but I've used Users and Groups plenty.

Get-MgIdentityGovernanceAccessReviewDefinition -Search "Displayname:stringToSearch"

The -Search parameter does not appear to be functiona and the the response is always:

Get-MgIdentityGovernanceAccessReviewDefinition_List: The query parameter '$search' is not supported.
Status: 400 (BadRequest)

[timayabi2020]

@insomniacc the command you are running translates to this http request https://graph.microsoft.com/v1.0/identityGovernance/accessReviews/definitions?$search="DisplayName:stringToSearch" which has a $search query parameter and it's not supported by the API. You will get an API response similar to the screen shot below if you put a -Debug option at the end of the command.

Please use this Get-MgIdentityGovernanceAccessReviewDefinition -Filter "DisplayName eq 'stringToSearch'" as an alternative.

[insomniacc]

@timayabi2020 - The reason that I was using the search parameter is because this would typically automatically wildcard my search.

So for example, if I had multiple access review definitions with the name 'prefix something suffix'
I could run a search across 'something' to fine all the associated items.

I'm not sure how I can accomplish this using -filter, since the following:

Get-MgIdentityGovernanceAccessReviewDefinition -Filter "contains(DisplayName,'something')" 

also does not work.

Regardless though, if -Search is not supported, it should not be presented as a parameter on the function.

[timayabi2020]

@insomniacc - Thank you for further clarification on the usage of the command. Unfortunately for such service issues, we may not be best placed to resolve it. I would therefore recommend that you to open an issue here https://developer.microsoft.com/en-us/graph/support and the service/API owner will action on it.

[insomniacc]

I'll be honest, I'm failing to understand how it's a service issue and not a build issue with the module or underlying dependencies (in which case I would have thought this is the correct channel to raise issue so that it can be internally be routed to the right team). It's a fundamental problem with the module that there's parameters which are effectively broken and cannot be used, but they are being provided as functionality - this should be tracked in this repo in my opinion, especially considering it's the first place other individuals will come looking for the same issue/answer as it's PowerShell module specific.

If it's not currently a feature, the module should be updated and the parameter should be removed.
If it should exist as a feature I would expect this issue to remain open and the relevant parties to be contacted to make them aware there's an issue with consistency and a standard is not being maintained, so that it can be rectified and tracked in line with the modules that are expecting to support it.

[timayabi2020]

@insomniacc if we revisit my first response to this issue, it shows how the command execution translates to a http request made to the API responsible for processing and availing data to a user. This means that you can copy the request and run it against a command like Invoke-MgGraphRequest -Uri <paste url here> and you will still get the same result. You can also make use of this tool https://developer.microsoft.com/en-us/graph/graph-explorer to directly run http requests against graph just to confirm that you are dealing with an issue that is not unique to the sdk.

Having said that, kindly note that cmdlets generation/builds are driven by openAPI specifications defined by the API/Service owner. In this case the search parameter is defined in the specification (See image below) and so the cmdlet will be generated with that parameter and the expectation is that it should be working. This clearly points to API functionality which I am not best placed to answer hence the request for you to log that issue with graph support team (https://developer.microsoft.com/en-us/graph/support).
NB. This repository is intended for issues related to the functionality of the module (bugs and feature requests)
Also have a look at https://learn.microsoft.com/en-us/powershell/microsoftgraph/troubleshooting?view=graph-powershell-1.0#using--debug for more troubleshooting pointers.

[insomniacc]

I'll log the support ticket as you requested but in my honest opinion, I think this process is all wrong and has been for a long time.

Either way you look at it, the parameter does not work, so while there may be a dependency issue and a problem that another team needs to resolve, it's still also an impacting issue with this module that needs to be tracked, hence why I opened it here in the first place.

I just think that asking your consumers to bridge a communication gap between internal teams is the totally wrong approach, it creates siloed working and it's not good communication generally. What if I gave up at this point and didn't bother to raise the support ticket (not that I will do that but I've not yet had time, but I imagine others will follow this path from time to time), would this issue be closed and then just left?

This is just one very specific issue with one function and one parameter that I happen to need to use, but generally I've avoided the graph modules for this reason. I mean for long enough there was a function for Add-MgGroupMember but there wasn't even one to remove them, this is something I'd expect in a an alpha or beta product, but then the worst part of that situation was, the issue was opened here in Nov 2020, and it wasn't resolved until release 1.10.0 on Jun 17 2022, that's nearly 2 years later!!!!! honestly, that's just crazy to me for something that is so commonly used. Yet I've seen this repeating pattern with issues being opened and taking years/months to resolve and it puts me off using the graph API at times or even bothering to raise issues.

Take a look at this one for example:
https://learn.microsoft.com/en-us/powershell/module/microsoft.graph.identity.governance/update-mgidentitygovernanceaccessreviewdefinition?view=graph-powershell-1.0

It's an update function, but there's parameters for -createdby and -createddatetime, from my understanding these are read only and should not be 'updateable'.

Don't get me wrong, I also don't want to take away from good work your teams do but I feel as though making a small change to the path of support and internal communication channels would go a long way to stopping these types of issues from over shadowing the good work being done, not to mention help to keep things moving along a little faster than they have been doing.

Anyway, let me bring this back a bit, I apologize for going on a little rant here, my intention is not to be difficult, but I just want to give you honest and critical feedback in the hopes that it highlights genuine gaps and drives change.

I'll go ahead and log a support ticket, please leave this issue open so that I can come back and update it with any progress.

[insomniacc]

Here's the response I got, I linked them to this issue so they could understand and read the detail in full.

I'm from the Azure Identity Developer Support Team.
 
Based on the case description, you are getting 400 - Bad Request when trying to use the OData search query param with this Graph API "/identityGovernance/accessReviews/definitions".
 
The HTTP 400 response you are receiving is intentional and is part of the system's design, this endpoint does not support the OData query parameter you are attempting to apply. It only supports the following OData query parameters to tailor the response: $select, $top, $skip, $orderby, and $filter. You can verify this information in the API documentation provided here.
 
 
It's important to understand that not all OData query parameters are universally implemented across all Graph API endpoints. Each property within the Graph API supports specific OData query parameters, while some properties do not support any at all. You can find such details for each property within the properties section of this endpoint.
 
 
The purpose of the Graph API returning a 400 - Bad Request error is to clarify what is currently supported by the API backend and to highlight functionalities that are not currently supported. This approach aims to facilitate the use of this API while maintaining transparency regarding its capabilities.
We recognize that this might not align with your initial expectations. We want to be clear about what our support engineers can offer.
I apologize for any inconvenience this situation may have caused. If you have additional questions or concerns, please don't hesitate to contact us.
Thanks!

This issue needs ownership, it needs someone to effectively communicate between teams and raise awareness because right now I'm just getting turned away from both sides claiming its not an issue, but it clearly is.
One of two actions needs taking, either 1. the parameter needs removing from the function and module or 2. support needs adding to the API for the parameter.

As a user of the module and a consumer, I've done everything I can.