Description
Laura Escamilla
2025-03-18 21:21:34 UTC
Created attachment 179482 [details] [review] Bug 39371: Added character limit to Holds to place (count) To test: 1. Go to place a hold for a patron. Under 'Hold next available item' the 'Holds to place (count) defaults to 1. When you go to edit the input you do not have a limit. You can enter an endless number. 2. Apply the patch. 3. Repeat step 1. When you go to edit the input now there is a 3 character limit. This should prevent accidentally scanning of barcodes in this area. 4. Sign off and have an amazing day! Created attachment 180408 [details] [review] Bug 39371: Add a max character limit to "Holds to place" To test: 1. Go to place a hold for a patron. Under 'Hold next available item' the 'Holds to place (count) defaults to 1. When you go to edit the input you do not have a limit. You can enter an endless number. 2. Apply the patch. 3. Repeat step 1. When you go to edit the input now there is a 3 character limit. This should prevent accidentally scanning of barcodes in this area. 4. Sign off and have an amazing day! I tried adding 10 holds for one patron, but only two got added. I assume this is because I have "Holds per record (count)" = 2 in the "Circulation and fine rules". Libraries could have a high number there and be annoyed if a high number of holds are added. But then they should have a high number there because they want to allow a high number of holds. Would it be possible to limit the field based on the "Holds per record (count)"? Would it make sense to also do this like the "Add multiple copies of this item" below the item cataloguing form? Where there is a limit on 3 characters, but there is also a JS confirmation, where you get asked "You are about to add 999 items. Continue?" I tested this on BibLibre sandbox and it worked as described. Though adding the confirmation window for any large number of reservations seems like a good idea. In connection to 'Holds per record' restriction in circulation rules, it would be really good to at least get a notice/warning that only X number of reservations can be / was made. If there's already plenty of resevations on the record, it can be quite hard to notice if all the new reservations were actually created. This could be another issue completely though. Sorry, I'll set this to "Failed QA" as at least two of us seem to agree it needs a little more work. It will be great to have the field not be completely free text, though! :-) ...and I forgot to change the status! Created attachment 183470 [details] [review] Bug 39371: Limit "Holds to place" input based on holds_per_record rule and prompt for multiple holds To test: 1. Go to place a hold for a patron. Under "Hold next available item," the "Holds to place (count)" field should default to 1. Before applying t Created attachment 183471 [details] [review] Bug 39371: Limit "Holds to place" input based on holds_per_record rule and prompt for multiple holds Test plan: 1. Go to place a hold for a patron. Under "Hold next available item," the "Holds to place (count)" field should default to 1. Before applying the patch, this input: * Has no maximum limit * Allows entry of any number, even extremely high values * Does not show a confirmation prompt 2. Apply the patch. 3. Repeat step 1. Now: * The maximum number of holds allowed is based on the holds_per_record circulation rule * If holds_per_record is set (e.g., 2), you cannot enter more than that * If it's blank (meaning unlimited), no max is set * A note appears under the input: * “The maximum number of holds to place is 2.” (or whatever the rule is) * Or: “There is no set maximum for holds.” if blank * If you enter more than 1, you will see a confirmation prompt: * “Are you sure you want to place 3 hold(s)?” * If you enter 1 hold, it proceeds without prompting 4. Try entering 0 or leaving the field blank: * The minimum is enforced as 1 * The system defaults back to placing 1 hold 5. Confirm that the input box: * Allows up/down arrows if a numeric max is set * Behaves correctly with keyboard input * Respects the configured circulation rule 6. Sign off and have an amazing day! 🎉 One of our coding guidelines warns against using input type "number": https://wiki.koha-community.org/wiki/Coding_Guidelines#ACC2:_Input_type_.22number.22_should_be_avoided I think it would be better to add some JS validation to check the valid range. There are a lot of whitespace changes in this patch. What's that about? |