[v3.4] Item availability validation not working

[orenyk]

From BMEC:

I came across a problem the other day that I haven’t had time to email you about, but it came up again yesterday so I thought I would take the time.

Reservations seems to be allowing us to create reservations for items that are not actually available. Yesterday, I made a reservation for a patron for Bose headphones. Reservations said there were two available from August 28-29, in looking at the catalog. When I went to the equipment model page, the calendar there said there was only 1 available for August 28 and that there were two for August 29. When I checked the actual availability, there was really only one item here and three checked out, one of which was due the 28th. It was only not a problem because one pair was available for the person who wanted one. The other day, Reservations allowed me to create a reservation for a laptop with no warning that there were none actually available. Again, the catalog said there were two, so I created a reservation, but found we had zero laptops in the closet. What we had were two that were due that day.

Screenshots:

[orenyk]

More feedback:

Yes, it can be duplicated on the test server. I used the Bose headphones again. From the view of the main catalog, both showed we had one more available to loan out today than we actually did due to items that are to be returned today.

For the Bose headphones I checked out three items to different patrons, one of which I set to be due today. That left the 4th pair available. The catalog again displayed there were 2 available from August 29-30, and allowed me to create two more reservations for that time frame despite only having one available for August 29. The equipment item page now displays a -1 availability for today.

[orenyk]

I've verified this as well, it looks like we're not taking reservations into account when determining item availability, and potentially using an open vs closed set of dates as well (e.g. not including the start date). Investigating...

[orenyk]

Found it! We were comparing TimeWithZones to Dates, resulting in a false comparison when checking the start date of each reservation (in Reservation#number_for_model_on_date and similarly in Reservation#number_for_category_on_date). Converting those to Dates fixes the issue, as far as I can tell.

[orenyk]

My first commit broke the renewal validations; issuing a PR after I investigate renewal behavior.

[orenyk]

Looks like our renewal specs were wrong; when there was an interfering reservation in the renewal period, the app was letting us renew existing reservations to include the start date of the new reservation, which is not good since technically the item has to be back the day before it's reserved. I've updated the specs; issuing a PR now.

[orenyk]

Oh, and this probably needs to be ported to master as well; leaving this open until that happens.

[orenyk]

Yup, verified in master. I'll try to cherry-pick commits and issue a PR.