-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Notify users about the usage of deprecated webhooks #4898
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
Conversation
fab04cc
to
bf8798d
Compare
request, | ||
user, | ||
) | ||
notification.send() |
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.
By calling .send()
here we will be sending an email notification each time the endpoint is hit and that's not right.
Since we only have email
(send email immediately) and site
(make a persistent notification) backends I'm thinking on creating a new called delayed_email
which would be a mixture between these two: save the notification in the storage to be sent as an email later.
I think we need here:
- create notifications on each endpoint hit
- deduplicate them automatically when created
- store them somewhere
- recover the notification stored (and filter by type
deprecated_webhook_endpoint
) from a Celery task - send them and remove them from the storage
cc @agjohnson
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.
Either our code or message-extends already does this for us. It de-duplicates messages. I'd have to dig up where this is, but a third backend shouldn't be necessary
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.
Yes, but it's a custom storage https://github.com/rtfd/readthedocs.org/blob/5fb61ac617741dc3c9adcacb64d5e7154deedab2/readthedocs/notifications/storages.py#L28
Since we are not calling storage.add
when using the EmailNotification
that code is never called, from what I understand. Right?
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.
What I'm proposing is to create a custom backend but use that same storage that already de-duplicate the messages.
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.
Yeah, our custom fallback storage backend:
https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/notifications/storages.py#L20-L80
So instead of using a Django level message type, you use a persistent level message type. As long as the message text matches, the user will only get one message.
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.
Looking good so far! Your implementation is really close to being usable, I think the notification level will solve your issue on duplication. Next, tests!
readthedocs/settings/base.py
Outdated
'task': 'readthedocs.projects.tasks.send_deprecated_endpoint_notifications', | ||
'schedule': crontab(minute=0, hour='10', day_of_week='monday'), | ||
'options': {'queue': 'web'}, | ||
}, |
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 think we need a task here, messages will just go out from our notification system.
|
||
<p>Once you have done that, you need to go to your <a href="{% url "projects_integrations" project.slug %}">project's Integrations</a> under Read the Docs project's Admin, click integration and then in "Resync webhook" button.</p> | ||
|
||
<p>Thanks!</p> |
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.
We can probably point users to documentation on this. Maybe i'll put together a doc update and blog post. I'll come back to this copy
This PR still need some things to be ready to merge:
Regarding emails, it seems that you (@agjohnson) have something in mind that I'm not getting. I think what you are suggesting is not possible, actually. |
bf8798d
to
4611180
Compare
Codecov Report
@@ Coverage Diff @@
## master #4898 +/- ##
==========================================
+ Coverage 76.8% 76.95% +0.14%
==========================================
Files 158 158
Lines 9937 10019 +82
Branches 1241 1258 +17
==========================================
+ Hits 7632 7710 +78
- Misses 1973 1980 +7
+ Partials 332 329 -3
|
I updated the approach used here. The workflow is as follows:
Then, later in the same day:
After 7 days:
|
@@ -11,3 +15,69 @@ class ResourceUsageNotification(Notification): | |||
context_object_name = 'project' | |||
subject = 'Builds for {{ project.name }} are using too many resources' | |||
level = REQUIREMENT | |||
|
|||
|
|||
class DeprecatedWebhookEndpointNotification(Notification): |
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 notification could be generalized in the future so other notifications can extend from the base class and use the same workflow for de-duplication and sending emails.
Each time a deprecated webhook is hit, a notification is created (without duplicating it) to be sent.
4b60ea3
to
8a6bb8a
Compare
It would be good to merge and deploy this as soon as possible so we give some time to our users to perform the migration.
(from https://developer.github.com/changes/2018-04-25-github-services-deprecation/) |
* Updated copy on webhooks * Drop "deprecated webhook endpoint" copy, this is core team nomenclature, not user nomenclature. * Add small amount of docs to point to * Update docs and point to docs in notification message * Add year
I didn't catch this initially, but this notification is for all webhook endpoints. I'm fixing this up now to be not GitHub specific. |
Also, have we tested this on our commercial side? I'm mostly certain that |
Yeah, originally we want to let users know about all the deprecated endpoints on our side but now we are more worried about GitHub Services. I mean, |
message='{}: {}'.format(self.name, self.get_subject()), | ||
level=self.level, | ||
user=self.user, | ||
extra_tags='email_delayed', |
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.
At this point, I think we want to check
if created and self.send_email:
message.read = True
to avoid showing the email notification as a site notification.
…points (#5083) * Updated copy on webhooks * Drop "deprecated webhook endpoint" copy, this is core team nomenclature, not user nomenclature. * Add small amount of docs to point to * Update docs and point to docs in notification message * Split up deprecated view notification to GitHub and other webhook endpoints This sets a date for deprecated of these endpoints as Mar 1st 2019. Too soon? * Reduce complexity and drop decorator pattern for Notification classmethod pattern used in other notifications * Add notifications for non-GitHub incoming webhooks * Add docs as well * More renaming and slight refactor Found out 2x messages are being generated, so this stops the automated mechanism for triggering these messages. * Update dates * Also update docs * Typo on date * Back out some more of the changes to notifications to make them operable without automation * Add admin method for notification * Add admin filter for project features
We're archiving this at https://github.com/rtfd/readthedocs.org/tree/humitos/de-duplicate-email-notifications and merging this with the automation rules removed for now. |
* Notify users about the usage of deprecated webhooks Each time a deprecated webhook is hit, a notification is created (without duplicating it) to be sent. * Extend notification to support de-dup and delayed email sent * Improve decorator to support generic and specific VCS webhook views * Remove no necessary settings * DeprecatedWebhookEndpointNotification tests and improvements * Better docstring * Lint * Update copy on notifications for github services deprecation (#5067) * Updated copy on webhooks * Drop "deprecated webhook endpoint" copy, this is core team nomenclature, not user nomenclature. * Add small amount of docs to point to * Update docs and point to docs in notification message * Add year * Split up deprecated view notification to GitHub and other webhook endpoints (#5083) * Updated copy on webhooks * Drop "deprecated webhook endpoint" copy, this is core team nomenclature, not user nomenclature. * Add small amount of docs to point to * Update docs and point to docs in notification message * Split up deprecated view notification to GitHub and other webhook endpoints This sets a date for deprecated of these endpoints as Mar 1st 2019. Too soon? * Reduce complexity and drop decorator pattern for Notification classmethod pattern used in other notifications * Add notifications for non-GitHub incoming webhooks * Add docs as well * More renaming and slight refactor Found out 2x messages are being generated, so this stops the automated mechanism for triggering these messages. * Update dates * Also update docs * Typo on date * Back out some more of the changes to notifications to make them operable without automation * Add admin method for notification * Add admin filter for project features
Each time a deprecated webhook is hit, a notification is created (without duplicating it) to be sent.
Closes #4568