Implement Order Confirmation Feature in Eventyay
This post elaborates on the details of an endpoint which can be used to explicatively used to resend order confirmations. In the current implementation of the open event project, if the order has been confirmed, the ticket holders and buyers get an email each regarding their order confirmation. But in case that email has been accidentally deleted by any of the attendees, the event organizer / owner should have the power to resend the confirmations.
The first step to the implementation was to create the appropriate endpoint for the server to be pinged. I utilized the existing blueprint being used for serving tickets on eventyay frontend project and created a new endpoint on the route : orders/resend-email [POST]
# app/api/auth.py |
I utilized exiting send_email_to_attendees for the email purpose but for security reasons, the endpoint was limited to make sure that an organizer can request only 5 order confrimations to be resent each minute (implemented using flask limiter).
This was all for server implementation, to implement this on the front end, I just created a new action named as resendConfirmation implemented as given.
// app/controllers/events/view/tickets/orders/list.js |
Using a simple post request, this was implemented on the frontend for sending the confirmation, but the additional work to be done was to handle the new error (429 status). The server throws the error but loader service hasn’t been configured yet to handle this error appropriately.
// app/services/loader.js if (!response.ok) { const defaultMessage = httpStatus[response.status]; if (parsedResponse) { throw parsedResponse; } if (response.status === 429) { throw { status: 429, message: ‘TOO MANY REQUESTS’ }; } throw new Error( getErrorMessage( response.statusText, defaultMessage ? `${response.status} – ${defaultMessage}` : `Could not make ${fetchOptions.type} request to ${fetchOptions.url}` ) ); } |
The loader service has been modified in the following manner to accommodate the new error been thrown so that a more user friendly error could be shown on the controller level.
This was the whole mechanism which has been implemented for this particular problem.
Resources
Related Work and Code Repository