Skip to content

Lp/SwapRequests#68

Draft
lop4cwru wants to merge 18 commits into
mainfrom
lp/swap-requests-that-hopefully-lets-me-build
Draft

Lp/SwapRequests#68
lop4cwru wants to merge 18 commits into
mainfrom
lp/swap-requests-that-hopefully-lets-me-build

Conversation

@lop4cwru
Copy link
Copy Markdown
Collaborator

@lop4cwru lop4cwru commented Apr 20, 2026

🛠️ Changes in this PR:

  • Swap Requests!
  • On the frontend, you now have the option to request to swap a shift. On the generated schedule view, you may navigate to a selectable version of that generated schedule and select which shifts you'd like to swap.
  • Once you have formulated your request, you can submit it to be be stored in the database.
  • The system will then send out an email to the person who requested the swap (to confirm that they actually initiated the request) and to the other person that will be swapping. (to be implemented)
  • Those emails will link the users to a page where they can accept or deny the swap request (to be implemented)
  • Once both users approve the request, the generatedSchedule will update with the new shift assignments. (to be tested once dependencies are implemented)

Minor Stuff

  • Added a backend function to get an availability based on the user's email
  • Added a question when creating a schedule to allow swaps (unfinished)
  • Added a new state for the calendar cells to be both colored and selectable (partially implemented, could be fancier)
  • Testing for the swapRequest on backend (needs to be updated for the email service context)
  • Also includes my fuzz schedule testing that I really should've put on a different branch, but kinda forgot to, but it's here now. (needs to be updated for the email service context)

🧠 Rationale:

[Were there any trade-offs you had to weigh? Alternative approaches considered? Things you want people to look at?]

  • Rhyder mentioned that there should be a different behavior (or at least a different look) for selecting shifts you want to give away and shifts you want to take. I agree, but at the moment implementing that selection visuals on the frontend was more complicated than anticipated.
  • The SwapRequests needs to be much stricter on the validation at the moment. Shifts that do not apply to either the requester nor the requester's buddy will not give an error, and will just be ignored by the system, but this would be confusing unless fixed. So I will fix it. Validation is here! Trying to make a swapRequest w/ time that belong to neither party will now error (as expected).

✅ Steps to test:

  • step 1

📸 Screenshots/Videos:

lop4cwru and others added 18 commits March 30, 2026 16:19
adding back all the changes from the earlier branches so it's consistent with main
- Filled out RequestSwap.tsx
    - Contains the generated schedule and a place to submit your email. If your email has an availability in this schedule, you may proceed to the next.
    - Contains a selectable schedule w/ text in the cells where you can select which shifts you'd like to swap. Then, you can submit that to create the SwapRequest in the backend (FUNCTIONALITY STILL WIP)
- Modified the CalendarInnerCell css class to allow for text inside as well (with help from Rhyder)
- Added a method to the backend that lets you find if an email has an Availability on this particular Schedule.
I really tried, man.

Anyway, progress is stuck at the "validate selection" portion: I need a way of guaranteeing that exactly two people are swapping, one is known (the user that gave their email and created the request) and the second is going to be selected from a button on the left, if I can get that to render right.

Still needs to happen:
- shift assignments need to be correctly read and interpreted by the backend into a SwapRequest object (shouldn't be that bad, but ScheduleController.RequestSwap() needs to have the input changed from List<ShiftAssignment> to a string array of times, then parse each of those times to find which party (A or B) owns that shift, *then* it can add that into the backend.

- Send out the email confirmation to the creating user when they send the request to the backend (probably a new backend function)

- Send out the email request to the other swapping user (will probably use function created from above)

- Create a landing page for the two requested swappers that just shows the trade offer

- process that (just make the backend call "api/swap/{swapRequestGuid}/processSwap) and that should work

- send an email to the manager informing of the swap

- add a preference for the manager to block/allow swaps and the corresponding functionality for that (i.e. disable the request swap button or block it w/ a ternary)
meeee

- I made a DTO for the swap request that takes in the necessary info to be sent to the backend. It comes with a corressponding type on the frontend (`CreateSwapRequestProps`) that stores start times, requesterID, and recipient ID.

- I also attempted to make selection colors w/ Rhyder's help, but it doesn't work so well since the calendar object assigns color based on string rather than AvailDbId's. So schedules w/ multiple people will not cooperate.
why did I think this would work? Anyway it's redudndant bc we have dto now.
- I need to still validate a couple things:
    - atm, the system does not check to make sure that all selected times belong to either the requester or the recipient of the swap request. But it does make sure that any selected shifts that belong to the requester or the recipient will be added to the backend request. So, it's like... kinda working.
It should def be handled on the frontend too, but right now a request that has a time selected that belongs to neither the requester or recipient will throw an error.
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.

2 participants