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

[Bug 21946] New: Group circulation by item type
by bugzilla-daemon＠bugs.koha-community.org 05 May '22

05 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21946 Bug ID: 21946 Summary: Group circulation by item type Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: kyle(a)bywatersolutions.com Reporter: jesse(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Group rules based on item type in order to restrict circulation. In other words, not allow more than x items to be checked out across all media type item types (DVD, VHS, Blue Ray) and not just 4 checkouts per type. Currently patrons can bypass the circulation rules and take out 4 DVDs and 4 VHS and still be within the system limitation but in reality have just taken out 8 media items. This development would allow for the grouping of materials in order to keep that 4 media limit across all types. 1 - Extend the itemtypes table to allow an itemtype to have a parent type 2 - When circulating an item the specific itemtype circulation rules will apply unless unset 3 - For itemtypes with a parent the parent rule will apply when child rule is unset -- You are receiving this mail because: You are watching all bug changes.

1 171

[Bug 30474] New: Convert tools pages tabs to Bootstrap (part 1)
by bugzilla-daemon＠bugs.koha-community.org 05 May '22

05 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30474 Bug ID: 30474 Summary: Convert tools pages tabs to Bootstrap (part 1) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 29226 Continuing the process of phasing out jQueryUI, this patch will replace jQueryUI tabs in a few tools templates with Bootstrap: - additional-contents.tt - batch_delete_records.tt - batch_record_modification.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29226 [Bug 29226] OMNIBUS: Replace the use of jQueryUI tabs -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 30270] New: Use numeric inputs instead of dropdowns for hold priority
by bugzilla-daemon＠bugs.koha-community.org 04 May '22

04 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30270 Bug ID: 30270 Summary: Use numeric inputs instead of dropdowns for hold priority Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Currently we load a dropdown menu with the range of priority optins when listing holds on request.pl For a record with many holds (100+) this dropdown is large, and difficult to use The page size when loading this many dropdowns is also large We can reduce the problem by using numeric inputs and allowing the user to type new numbers, rather than selecting -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 25436] New: Google SSO
by bugzilla-daemon＠bugs.koha-community.org 04 May '22

04 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25436 Bug ID: 25436 Summary: Google SSO Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: Diwakar.j(a)inspiria.edu.in QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We would like to single sign in/off through our google g-suite email id. or integration with google directory with Koha users, so we do not need to create users manually. If any one of those possible, kindly share the steps or advise. Regards, Diwakar -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 27078] New: Starman hanging in 3-node Koha cluster when 1 node goes offline.
by bugzilla-daemon＠bugs.koha-community.org 04 May '22

04 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27078 Bug ID: 27078 Summary: Starman hanging in 3-node Koha cluster when 1 node goes offline. Change sponsored?: --- Product: Koha Version: 20.05 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: rcmcdonald91(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org So I've got a pretty interesting case that I've been playing with for the past several weeks. My goal has been to build a converged 3-node Koha cluster. The architecture looks like this: 1. Each node runs the "standalone" Koha stack (Koha, Starman, Apache, ElasticSearch, Memcached, MariaDB). For the sake of example, these nodes are 10.10.100.51, 10.10.100.52, and 10.10.100.53. 2. Galera is used to build the 3-node MariaDB cluster and each Koha node simply talks to the MariaDB server at localhost. This has worked fine and koha is blissfully unaware of the underlying galera cluster. 3. ElasticSearch is built in a 3-node cluster. koha-conf.xml is configured to use all three ES nodes (again at 10.10.100.51, 10.10.100.52, and 10.10.100.53). Again, koha doesn't seem to mind this at all. 4. All three nodes run Memcached and koha-conf.xml is configured to use all three Memcached nodes (again at 10.10.100.51-3). 5. Plack is enabled on all nodes using koha-plack --enable instancename && koha-plack --start instancename. 6. GlusterFS is used to serve up a 3-node replicated volume for /etc/koha/*, /usr/share/koha/*, and /var/lib/koha* across all three nodes. symlinks are used to present this storage in places koha is expecting them to be. Again, this works great. 6. Two HAProxy instances sit in front of these three koha instances (at 10.10.100.2 and 10.10.100.3). koha_trusted_proxies in koha-conf.xml is configured with these two IPs. 7. Finally, HAProxy handles SSL-offloading and client stickiness. This all works fine too. Here is the weirdness... When all three nodes are online, everything is absolutely fine. Everything is snappy, searching works, etc. When I change koha-conf.xml on one node, this is replicated to the other nodes immediately. However, when one node goes offline, the two remaining nodes become really sluggish. I've narrowed this down to a Starman/Plack issue, but I have no idea why. Here's how I arrived at that conclusion. * I started by killing pertinent services one-by-one on Node A. Killing MariaDB on Node A had no effect on Node B and C... though as expected, Node A started spitting out errors that the DB was unavailable. * Next, I stopped Memcached on Node A. Again, this had no effect on Node B and C. * Next, I stopped ElasticSeasrch on Node A. Again, this had no effect on Node B and Node C. * Next, I stopped GlusterFS on Node A. Again, this had no effect on Node B and Node C. * Next, I stopped koha-common on Node A. Again, this had no effect on Node B and Node C. So at this point, Node A is still "online." However, every service related to Koha is stopped (MariaDB, Memcached, ElasticSearch, Apache, koha-common, etc.). As expected, Node B and C keep on working just fine. Here is the weird part, When Node A actually goes offline (i.e. loses network connectivity and/or powers down), Node B and C become very very slow. They still serve traffic, but they are really sluggish. As soon as connectivity is restored to Node A, Node B and Node C speed right back up again. So is this related to Starman/Plack? When I disable Starman/Plack on all nodes, the speed of each node doesn't change when a single node goes offline. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 30509] New: Accordion on letter.tt is broken
by bugzilla-daemon＠bugs.koha-community.org 03 May '22

