May 2023 - Koha-bugs - lists.koha-community.org

[Bug 27462] New: Number of suggestions includes archived suggestions
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27462 Bug ID: 27462 Summary: Number of suggestions includes archived suggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 25033, 22784 On the main page the number of suggestions includes archived suggestions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22784 [Bug 22784] Add the ability to archive purchase suggestions https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25033 [Bug 25033] Counts of suggestions are confusing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 33846] New: 'Save' and 'close' buttons confusing on multi-receive
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33846 Bug ID: 33846 Summary: 'Save' and 'close' buttons confusing on multi-receive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I'm opening this so we don't forget. Talking with Kyle and Nick, we agreed the 'Save' button is weird, in the sense that it is not saving but updating the underlying table which can then be used to receive. And there's the 'Close' button, that seems to be doing the same thing i.e. closing the modal. Plus, there's no real way of 'resetting' your changes which is the usual thing we have: a confirm button and a cancel. I'm not sure what is the best solution here, but we could have: - Close (which updates the underlying table) - Cancel link (which resets any changes you've made) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 6903] Quantity for odering from suggestion should not default to 0
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6903 Tomás Cohen Arazi <tomascohen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33867 -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 32372] New: Calculate hold waiting expiration based on days closed
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32372 Bug ID: 32372 Summary: Calculate hold waiting expiration based on days closed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the ExcludeHolidaysFromMaxPickUpDelay is an on or off function. This is problematic with libraries that are closed several days in a week. It would be helpful if there were a threshold that could be set for this setting. The question would be, what kind of a threshold? For example, if ReservesMaxPickUpDelay is set to 7, and a pickup library is closed for 4 days in a week, if ExcludeHolidaysFromMaxPickUpDelay does not use the calendar, the expiration on the waiting hold will likely fall on a closed day, and also reduce the number of opportunities to be picked up. However, if ExcludeHolidaysFromMaxPickUpDelay is set to use the calendar, that same library will end up holding the item for more than two weeks to fulfill the 7 days. If ExcludeHolidaysFromMaxPickUpDelay uses the calendar, it would be helpful if there were an option to extend the ReservesMaxPickUpDelay to the closest open day past the closed dates. Perhaps something like MaxReservePickupExtentension, in which if it is blank or set to 0, it does nothing, like Koha does currently, but if it is set to a number of days, it would extend the expiration past the close date to the next open day that falls within the number of days defined. For example, ReservesMaxPickUpDelay is set to 7, and our proposed MaxReservePickupExtentension setting is set to 7 as well, and the pickup library is closed Sunday, Monday, Wednesday, and Friday. The pickup library receives the item on Tuesday, and instead of expiring on the following Monday when they are closed, Koha would look to the next open day (within 7 days past ReservesMaxPickUpDelay), which would be the following Tuesday. If there is no open days within the extra days defined in MaxReservePickupExtentension, it would keep the original expiration date, or more accurately, expire on the last open day before the closed expiration date. I hope that makes sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33866] New: ExcludeHolidaysFromMaxPickUpDelay needs individual library settings
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33866 Bug ID: 33866 Summary: ExcludeHolidaysFromMaxPickUpDelay needs individual library settings Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ExcludeHolidaysFromMaxPickUpDelay is useless to consortium that has libraries that are only open part time. This setting can delay items an extra week if used, while this would be a perfect setting for larger libraries that are usually open 7 days a week. It would be preferable if this setting were set under individual libraries rather than as an all or nothing setting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Andrew Nugged <nugged(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33864 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33864 [Bug 33864] Modal broken when "AcqCreateItem" set to "cataloguing" -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33702] Patrons should only see their own ILLs in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33702 --- Comment #15 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- What happened here? It's part of 22.11.x only now? RMaints? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33862] New: reserve_stats.pl: Cancelled holds are counted incorrectly under processing status
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33862 Bug ID: 33862 Summary: reserve_stats.pl: Cancelled holds are counted incorrectly under processing status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 23059 comment6. Please test the patch on 23059 to resolve this issue too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32522] New: Accessibility: Calendar widget in OPAC is read-only / doesn't allow for manually entering dates
by bugzilla-daemon＠bugs.koha-community.org 29 May '23

29 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32522 Bug ID: 32522 Summary: Accessibility: Calendar widget in OPAC is read-only / doesn't allow for manually entering dates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The date fields using the calendar widget in the OPAC are set to read-only, meaning that you can't type the date. This is a bad accessibility issue as the widget is hard to use for example with screen readers. In the staff interface the dates can be typed in. Example: * date of birth on the patron details / patron self registration form. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 30966] New: Record Overlay Rules - Fault in Z39.50 filter
by bugzilla-daemon＠bugs.koha-community.org 29 May '23

29 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30966 Bug ID: 30966 Summary: Record Overlay Rules - Fault in Z39.50 filter Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bjornbibblan(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We're setting up MARC Overlay Rules in 21.11.05. When defining the rules, we aren't able to make the filter Z39.50 work. A colleague checked the code and reports that line 876 in cataloguing/addbiblio.pl sets the source to z39.50. The source value should be z3950 to match the filter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33