[Koha-bugs] [Bug 29002] Add ability to book items ahead of time

Fri Aug 18 11:00:39 CEST 2023

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29002

--- Comment #32 from Martin Renvoize <martin.renvoize at ptfs-europe.com> ---
(In reply to Caroline Cyr La Rose from comment #31)
> I still see the months in French. It's not that big of a deal, but very
> mysterious.

Can this one wait for a follow-up bug.. it's in the depths of the library we're
using for the timeline view.

> >
> > -  It seems the next day after a booking is not available? Also the calendar
> > view and the table don't show the same dates.
> >    To recreate:
> >    1. Click Place booking
> >    2. Place a booking for two days, for example May 22 and 23
> >    3. Click Place booking again for the same item
> >       --> Note that 22, 23 and 24 are greyed out
> >    4. Place the booking for May 25-26
> >    5. In the bookings tab, move the second booking to May 24-25
> >       --> It worked
> >    6. In the table, the dates are not updated
> >       --> First booking in the calendar is 22-23, in the table it's 22-24
> >       --> The second booking (the one that was moved) in the calendar is
> > 24-25, in the table it's 25-27

> My bookings are still taking one extra day than what I select. I'm guessing
> this is by design? For example, I booked something from Sept. 2 to Sept. 4
> https://snipboard.io/X4wGIL.jpg In the calendar view, I see it is booked
> from the 2nd to the 4th, but in the table view, it says it's booked until
> the 5th. https://snipboard.io/zmD3fu.jpg 

This is a sandboxes issue.. we can't set the correct location in the koha-conf
to match your locality and as such timezone handling doesn't work.  I've got an
ongoing discussion about this with Jonathan D.. it's not a new bug here.. it's
just that this work highlights it particularly strongly.

> When I move it manually, it is not updated in the table.
> https://snipboard.io/3fZbxj.jpg

Working on this now, seems a regression in rebasing.

> >
> > Usability comments:
> > 
> > -  The patron search is not the same as elsewhere. I don't mind this version
> > but for usability I think it would be best to have the same search
> > everywhere.
> >    (Summary of IRC discussions 
> >    - Martin said the traditional search doesn't work well with modals
> >    - Katrin said the traditional search works better for large datasets, so
> > you can limit by library or category
> >    - Martin said he'd work on a middle ground)
> >    Maybe an alternative would be to make it work like the holds, i.e. send
> > to a page with the form, the calendar and the table...
> > 
> 
> I honestly don't remember what the patron search was before, if you changed
> it. It is still different from any other patron search in Koha, and doesn't
> allow to limit by library or category like Katrin mentioned. I don't think
> this would be a blocker, I think most people would scan the card or type in
> the name. But maybe something to think about in the future as we try to make
> Koha uniform and consistent.

I'm reverting to just using the patron_autocomplete function we have elsewhere
and will deal with converting those to a nicer select2 implementation in a
distinct bug.

> 
> I also thought bookings could be set by item type (like, all LAPTOP items
> could be bookable by default, etc.). Then you could use the flag on an
> item-per-item basis if needed. It's just that if you have a lot of items you
> want to be bookable, it's a pain to change them one by one as it is
> currently not an option in the items batch modification form. That could be
> in a follow-up.

The switch to item specific level was at ByWaters request.  I think adding
options for itemtype level should be a later bug hanging off this one too.

> New (?) blocker bugs
> 
> -  When I select 'Any item' (https://snipboard.io/X4wGIL.jpg), the booking
> is placed for the specific item (https://snipboard.io/zmD3fu.jpg). I thought
> at first it was because there was only one item that was bookable on the
> record, but I made more items bookable after the booking was made and it
> stayed on the specific item. And when I added another booking for 'Any item'
> (https://snipboard.io/BPw8iy.jpg) it put it for the same specific item
> (https://snipboard.io/w4YBk9.jpg). It also doesn't block the booked dates if
> I try to make another booking for 'Any item'
> (https://snipboard.io/iNVWS4.jpg).
> I tried placing a new booking for 'Any item' with the same dates, and it
> just added it to the same row (https://snipboard.io/nJhEk0.jpg).
> 
> - I noticed in the Bookings tab of the patron file that there are hours to
> the start and end dates (https://snipboard.io/P85tHo.jpg). I don't know how
> I managed to make a booking from 4 to 3:58... If we permit bookings with
> hours, we should be able to choose them when making the booking, and show
> the hours everywhere. If not, then displaying only date would be sufficient
> (and have the saved date be 00:00 to 23:59?).
> 
> - I don't have access to the DB in the sandbox, but I made a report to see
> what it looked like. This might be philosophical, but I think we should
> stick to borrowernumber, biblionumber and itemnumber as column names. Unless
> it was decided otherwise in a dev meeting that now borrowers are patrons and
> everything is _id in the DB...
> 

Working on these now.

-- 
You are receiving this mail because:
You are watching all bug changes.