feat: add terms to custom events

[Slo1k]

Summary

The change addresses the issue of assigning a term to a custom event when it is created. Previously, when users created custom events, no term was assigned to them. With this update, we now ensure that each custom event is associated with a term.

The term is obtained from the associated ScheduleCourse in the schedule. If the schedule contains classes from multiple terms (e.g., Fall 2023 and Spring 2023), the latest term is selected. If no term is found in the schedule, the default term will be used.

Test Plan

1. Test creation of a custom event with a single term in the schedule. Verify that the custom event is assigned the correct term.
2. Test creation of a custom event with multiple terms in the schedule. Ensure the latest term is assigned to the custom event.
3. Test creation of a custom event with no associated terms in the schedule. Verify that the default term is applied.
4. Ensure that edge cases like missing terms or incorrect term names in the schedule are handled correctly and fall back to the default term.
5. Verify that custom events are correctly displayed with their respective terms in calendar view - CustomEventDialog.
6. Test that after removing some scheduleCourses, the correct term is still assigned to the custom event, reflecting the updated state of the schedule.

Issues

Closes #762

[Slo1k]

@MinhxNguyen7 Hi! Could you review this pull request when you have a moment? Thanks!

[MinhxNguyen7]

Looks alright on the front-end with a minor suggestion.

However, you need to implement the backend to save it as well. For that, you need to add the term to the DB schema and save/get it from the backend endpoints. You can find the custom event schema in apps/backend/src/db/schema/schedule/custom_event.ts. For saving and retrieving, edit getGuestUserData and upsertGetUserData. There's not that much to change, but you'll need to read the code to see what has already been inferred when you changed RepeatingCustomEventSchema. Let me know if you need help with that.

That highlights the fact that the test plan above needs to account for saving and loading user account as well.

[Slo1k]

Thanks for the feedback!

I’ve made the changes on the frontend as suggested and also tried to adapt the backend by adding the term to the DB schema and updating the relevant endpoints (getGuestUserData and upsertGuestUserData). However, I’m having trouble running the backend locally to verify if the migration with the new field works correctly.

This is my first time working with tRPC, so I’m not entirely sure how to properly set up my local environment for the backend. Could you either check the changes on your side or provide a detailed explanation of how to configure the backend locally to ensure everything works as expected?

Thanks in advance!

[MinhxNguyen7]

I'll check the changes on my side, and I'm working on updating the README to reflect our stack after a recent migration.

Sorry for the inconvenience. I didn't think about this when I marked the issue as a good first task.

[MinhxNguyen7]

@Slo1k You can refer to the information added in #1110 to set up locally, if you'd like. I'll try to get reviewing and testing this locally as soon as I can