Skip to content

Conversation

@kogre
Copy link
Contributor

@kogre kogre commented Oct 22, 2025

Changelog

Added

  • Support for Webhooks, which makes it possible to let external tools react to certain actions that happen on the platform
  • Internal comments are now supported in the Public API

Changed

  • 'Idea assigned to you' notifications now also work if the assignment was done through the public API

@notion-workspace
Copy link

Support webhooks

@cl-dev-bot
Copy link
Collaborator

cl-dev-bot commented Oct 29, 2025

Messages
📖 Changelog provided 🎉
📖 Notion issue: TAN-5687
📖

Run the e2e tests

📖 Check translation progress

Generated by 🚫 dangerJS against bfc46ee

@kogre kogre marked this pull request as ready for review November 2, 2025 21:44
@kogre kogre mentioned this pull request Nov 3, 2025
@kogre kogre requested a review from IvaKop November 5, 2025 08:06
Copy link
Contributor

@IvaKop IvaKop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation makes sense to me! I had some questions and comments but nothing blocking. 🚀

const methods = useForm({
mode: 'onBlur',
resolver: yupResolver(schema),
defaultValues: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add empty default values, this can be deleted.


return (
<Box w="100%" m="24px auto" pr="24px">
{!success ? (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having a separate state for success, you can use the form state to determine if it has been submitted via methods.formState.isSubmitSuccessful

project_id?: string | null;
}

export const WEBHOOK_EVENTS = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good but I think putting those directly into the dropdown might be confusing as survey submission or proposal is also an idea. Maybe we need better framing?

Copy link
Contributor Author

@kogre kogre Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's important that these strings exactly match what is sent to the receiving end of the webhook, so they should be literal. But I should indeed link to the documentation (for which I forgot to ask your review, did just now), will add.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't suggesting to change what is sent to the API, just that keeping these as they are in the dropdown itself could be confusing and that maybe we should use human language there like "Input (or post) created" or something similar.

@@ -0,0 +1,153 @@
# Changes Made to Implementation Plan
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was it intended that everything in this folder was committed? Maybe it was part of the working process and we should leave it out? Or is all of the information in here valuable enough to remain in the codebase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, it's a discussion we should have, I think. I think it's useful information to understand the feature, but we should align on how and where to incorporate such information. For now I'll keep it in for the sake of our discussion (next week)


def perform
# Delete successful deliveries older than 30 days
deleted_success = Webhooks::Delivery.succeeded
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious why we don't keep deliveries for more than 30 days?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just because it potentially bloats the database. I think we'll start without and not define the rake task yet, but suspect we might want to start doing it at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants