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

[Bug 24841] New: REST API should check if patron is restricted/debarred
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24841 Bug ID: 24841 Summary: REST API should check if patron is restricted/debarred Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Bug 17247 "ILS-DI HoldTitle and HoldItem should check if patron is restricted" adds checks to see if the patron is restricted before a hold is placed. These checks are added to C4::ILSDI::Services::HoldItem() and C4::ILSDI::Services::HoldTitle(). As far as I can tell, the same checks are missing from the REST API, specifically for "POST /api/v1/holds". Koha::REST::V1::Holds::add() does call C4::Reserves::CanItemBeReserved() and C4::Reserves::CanBookBeReserved(), but as far as I can tell, those subs do not check if the patron in question is debarred. Am I missing something or is this a bug? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 32974] New: Allow different limits for hold the shelf holds vs holds on checked out items
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32974 Bug ID: 32974 Summary: Allow different limits for hold the shelf holds vs holds on checked out items Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: rkuiper(a)roundrocktexas.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We would like to see a function in Koha where the hold limit is separated into two limits. One limit for on-the-shelf holds and another limit for holds on items checked out. Currently, we can allow or not allow on-the-shelf holds. We would like to see this expanded to specify the number of holds allowed if we have on-the-shelf holds turned on. Then there would be a separate limit that is for items that are checked out or on order. The reason for separating these is so we can manage staff time on the holds to pull list and still allow patrons to put holds on popular items and items that are new to the library. Our plan would be to allow something like 7 holds for on-the-shelf holds and allow unlimited holds for checked out and on order items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29505] New: Add syspref to allow to place multiple holds on same item
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29505 Bug ID: 29505 Summary: Add syspref to allow to place multiple holds on same item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 26038] New: Accessibility: 4.1.3 Status Messages
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26038 Bug ID: 26038 Summary: Accessibility: 4.1.3 Status Messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: oleonard(a)myacpl.org, testopia(a)bugs.koha-community.org Blocks: 23003 The intent of this Success Criterion is to make users aware of important changes in content that are not given focus, and to do so in a way that doesn't unnecessarily interrupt their work. The intended beneficiaries are blind and low vision users of assistive technologies with screen reader capabilities. An additional benefit is that assistive technologies for users with cognitive disabilities may achieve an alternative means of indicating (or even delaying or supressing) status messages, as preferred by the user. The scope of this Success Criterion is specific to changes in content that involve status messages. A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message: https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23003 [Bug 23003] Accessibility improvements -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 18303] New: Release team omnibus
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18303 Bug ID: 18303 Summary: Release team omnibus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: nengard(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 34360] New: [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34360 Bug ID: 34360 Summary: [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Seeing this warn on current master: [2023/07/24 13:37:03] [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /usr/share/koha/Koha/Objects.pm line 421 Refers to sub get_column { my ($self, $column_name) = @_; => return $self->_resultset->get_column( $column_name )->all; } get_column is called in the accessors of Koha/Object AUTOLOAD. This warn must have been triggered already by doing a catalogue search in staff from the main page. Some join or prefetch on staff detail ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 34263] New: Suspending holds consecutively populates previously used date falsely
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34263 Bug ID: 34263 Summary: Suspending holds consecutively populates previously used date falsely Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Place 3 holds on a patron account. 2. Suspend hold #1 and set date for 9/5/2023 or future date. 3. Suspend the hold for item #2. The pop-up modal shows a pre-filled suspend date of 9/5/23 (or the future date you chose). After confirming the suspend and returning to the holds list you'll see that no date shows up / the hold has been suspended indefinitely. 4. Suspend the hold for item #3. The pop-up modal has pre-filled the suspend date again to 9/5/23 (or future date used). However, re-selecting the date from the date picker correctly sets the date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 30554] New: Wrong display of authorities records in the Authority search plugin
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30554 Bug ID: 30554 Summary: Wrong display of authorities records in the Authority search plugin Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.breuillard(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Once the search is done with this plugin some of the authorities are wrong displayed because parts and links are missing. It is not the case if the search is made via authority mobile -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 25071] New: Explain close budget vs make budget inactive
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '25

01 Jul '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25071 Bug ID: 25071 Summary: Explain close budget vs make budget inactive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I noticed that if you try to close a budget with no unreceived orders, it doesn't work. You have to go edit the budget and make it inactive. I didn't test to see if you close a budget with unreceived orders, if it also makes it inactive or if you have to edit the budget to make it inactive after rolling over your unreceived orders. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34313] New: Make password validation endpoint return patron ids
by bugzilla-daemon＠bugs.koha-community.org 30 Jun '25

30 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34313 Bug ID: 34313 Summary: Make password validation endpoint return patron ids Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com With the `identifier` parameter passed for validating a password, as introduced by bug 32739, the identifier will be matched against `userid` and `cardnumber`. It would be useful to return both the userid and cardnumber of the patron if validation is correct. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32