You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was something that's been driving me around in circles the past hour, until I noticed the discrepancy whilst comparing the Graph Explorer behaviour v the MSGraph cmdlets in debug.
When attempting to update (or create) a group with a schemaExtension, such as below;
The cmdlet reformats the keys (as passed in the BodyParameter) into camelCase, leading to the data held within being updated to "Null" as opposed to the intended value - as it doesn't match the keys as-is within the schema that has been created.
This same behaviour is exhibited when attempting to set the data at the same time as the group being created; the data, as provided by the user, should be passed through as-is - as opposed to forced into camelCase.
We can see the lack of application of the additional data, despite a HTTP/204, via the following:
When doing the same operation (i.e., setting the schema extension values) via the Graph Explorer, or directly interacting with Microsoft Graph, it works as intended - where re-running the above returns the correct values;
Thank you @peombwa! I did have a quick search through the issues, but must have missed that one - thank you for linking it, and for the update on the release. Much appreciated!
Uh oh!
There was an error while loading. Please reload this page.
This was something that's been driving me around in circles the past hour, until I noticed the discrepancy whilst comparing the Graph Explorer behaviour v the MSGraph cmdlets in debug.
When attempting to update (or create) a group with a
schemaExtension
, such as below;The cmdlet reformats the keys (as passed in the
BodyParameter
) into camelCase, leading to the data held within being updated to "Null" as opposed to the intended value - as it doesn't match the keys as-is within the schema that has been created.This same behaviour is exhibited when attempting to set the data at the same time as the group being created; the data, as provided by the user, should be passed through as-is - as opposed to forced into camelCase.
We can see the lack of application of the additional data, despite a HTTP/204, via the following:
Which yields,
When doing the same operation (i.e., setting the schema extension values) via the Graph Explorer, or directly interacting with Microsoft Graph, it works as intended - where re-running the above returns the correct values;
The text was updated successfully, but these errors were encountered: