chore: incoming webhooks and tokens migration

[nunogois]

https://linear.app/unleash/issue/2-1699/db-create-migration-for-a-new-incoming-webhooks-table

Adds a migration that creates 2 tables:

• incoming_webhooks
• incoming_webhook_tokens

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
unleash-docs	⬜️ Ignored (Inspect)	Visit Preview		Dec 18, 2023 0:37am
unleash-monorepo-frontend	⬜️ Ignored (Inspect)	Visit Preview		Dec 18, 2023 0:37am

[chriswk]

I'm not sure we want to cascade here.

Unless the thought is that incoming webhooks are strongly bound to the user that created them?

I see both pros and contras here.
Pros:

• explicit control over what webhooks are created by whom
• automatic cleanup when users are removed from the system

Cons:

• automatic cleanup when users are removed. This is a double-edged sword, and the one that worries me the most

[nunogois]

I'm not sure we want to cascade here.

Unless the thought is that incoming webhooks are strongly bound to the user that created them?

I see both pros and contras here. Pros:

• explicit control over what webhooks are created by whom
• automatic cleanup when users are removed from the system

Cons:

• automatic cleanup when users are removed. This is a double-edged sword, and the one that worries me the most

I was under the assumption that we are always soft-deleting and not hard-deleting users, but I guess that may be a possibility after all. If that's the case I guess we may also want to drop the reference to the users table.

Addressed in 6c5899e

[chriswk]

Ah, I forgot about the soft delete thing. May I also suggest an index on the created_by_user_id?

[chriswk]

Never mind, I see they are in place already.

[chriswk]

Nice :)

[chriswk]

You don't need use strict; btw, so feel free to remove it :)

[gastonfournier]

LGTM!