search

stockpile-co / api

The API for Stockpile, an app that manages stuff for organizations.
0 stars 1 forks source link

Add reservations #149

Closed AdamVig closed 7 years ago

AdamVig commented 7 years ago
AdamVig commented 7 years ago

@emroussel it has been a while since we looked at this issue. Have the requirements changed at all?

emroussel commented 7 years ago

I think this covers the changes to the rental process if we include reservations. Would getting rentals (with the new ability to view rentals in the app) support viewing items that are reserved as well?

Also, from the app's perspective, I think it would be confusing to the user if we keep the same flow.

They could scan a bunch of items only to realize one of them is reserved for the period they want to rent (and we can't check when scanning, because users enter the dates in the next screen).

So maybe reviewing the flow and how it could work would help to define more precise requirements for the api.

AdamVig commented 7 years ago

Would it make sense to change the rental flow to the following?

  1. enter end date
  2. scan each item (with each one being checked for conflicts in the given time span)
  3. set notes and external renters
  4. create rental

If we change the flow to the above, then creating reservations would be almost the same, but with the addition of a start date.

Previously, I thought the best way to do reservations was to essentially create "rentals that have not happened yet" by setting a start date in the future. The downside to that is that the user will have to physically scan the items in order to reserve them. It would be better to allow the user to make reservations based on the inventory view.

Reservations would have basically the same schema as rentals (one reservation to many items, just as there is one rental to many items), and the same date validation, but now the date validation for rentals would have to check reservations and vice versa. It seems like a lot of duplication.

It may, after all, be best to use rentals to implement reservations, but to add a field that differentiates rentals from reservations (since they would be sharing tables).

emroussel commented 7 years ago

Yeah I like the idea of adding a field to mark a rental as a reservation.

We could allow users to make a reservation by simply selecting items in the inventory (without scanning), and then ask them to scan them before making the actual rental (and maybe that could set the reservation field of rentals to false?).

It would also be nice to include a visual indication of which item is available when. Maybe something like a timeline? I can just imagine that it would be confusing to only know whether an item is available or not at a current date and would make planning harder. I guess this is more of a front end problem though.

AdamVig commented 7 years ago

I think that sounds good. The step where the user gets to convert the reservation to a rental should prompt the user to scan each item in the original reservation (similar to kits?) and give the user the opportunity to add more items.

I like the idea of a timeline, too. I think that with the addition of a field that shows whether a rental is a reservation or not, all the necessary data to build a timeline should be available. You can use GET /item/:barcode/rentals to get all rentals for a specific item.

Based on this discussion, it seems like my only action item for this issue is to add a boolean isReservation field to the rentals table. Does that sound right, or do you think you will need any new endpoints?

emroussel commented 7 years ago

Yeah, I think this is for now!