Workaround for corrupted or missing @odata.id for directory objects
#616
Conversation
We use the `@odata.id` field (`DirectoryObject.ODataId`) to reference
objects for `@odata.bind` fields, e.g. when creating applications,
groups, service principals, or posting new members for groups or
directory roles. Two breaking changes were recently introduced in the
API:
1. `@odata.id` stopped being returned for requests with
`Accept: odata.metadata=minimal`. Hamilton has a fix for this in
v0.32.0.
2. The format of the `@odata.id` value has changed for some tenants.
Previously it was always the URI of the object, now in many cases
despite the odata.json spec suggesting this should be a URI, it
takes the form `directoryObject('0000...')`. This form isn't
recognised by other API endpoints like applications, groups etc.
To work around (2), we're manually constructing the OData ID to look
like a URI. This is intended to be a temporary fix until the API
stabilizes.
See #588
manicminer
force-pushed
the
bugfix/odata-id
branch
from
3873428
to
933b4a6
Compare
| callerObject.ODataId = (*odata.Id)(utils.String(fmt.Sprintf("%s/v1.0/%s/directoryObjects/%s", | ||
| client.BaseClient.Endpoint, client.BaseClient.TenantId, callerId))) |
There was a problem hiding this comment.
Note: this intentionally hardcodes the API version into the URI as that's what the API accepts, regardless of the actual version
|
@manicminer - Does this mean we can still use the 2.5 azurerm provider and expect it to work? Or are we still pending the bug fix release tomorrow? |
|
Test Results App Role Assignments Applications Directory Roles Groups (failures unrelated) Service Principals |
|
@manicminer thanks for working on this! Can you give us feedback in which version this will be available? Will this also be a backport-fix? Or only in 2.6.0? If only in 2.6.0, is there already a release date? |
|
We're also having this issue. Could this be considered for a 2.5.1 type release? |
|
We're also having this issue. |
|
We are also impacted by this issue. I hope we can get this new version today. |
|
This functionality has been released in v2.6.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
We use the
@odata.idfield (DirectoryObject.ODataId) to reference objects for@odata.bindfields, e.g. when creating applications, groups, service principals, or posting new members for groups or directory roles. Two breaking changes were recently introduced in the API:@odata.idstopped being returned for requests withAccept: odata.metadata=minimal. Hamilton has a fix for this in v0.32.0.@odata.idvalue has changed for some tenants. Previously it was always the URI of the object, now in many cases despite the odata-json spec suggesting this should be a URI, it takes the formdirectoryObjects('0000...'). This form isn't recognised by other API endpoints like applications, groups etc.To work around (2), we're manually constructing the OData ID to look like a URI. This is intended to be a temporary fix until the API stabilizes.
Fixes: #588