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

Refactor emails handling #26

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

johnny-m-young
Copy link
Owner

@johnny-m-young johnny-m-young commented Sep 8, 2023

What

This refactors the way emails are handled in the application. At present the application uses an EmailsHelper with various methods for sending emails depending on the type of email being sent. This has led to have lots of case statements throughout the code to determine what method should be called and with which parameters.

In this PR I have eliminated the need for the EmailsHelper. Instead I have created a factory in the AnnualLeaveRequestsController which returns an instance of a StatusUpdate class, the type of which depends on the new status, which contains the email hash for the update. The controller then directly interacts with the Notify client to send an email using the #send_email method with the email hash.

Why

This makes the code more open to extension, which will come in useful when implementing the Edit and Withdraw actions.

@johnny-m-young
Copy link
Owner Author

I've got a few points I wasn't sure about with this one:

  • I wasn't sure where to put the ApprovedStatusUpdate and DeniedStatusUpdate classes
  • Are the class names suitable?
  • Should these two classes inherit from a super class called StatusUpdate?

@johnny-m-young johnny-m-young force-pushed the refactor-emails-handling branch from 327d388 to ccc7184 Compare September 13, 2023 11:02
Jonathan Young added 2 commits September 13, 2023 13:22
I believe these changes will make it easier to extend
the `annual_leave_request#update_status` method to
accomodate other actions, such as editing and
withdrawing annual leave requests.

The present solution is very rigid, requiring new
EmailsHelper methods to be written for each new
update action. The new solution simply needs a new
StatusUpdate class to be added for the new action,
and for that action to be added to the case options
in the private `status_update` method in
AnnualLeaveRequestController. This brings the code much
closer to being open for extension.
Updates the AnnualLeaveRequestController tests
to check emails are sent to the correct person
with the correct template used.
@johnny-m-young johnny-m-young force-pushed the refactor-emails-handling branch from ccc7184 to 576f415 Compare September 13, 2023 12:22
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.

1 participant