PingAccess application resource process order

[ashhammond]

Community Note

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

Description

New or Affected Resource(s)

PingAccess supports the ability to enforce the order of which application resourced are processed. Using this feature, then gives the administrator the ability to use regex filters in the application resource path to aid pattern matching.

The provider currently does not support this type of PingAccess configuration and it would be a nice additional feature if it did.

• pingaccess_application_resource

Potential Terraform Configuration

resource "pingaccess_application_resource" "foo" {

  anonymous                  = false
  name                       = "foo"
  enabled                    = true
  methods                    = ["GET"]
  root_resource              = false
  path_prefixes              = ["/api/v1/users"]
  order_preference           =  0
}

References

• #0000

[iwarapter]

hi @ashhammond the resource ordering is on the application

resourceOrder (array[int]): The explicit resource order defined when manual ordering is enabled. Each existing resource ID must be represented. (Required when 'manualOrderingEnabled' is true.)

The problem with this is it will make a cyclic dependency you need to create the app before the resource but it would then depend on the resource etc etc, its not a great API design. We could add support for this but it would be something you'd never be able to create from scratch in a single plan/apply. It would be create app and resources then update app definition with resource ordering.

[ashhammond]

hi @iwarapter thank you for taking the time to reply and giving this consideration. I understand your reply and agree.

If this is a limitation of the API and a clean solution cannot be applied, it should not be included in the provider.