Skip to content

Implement email service#600

Open
selenaliu1 wants to merge 16 commits into
masterfrom
sl2663/emailservice
Open

Implement email service#600
selenaliu1 wants to merge 16 commits into
masterfrom
sl2663/emailservice

Conversation

@selenaliu1

@selenaliu1 selenaliu1 commented Oct 8, 2025

Copy link
Copy Markdown
Contributor

Summary

This pull request is the first step towards implementing an email service to automate emails when a ride is approved, approved with modification, rejected, or cancelled.

  • implemented nodemailer
  • added new scheduling state for approved rides with modifications
  • implement rejected vs cancelled state
  • misc clean up: removed status from student page and report button, make rides more clickable from admin page
  • made the cancel ride confirmation dialog uniform across all places needed on admin and student page, added reject ride option for admin
  • approved email
  • approved with modification logic and email flow
  • rejected email
  • cancelled email

Test Plan

Fermin created a VPN to test this on, I successfully received the emails! You won't get the emails unless you have access to the VPN and are connected to it.
Screenshot 2025-11-29 at 3 50 00 PM

Cancelled ride:
Screenshot 2025-11-20 at 10 35 42 PM

rejected ride:
Screenshot 2025-11-20 at 10 35 00 PM

scheduled with modification:
Screenshot 2025-11-20 at 10 36 03 PM

scheduled ride:
Screenshot 2025-11-20 at 10 36 58 PM

Notes

Kept console.logs in for now for debugging.

Breaking Changes

@selenaliu1 selenaliu1 requested a review from a team as a code owner October 8, 2025 04:49
@dti-github-bot

dti-github-bot commented Oct 8, 2025

Copy link
Copy Markdown
Member

[diff-counting] Significant lines: 1011. This diff might be too big! Developer leads are invited to review the code.

@anika-4444 anika-4444 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think separating rejecting and cancelling might be a good idea. For the user, they convey different information (your ride not being scheduled vs your ride not happening when you expect it to) so perhaps that difference should also be reflected in the flow state?

Also, another thought for the future: now that we are adding an email service, should we think about other times an email could be auto-sent to users? When a user is first registered, campus wide closings, and holidays immediately come to mind.

Comment thread server/src/mailer.ts
import nodemailer, { Transporter } from "nodemailer";
import { format } from "date-fns";

let transporter: Transporter;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

More documentation for this page might be good? It's slightly unclear what the transporter does

Base automatically changed from dka34/changes to master November 2, 2025 21:57
@selenaliu1 selenaliu1 changed the title [WIP]: Implement node mailer for email service Implement node mailer for email service Nov 21, 2025
@selenaliu1 selenaliu1 changed the title Implement node mailer for email service Implement email service Nov 21, 2025

@mjaydenkim mjaydenkim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This looks incredible, great work! Not approving just yet b/c I noticed a couple of small bugs including one seemingly breaking one, but this looks just about there -- great work <3

Also, side note -- do we wanna add emails for when rides are assigned to drivers? I think it's less necessary but if it's easy to implement it might be worth it. Not sure though.

Comment thread server/src/mailer.ts Outdated
Comment thread frontend/src/components/Modal/CancelRideConfirmationDialog.tsx
// Scheduling state - separate from operational status
export enum SchedulingState {
SCHEDULED = 'scheduled',
SCHEDULED_WITH_MODIFICATION = 'scheduled_with_modification',

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

when i went into the ride overview for a ride from the admin rides table and changed the ride from "scheduled" to "scheduled with modification" without making any other changes, i got the following error:

Screen.Recording.2025-12-04.145557.mp4
TypeError: Cannot read properties of undefined (reading 'startTime')```

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the catch! Kind of debating what use there is to have this scheduling state here in the first place, since it should be done automatically and could potentially cause confusion, but I'm hesitant to fully remove it in cases when automatic detection might not correctly catch a scheduling state change, or other edge cases I haven't fully thought through. The error should be fixed now, and the logic now is that even if the scheduling state changes to scheduled with modification, it doesn't send an email unless an actual change relevant to the rider (time, pickup or dropoff location) is made.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah, I think that makes sense -- I think we should lean towards giving admins more leverage given how few there are and how flexible the current system is, but that solution sounds good to me.

Comment thread frontend/src/pages/Rider/Schedule.tsx
Comment thread server/src/mailer.ts
Comment thread server/src/router/ride.ts
notify(ride, body, userType)
.then(() => res.send(ride))
.catch(() => res.send(ride));
notify(updatedRide, body, userType)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Updated rides seem to be sent as approved rides -- since these emails don't contain all the details this is a little confusing. Maybe add a new type of email for updated/modified rides? Probably not necessary though, might be more work than it's worth

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good point! I changed the logic so that a scheduled --> scheduled ride with no change in scheduling state should not send another email (ie. scheduled --> scheduled), and only a meaningful change (scheduled --> scheduled with modification) would prompt an email. Similarly, for scheduled with modification --> scheduled with modification, an email is only sent if a meaningful change is made, otherwise don't send.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

That makes sense! I also noticed that changing the state back from "Scheduled_with_modifications" to "Scheduled" triggers a new email; I honestly don't think we need to worry about this though, it's a pretty small error.

@mjaydenkim mjaydenkim self-requested a review January 1, 2026 06:12

@mjaydenkim mjaydenkim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Did some more testing and everything looks great! This is such incredible work, tysm :') left like one or two comments but there's no real concerns

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.

4 participants