Skip to content
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

Merged
merged 3 commits into from
Aug 24, 2021

Conversation

stsewd
Copy link
Member

@stsewd stsewd commented Aug 12, 2021

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.

@stsewd stsewd force-pushed the update-profile-info-front branch 5 times, most recently from f253670 to cf001a6 Compare August 12, 2021 22:20
@stsewd stsewd marked this pull request as ready for review August 12, 2021 22:34
@@ -34,6 +34,7 @@
url(r'^support/error/$',
Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

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

Seems reasonable 👍

@stsewd stsewd requested review from a team and removed request for a team August 12, 2021 22:50
Copy link
Member

@ericholscher ericholscher left a 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.

import requests


class FrontClient:
Copy link
Member

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?

Copy link
Member Author

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.

@@ -34,6 +34,7 @@
url(r'^support/error/$',
Copy link
Member

Choose a reason for hiding this comment

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

Seems reasonable 👍

Copy link
Member

@humitos humitos left a 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

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.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
See https://dev.frontapp.com/docs/webhooks-1.
See https://dev.frontapp.com/docs/webhooks-1

Make the link clickable 😄

Copy link
Member Author

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)

Copy link
Member

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/urls.py Outdated Show resolved Hide resolved
readthedocs/support/views.py Outdated Show resolved Hide resolved
except Exception: # noqa
msg = f'Error while getting conversation {conversation_id}'
log.exception(msg)
return Response({'detail': msg}, status=HTTP_500_INTERNAL_SERVER_ERROR)
Copy link
Member

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.

Copy link
Member Author

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 Show resolved Hide resolved
Comment on lines 80 to 82
msg = f'Error while getting contact {email}'
log.exception(msg)
return Response({'detail': msg}, HTTP_500_INTERNAL_SERVER_ERROR)
Copy link
Member

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=...

@humitos
Copy link
Member

humitos commented Aug 16, 2021

This feels pretty specific to our hosted RTD instances. I think this probably belongs in -ext, but I don't feel too strongly.

It makes sense to me putting this in the -ext repository, 👍🏼

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.

This sounds complex and extra work for us IMO, and I'm not sure that somebody will use it.

@stsewd
Copy link
Member Author

stsewd commented Aug 16, 2021

I think this probably belongs in -ext, but I don't feel too strongly.

yeah, I put it here since the support form was already here. I could move everything in another PR.

@ericholscher
Copy link
Member

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.

@stsewd
Copy link
Member Author

stsewd commented Aug 16, 2021

rename "front" to be "frontapp"

+1 on that, actually while searching for an existing integration with "django + front" results were mostly about frontend...

@stsewd
Copy link
Member Author

stsewd commented Aug 16, 2021

Should I move this to -ext now or merge this PR first?

@humitos
Copy link
Member

humitos commented Aug 17, 2021

Should I move this to -ext now or merge this PR first?

Probably better to move it now to keep things clean.

@stsewd stsewd merged commit 6d3cb4b into master Aug 24, 2021
@stsewd stsewd deleted the update-profile-info-front branch August 24, 2021 00:48
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.

3 participants