03 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30509 Bug ID: 30509 Summary: Accordion on letter.tt is broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org At '/cgi-bin/koha/tools/letter.pl' the accordion for changing between Email, Print, SMS notice templates is broken. All of the templates are showing at the same time. It looks to be related to a JS error coming from letter.js: Uncaught TypeError: t.find(...).even is not a function -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 30525] New: Items batch modification broken
by bugzilla-daemon＠bugs.koha-community.org 03 May '22

03 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30525 Bug ID: 30525 Summary: Items batch modification broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Items batch modification is broken looks like it is since Bug 29957 I get the error : Can't call method "value" on an undefined value at /kohadevbox/koha/tools/batchMod.pl line 87 86: my %cookies = parse CGI::Cookie($cookie); 87: my $sessionID = $cookies{'CGISESSID'}->value; -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 30376] New: Unable to save item if field date acquired is set mandatory
by bugzilla-daemon＠bugs.koha-community.org 03 May '22

03 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30376 Bug ID: 30376 Summary: Unable to save item if field date acquired is set mandatory Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you set 952$d (date acquired or "dateaccessioned") as mandatory in your MARC framework, you'll be unable to edit or add items because item form validation fails with error "1 mandatory fields empty". To reproduce: 1. Edit a MARC framework of your choice (e.g. Default) 2. Locate 952$d "Date acquired" and click Edit /cgi-bin/koha/admin/marc_subfields_structure.pl?op=add_form&tagfield=952&frameworkcode=#subdfield 3. Tick "Mandatory" checkbox 4. Save changes 5. Edit any item using MARC framework you edited in step 1 /cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=123&itemnumber=456 6. Set "Date acquired" to any date 7. Click Save 8. Observe error "- 1 mandatory fields empty (highlighted)" (JavaScript alert) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 30076] New: Add ability to check patron messaging preferences from a notice
by bugzilla-daemon＠bugs.koha-community.org 03 May '22

03 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30076 Bug ID: 30076 Summary: Add ability to check patron messaging preferences from a notice 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries want to be able to use a patron's messaging preferences to conditionally change the contents of a notice depending on the patron's other messaging preference. For example, a library has requested to have the note on the hold slip if the patron has requested phone messages for waiting holds. This really only entails adding a method to the Koha::Patron class to allow this type of looking. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 23702] New: New UNIMARC XSLT
by bugzilla-daemon＠bugs.koha-community.org 03 May '22

03 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23702 Bug ID: 23702 Summary: New UNIMARC XSLT Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: stephane.delaye(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 93308 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=93308&action=ed… xslt unimarc intranet detail In attachments the new xslt files UNIMARC and zebra configuration files. The xslt file call new index about the link fields(4xx). The news: -add fields for the bibliographic transition(181,182,183,214) -add fields 923 and 924 for display better the summaries of collection -display better the punctuation isbd -fields 600 à 608 : search the string with phr and not with number authority ..etc Test plan 1.Install the intranet xslt files into : ~/src/koha-tmpl/intranet-tmpl/prog/en/xslt 2.Install the opac xslt files into : :~/src/koha-tmpl/opac-tmpl/bootstrap/en/xslt 3.Install the file 'biblio-koha-indexdefs.xml' into /home/koha/etc/zebradb/marc_defs/unimarc/biblios/ 4.Install the file 'ccl.properties' into /home/koha/etc/zebradb/ 5.Install the file 'bib1.att' into/home/koha/etc/zebradb/biblios/etc/ 6.Run the indexation cd /home/koha/tools/zebra;update_xsl_config.sh -a -b;./rebuild_full.sh -b -a; -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55