changelog detected ✅

thanks for the PR! as v2 is just around the corner, instead of merging this, can you see if ruleset.Rules covers what you're after here?

thanks for the hint I will definitely check out v2 now. When you say "around the corner" what are we talking about in terms of time? I know estimates are a tricky but just to get a rough understanding.

you can use it today, see #1538

it's just waiting for us to clean up a couple of UX improvements and slap a GA label on it.

Okay so I looked into v2 and while it is great, I am afraid that the functionality this PR would introduce is either missing or then I can't find it.

What is the functionality I am looking for?

We need to be able to CRUD individual rules in a WAF ruleset without updating the entire ruleset.
Otherwise, to my understanding we could be running into race conditions in which two individual clients are performing an ruleset update (please correct me if that is wrong).

the link i provided above is for managing individual ruleset rules - the same as the PR you've proposed. you can confirm this by looking at the HTTP method and the path called.

as for your issue or concurrency, it exists in a ruleset and rule and neither will mitigate it because the backing service doesn't offer concurrency flags or a locking mechanism. you can still have two HTTP calls to the same resource which will result in a race condition; that is something you'll need to mitigate within your own coordination.

Maybe you could point me to the methods that can be used to updating the zone WAF rules, since I only manage to find the methods that use the accounts endpoint, but not he zone endpoints (searching for zones/%s/rulesets does not return any results for me).

Thank you very much!

see ruleset.Rules - if you provide an account identifier, it uses that, otherwise if you provide a zone identifier, it will use that instead.

closing as v2 has this functionality today and you can use them alongside one another if needed.