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

[Bug 37160] New: spinelabel-print.pl print pop-up window should be configurable
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37160 Bug ID: 37160 Summary: spinelabel-print.pl print pop-up window should be configurable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 37159] New: Offline circulation should respect current transactions
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37159 Bug ID: 37159 Summary: Offline circulation should respect current transactions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We saw on a production server a confusion of renewals/checkouts arising from the processing of an older offline circulation file. When processing transactions, offline circulation should ignore previous checkouts if the item has been checked out to a new patron since the date of the offline transaction. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 37110] New: Replace record via Z39.50/SRU search to Advanced Editor
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37110 Bug ID: 37110 Summary: Replace record via Z39.50/SRU search to Advanced Editor Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: iming(a)rosewoodfarm.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Introduce "Replace record via Z39.50/SRU search" button to Advanced Editor like for the Normal Editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 37174] New: Patron’s checkout summary reports "0 of 0 renewals remaining" while circulation rules allow 3 renewals
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37174 Bug ID: 37174 Summary: Patron’s checkout summary reports "0 of 0 renewals remaining" while circulation rules allow 3 renewals Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: MZore(a)SterlingTech.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 168039 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168039&action=e… Data before (which fails) and after (which works) assigning branchcode to all records After upgrading from 23.11 to 24.05, renewals failed to work correctly using Circulation > Renew, the Renew option on the menu bar, or the Patron’s checkout summary. For example, the patron’s checkout summary reported all items as "Not Renewable (0 of 0 renewals remaining)" while the circulation rule for this patron category allows 3. I found an earlier bug issue from 2017 (Koha 16.11.04) in which deleting and recreating all categories resolved this issue (https://koha.katipo.co.narkive.com/PWWM7AWH/all-items-not-renewable) I created a new category, assigned a user to this category, and checked the Patron screen. For this single user, renewals returned to working properly. To avoid the work this solution would require, I checked the contents of table "circulation_rules". I found that branchcode was set to our correct code ("FCC") for the new entry, but was NULL for many of the properties in existing categories, including the patron category having the problem. I assigned the correct value to all entries using "UPDATE circulation_rules SET branchcode = 'FCC' WHERE branchcode IS NULL;" and the patron summary properly reported "(x of 3 renewals)" and allowed renewals. Checking a data backup from 2023, the NULL values existed in 23.11, so this data pre-existed the upgrade to 24.05 but the renewals operated correctly with this data in the earlier version. A backup of the circulation_rules table data before and after the change are attached. This was the only table modified to correct the symptom. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 37173] New: Add the ability to define several unavailable statuses based on different conditions
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37173 Bug ID: 37173 Summary: Add the ability to define several unavailable statuses based on different conditions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 36996 adds the ability to mark a set of items as 'Unavailable' in Z39 responses, but only allows for a single type of unavailable status. It would be nice to be able to specify an arbitrary number of different statuses -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 30280] New: Koha does not currently support authority posts with common subject headings from different thesaurus
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30280 Bug ID: 30280 Summary: Koha does not currently support authority posts with common subject headings from different thesaurus Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: frank.hansen(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org Consider this three following examples 650 _ 0 $a Feminism 650 _ 7 $a Feminism $2 sao 650 _ 7 $a Feminism $2 barn The first example above is the LCSH term. The two other sao (controlled Swedish subject heading system) and barn (Swedish children subject heading system). These three using basically the same TOPIC_TERM Feminism but they belongs to different thesaurus. According to https://www.loc.gov/marc/authority/ (Library of Congress), subject heading thesaurus/system is specified in 008/11 in the authority record. When other thesaurus/system is used, the value of 008/11 is "z" (Other) and the convention used is marked up in field 040$f. But Koha currently not seems to support the use of different thesaurus. The script link_bibs_to_authorites.pl will treat authority records with the same TOPIC_TERM from different thesaurus as duplicates and will not be able to link the subject heading to its corresponding authority record. We would like if Koha could let authority records from different thesaurus co-exist in Koha and "learn" Koha how to distinguish between them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 80

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33526 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33526 [Bug 33526] Use template wrapper for tabs: Bibliographic detail page -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28504] New: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup'
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28504 Bug ID: 28504 Summary: Hold pickup library match (hold_fulfillment_policy) not enforced when filling holds if set to "patron's group" / 'patrongroup' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The case is simply not covered in the code In C4::Reserves::CheckReserves: 908 my $hold_fulfillment_policy = $branchitemrule->{hold_fulfillment_policy}; 909 next if ( ($hold_fulfillment_policy eq 'holdgroup') && (!$library->validate_hold_sibling({branchcode => $res->{branchcode}})) ); 910 next if ( ($hold_fulfillment_policy eq 'homebranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 911 next if ( ($hold_fulfillment_policy eq 'holdingbranch') && ($res->{branchcode} ne $item->$hold_fulfillment_policy) ); 912 next unless $item->can_be_transferred( { to => Koha::Libraries->find( $res->{branchcode} ) } ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37169] New: Fix the POD for z3950_search_args
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '24

24 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37169 Bug ID: 37169 Summary: Fix the POD for z3950_search_args Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org https://git.koha-community.org/Koha-community/Koha/src/commit/b0b168b6f84ef… Lines 2143-2144 still claim it returns a URL encoded value, though when bug 12071 stopped it from doing that, it did fix another mention of the URL encoded value Lines 2148-2149 says that $matchpoints as a hash ref is bibliographic data from Biblio::GetBiblioData, but a hash ref $matchpoints can also be search data from an advanced search (and, not sure but it may very well be that even a simple keyword search passes a hash ref, since bug 11572 doesn't make much sense otherwise) Lines 2151-2153 are either completely wrong if we no longer ever pass a scalar search term, or are wrong that we always return 'title' since we return either that or 'isbn' if we sniff out that it's an ISBN. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 37095] New: Add a cli for creating a user that returns the user + an api key
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '24

23 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37095 Bug ID: 37095 Summary: Add a cli for creating a user that returns the user + an api key Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We have the create_superlibrarian script, but it would be nice to have a more generic create_user script where one could pass a list of permissions to assign to that user and also ask for an API key to be generated and returned too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3