-
Notifications
You must be signed in to change notification settings - Fork 37
TAN-5687 Webhooks #12365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
TAN-5687 Webhooks #12365
Conversation
|
…nlab into TAN-5687-webhooks
There was a problem hiding this 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: { |
There was a problem hiding this comment.
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 ? ( |
There was a problem hiding this comment.
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 = [ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Changelog
Added
Changed