Agenda Items

• Frontend only knows if item is borrowed. User cannot see what time range people have it or how long they have it

  • if you can know (show on frontend) who's reserving some item/borrowing some item, you can ask them if you really need it

  • We don't know who, for how long, what is estimated time of return for when an item is borrowed. Only info given is "you cannot have this" when trying to BorrowItem

  • Jeremy: When you borrow something, you put in your email.

    • Easy part: can just display borrower email.
    • Hard part:

  • Gavin: UX Team says, when you borrow item, you can create a reservation for the period of time you intend to borrow it. Can tell people how long you plan to use the thing.

  • TL;DR Borrower field: you put in reservation id. Reservation contains borrower, start and end time, notes. Frontend: add functionality to see who last borrowed the item. Use History table to do this.

  • TTL Column for History and schedule table: EX if it gets past 90 days, it deletes itself (DDB can take care of this). Can add stipulation: If it is the last/only remaining borrow for an item, don't delete it.

  • History table: Can modify to "who borrowed it last" instead of keeping it as a complete record of all borrows and returns

    • becomes a pointer to the row in the schedule table which is the last "borrow" for an item

• UX Team: Can we have a calendar view of reservations for an item show up on the page for that item? Show 1 week at a time of what time the item is being reserved. And then can scroll down week by week.

• Backend: Feature for "reoccurring reservation."

  • Imagine a Linked List of reoccurring reservation nodes. Add a "next reservation" column, refers to next "reservationId." (field type string, points to another row in the schedule table). Have API called "ModifyReoccuringReservation". When you call it, can make X < 10 number of reoccurrence of a reservation. (Assuming you reserve same set of items for a meeting i.e. event).
  • Delete reservation becomes complicated because can run into case of trying to delete one of a reoccurring reservation: "you are removing the middle of a node in a liked list." Need to jump around rows and reconnect pointers (change the reservation id rows of correct reservation.

• Frontend: (LOW PRIORITY) Notifications for "you have a reservation starting soon" and "you have a reservation ending soon." Look into background tasks (app should run in background to certain extent). Prob some way to schedule notifications and if you return the item, delete the notification. Do email, push, text notifications? See how people use the app after we release.

• Auto return system would mess things up (return things when time is up).

  • Note: Is this how things UX has set up? Why is this feature being brought up

• What's necessary on backend to make frontend work happen?

  • Lot's already there. Just "how do we use it as frontend?"

• How do we implement picture storage on backend?

  • Need to wait for a bit on what UX wants. Jeremy has ideas.

• Categories: What ones should we define?

  • no enums, move to custom categories
  • Notion has good example

Action Items

UX

1. Calendar view showing reservations. Displays 1 week at a time (can scroll to next week).
2. Revisit pictures (how do we want to do them).
3. Rethink categories. Look at how Notion does categories for tables and see if you like it (User can input custom categories, but will show existing tags users create). (Note: Frontend can do this. Be sure to ask Frontend if they can do something before vetoing ideas).

Frontend

1. Display the borrower on item profile page
2. Implementing logic to create reservation on borrow. Put reservation id on borrower field in items table.
3. Implement calendar (pending UX Design).
4. Implement custom categories (pending UX Design).

Backend

1. Add API to modify reservation time (start time, end time). Can be single API or multiple. (Gavin prefers single API).
2. Implementing "last borrowed" column in the items table. Points to id of last schedule on item chronologically closest to present, not in future. On return: overwrite the last schedule with the schedule associated with the return you are making. Delete the previous schedule table row to clean it up (schedule table for reservations made in the past (end time before today) should only contain 1 entry for each item max).
3. Implement reoccurring reservations
4. Implement picture storage (pending UX design)