-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Support: update contact information via Front webhook #8406
Conversation
f253670
to
cf001a6
Compare
cf001a6
to
bb29a38
Compare
readthedocs/urls.py
Outdated
@@ -34,6 +34,7 @@ | |||
url(r'^support/error/$', |
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 can move these to the new support
module in this PR if that's ok.
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.
Seems reasonable 👍
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 feels pretty specific to our hosted RTD instances. I think this probably belongs in -ext
, but I don't feel too strongly. Seems we made the API client generic, but didn't make the actual integration generic. It seems like a weird middle step. I think it's fine for now, but if we actually want pluggable things, we probably want a Front client for syncing user data, not for the API itself, and an API that's like backend = settings.DATA_BACKEND(); backend.sync_data(custom_data)
or similar.
readthedocs/support/front.py
Outdated
import requests | ||
|
||
|
||
class FrontClient: |
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 seems like overkill for 3 API calls. Is there a reason that we're using a wrapper instead of just calling the API directly?
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 need to pass the token header on each request, felt like a lot of duplication, I'm fine moving this class to the views file. Can also merge this into the view class, but not a big fan of fat-views.
readthedocs/urls.py
Outdated
@@ -34,6 +34,7 @@ | |||
url(r'^support/error/$', |
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.
Seems reasonable 👍
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 left some suggestions about:
- not use 500 errors when it's not our error
- improve log messages by adding the URL requested to it
- rename "front" to be "frontapp"" when possible to make it clear that we refer to the Front Support service
readthedocs/support/views.py
Outdated
Currently we only listen to inbound messages events. | ||
Contact information is updated when a new message is received. | ||
|
||
See https://dev.frontapp.com/docs/webhooks-1. |
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.
See https://dev.frontapp.com/docs/webhooks-1. | |
See https://dev.frontapp.com/docs/webhooks-1 |
Make the link clickable 😄
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.
Works for me with the period (gnome-terminal and kitty)
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.
He, it doesn't work on GitHub 🙃
readthedocs/support/views.py
Outdated
except Exception: # noqa | ||
msg = f'Error while getting conversation {conversation_id}' | ||
log.exception(msg) | ||
return Response({'detail': msg}, status=HTTP_500_INTERNAL_SERVER_ERROR) |
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 should return 500 here. It's not our own error. Maybe 400 or 404 is better.
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 an error when connecting to the front API, not an error on how the request was done, so not a 4xx.
readthedocs/support/views.py
Outdated
msg = f'Error while getting contact {email}' | ||
log.exception(msg) | ||
return Response({'detail': msg}, HTTP_500_INTERNAL_SERVER_ERROR) |
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.
Same here. 500 is not a good error IMO for external errors.
Also, the exception message could be improved by showing the URL tried: url=...
It makes sense to me putting this in the
This sounds complex and extra work for us IMO, and I'm not sure that somebody will use it. |
yeah, I put it here since the support form was already here. I could move everything in another PR. |
The support form being here makes sense, it's core logic. The integration with Front though is very custom, so almost all OSS users won't care about it, so it doesn't really make sense in the .org codebase. |
+1 on that, actually while searching for an existing integration with "django + front" results were mostly about frontend... |
0e3ff61
to
8305c6d
Compare
Should I move this to -ext now or merge this PR first? |
Probably better to move it now to keep things clean. |
Added a new endpoint to listed to front webhooks, the endpoint validates the signature using the api secret from Front.
I have already created the rules and webhooks (they need to be marked as active and the urls updated after deploy), so we only need to set the secrets on the ops repos.