@ffahri Sorry for bothering you. Can you help us with this or is the maintenance of this project somehow on-hold?

I think #191 is similar.

@emmahsax No, #191 is about conditions order inside a policy, not policies order.

@emmahsax No, #191 is about conditions order inside a policy, not policies order.

Okay. I just glanced briefly, not in detail... just saw they were both ordering issues.

@axdotl Looking at the policy API doc, the order can't be set when creating/updating a policy but only through a specific request: https://docs.opsgenie.com/docs/alert-and-notification-policy-api#change-policy-order

It's a bad API design leaded by the UI needs (you create the policy first, then change its order).

Not sure if the clean Terraform way to handle this should be to hide the second request behind the same alert policy resource, or to create a specific "alert policy order" resource.

Both looks dirty to me in their respective way, but as policies order may have a real impact on the result, I think it's important to fix this.

@gdlx Thanks for this investigation. You're right it's again a situation where the Opsgenie API design is not that great.

Based on your proposals I think the least dirty way is to introduce a new policy_order resource where one can reference existing policies.

Based on your proposals I think the least dirty way is to introduce a new policy_order resource where one can reference existing policies.

@axdotl I tended to agree but looking at the structure (long time since I coded for a TF provider), I think keeping a single resource (well, actually 2 with notification policies, but I'm not sure the order is as much important) may be better since there's no actual resource behind the change-order endpoint, so TF would have nothing with an ID to actually create/update/delete and store in the tfstate: at the end it's just a property in the policy itself.

This is actually worse than I thought since, unlike the WebAPI, the Policy API used by Terraform does not provide the order in the policy data.
It's only given in the policies list.
That means you also have to make an extra request to read the order 😩

@axdotl you may want to give a try: #388

At present, the GET Api https://docs.opsgenie.com/docs/alert-and-notification-policy-api#get-policy doesn't provide us the attribute of order. So we will not be able to support this request in terraform.

@agoel2-atlassian The order is provided by the policies list: https://docs.opsgenie.com/docs/alert-and-notification-policy-api#list-alert-policies

That's what I've used in #388.

Order has a strong impact on policies behavior. Not handling this almost prevents managing policies through terraform.

@agoel2-atlassian would it be possible to reopen this issue? This is a significant blocker to us defining alert policies in Terraform and it seems like gdx' PR would address the use case.

Looks like they closed it without even noting there's a PR fixing it.
They didn't even review the PR.

@agoel2-atlassian pinging again. #388 appears to address your concern, can you take a look?