March 2022 - Koha-bugs - lists.koha-community.org

[Bug 19421] New: Predue Notices should work like Overdue Notices
by bugzilla-daemon＠bugs.koha-community.org 24 May '24

24 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19421 Bug ID: 19421 Summary: Predue Notices should work like Overdue Notices Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently Advance due notices (pre-due) follow the patron's holding branch and it would be more beneficial that they follow the item's holding branch. When a patron takes out an item from another branch, they should receive the information and rules from the library that the item is from as it could be different from their own home branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 29085] New: Add an alert when deleting a vendor linked to a subscription
by bugzilla-daemon＠bugs.koha-community.org 24 May '24

24 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29085 Bug ID: 29085 Summary: Add an alert when deleting a vendor linked to a subscription Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Currently (20.05), when deleting a vendor, there is no alert to check if a subscription is linked to the vendor. if the vendor is deleted anyway, in the subscription, the vendor box is empty but the booksellerid remains visible. When editing a subscription, an error message appears because the vendor is no longer found. see the following video https://www.screencast.com/t/5oi85cCFGclS Can an alert be added to mean that the vendor should not be deleted as it is used in a subscription? Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 23241] New: Does misc/bin/koha-index-daemon-ctl.sh still belong in community koha?
by bugzilla-daemon＠bugs.koha-community.org 24 May '24

24 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23241 Bug ID: 23241 Summary: Does misc/bin/koha-index-daemon-ctl.sh still belong in community koha? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have had a daemon mode in rebuild_zebra.pl for a long time and have been using that as the default indexing daemon for years.. Should we deprecate the above script to prevent confusion for new users where indexing should just work out of the box without the need for installing external dependancies. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 30136] New: Add back to top button when scrolling
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30136 Bug ID: 30136 Summary: Add back to top button when scrolling Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Like in many websites, when scrolling down the page make a button appear to go back to top. This can be very useful specially in search results page. -- You are receiving this mail because: You are watching all bug changes.

1 38

[Bug 24143] New: buildQuery should disable Query* on identifier search
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24143 Bug ID: 24143 Summary: buildQuery should disable Query* on identifier search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Currently, QueryWeightFields, QueryFuzzy, QueryStemming, QueryAutoTruncate are disabled in buildQuery in several cases: - Date of Publication - Date of Acquisition - ISBN,ISSN,Standard Number Those modifiers should also be disabled when searching on identifiers. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 28899] New: Don't always make = into : for elastic range searching
by bugzilla-daemon＠bugs.koha-community.org 23 May '24

23 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28899 Bug ID: 28899 Summary: Don't always make = into : for elastic range searching Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com For range searches, Elastic supports searches for ranges with one end bound, like "pubdate greater than or equal to 2020." Except the phrasing for that would be "pubdate:>=2020." And Koha wants to let us use either a colon or an equals sign after our index name, so it always converts an equals sign in to a colon, which means our query turns into "pubdate:>:2020" and we get an error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23067] New: in Opac Confirm holds page the Last location column is empty
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23067 Bug ID: 23067 Summary: in Opac Confirm holds page the Last location column is empty 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: christophe.croullebois(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- In opac-reserve.pl click on 'Show more options' select 'A specific item' Then you'll see a table with a column 'Last location' (holdingbranch) always empty if homebranch = holdingbranch. It would be better if this column shows always this location. opac/opac-reserve.pl # If the holdingbranch is different than the homebranch, we show the # holdingbranch of the document too. if ( $itemInfo->{homebranch} ne $itemInfo->{holdingbranch} ) { $itemLoopIter->{holdingBranchName} = $itemInfo->{holdingbranch}; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 22844] New: Simplify the process of selecting database columns for system preferences
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22844 Bug ID: 22844 Summary: Simplify the process of selecting database columns for system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- Created attachment 89322 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=89322&action=ed… Screenshot showing column selection in a modal window Right now the process of hand-typing the names of database columns in system preferences like BorrowerMandatoryField is cumbersome and error-prone. I would like to change to a system where the user can select from a predefined list of database columns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 170

[Bug 28561] New: Order_by triggers a DBIx warning Unable to properly collapse has_many results
by bugzilla-daemon＠bugs.koha-community.org 22 May '24

22 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28561 Bug ID: 28561 Summary: Order_by triggers a DBIx warning Unable to properly collapse has_many results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Make a list, few biblios with multiple items. Check the plack-opac-error.log [2021/06/14 11:51:45] [WARN] Use of uninitialized value $direction in string ne at /usr/share/koha/opac/opac-shelves.pl line 265. [2021/06/14 11:51:45] [WARN] Use of uninitialized value $direction in string ne at /usr/share/koha/opac/opac-shelves.pl line 265. [2021/06/14 11:51:45] [WARN] DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse has_many results in iterator mode due to order criteria - performed an eager cursor slurp underneath. Consider using ->all() instead at /usr/share/koha/Koha/Objects.pm line 335 Koha/Objects Line 335 says: my $result = $self->_resultset()->next(); The warning has to do with the sorting criteria. Disabling the order_by clause removes the warning. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 28594] New: Add ability to mark an item as retuned when resolving a claim
by bugzilla-daemon＠bugs.koha-community.org 20 May '24

20 May '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28594 Bug ID: 28594 Summary: Add ability to mark an item as retuned when resolving a claim Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is the inverse of bug 27753. While 27753 says we should be able to automatically resolve a claim when checking in an item, we should also be able to automatically mark an item as returned when resolving its claim. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3