It's the most popular and flexible option, so should be able to cater for our future needs best.

This job is responsible for delivering a payload for one webhook event only. It allows the action to run asynchronously (and not slow down the calling process).

And thus retry later.
I tried to test that it actually retries, or ensuring the job remained in the queue to be retried, but couldn't get it to work.

Best reviewed with whitespace hidden.

Unfortunately the spec isn't allowed in CI. But it worked on my environment, I promise.
I chose `xit` so that it doesn't run unnecessarily. Perhaps we could use `pending` instead, which would execute, and notify us if it suddenly started working one day. But I doubt it.

This will store the URL for each user that wants a notification.

We probably don't need URL validation (it's not done on Enterprise for example). It could be validated by browser input, and anyway will be validated if the webhook actually works or not.

Inspired by Keygen: https://keygen.sh/blog/how-to-build-a-webhook-system-in-rails-using-sidekiq/

Although we won't be allowing multiple in the this PR, we certainly plan to in the future.

The migration helper add_reference couldn't handle the custom column name, so I had to put it together manually.

…er cycle event

But not supplier owners.

Using the clever concurrency testing borrowed from SubscriptionPlacementJob, but I thought a shorter pause time (just 100ms) would be sufficient.

I considered doing this with a new 'state' field (upcoming/open/close), but decided to keep it simple.

Allowing creation and deleting via the user association.
It probably won't be much effort to allow editing and multiple records, but I cut it down to the minimum needed to avoid any further delays.

I couldn't find a way to test a failure in the destroy method, but decided to keep the condition because I thought it was worth having.

Co-authored-by: Maikel <[email protected]>

The best way to check if something changed or not, is with 'change' of course.