Implement azuread_application_registration data source

[ilmax]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

With the split of the azuread_application resource into a heap of it's constituent parts, now every new resource i.e. azuread_application_* accepts an application id that looks like the following: /applications/{guid}.

Today there's no resource I know of that can read an application from MS Entra and expose such id, so in case the barebone azuread_application_registration has been created in another module, possible even in a completely different terraform deployment, you have to resort to string interpolation to specify this value.

I see no drawbacks (unless I'm missing something) to implement such data source, it will also provide feature parity with the older counterpart azuread_application

New or Affected Resource(s)

data "azuread_application_registration" "example" {}

[manicminer]

Thanks for requesting this @ilmax. I appreciate that during this transition period that the mix of ID formats is challenging and can necessitate these kludges in configurations. The intention is to roll out the new ID format to existing data sources such as data.azuread_application, this has so far not been done to minimise disruption to existing configurations (incorrectly) relying on the bare UUID format. We'll be updating the existing data source in due course which will avoid having to introduce an additional redundant DS.

[ilmax]

@manicminer thanks for the answer, as long as the change won't break the current use of the data.azuread_application this approach is also fine, do you have any timeline for such a change?