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

[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 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

[Bug 20417] New: Remove OpacCloud system preference and feature
by bugzilla-daemon＠bugs.koha-community.org 02 May '22

02 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20417 Bug ID: 20417 Summary: Remove OpacCloud system preference and feature 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org This is a poorly implemented old fashioned "word cloud". I think it could be entirely removed. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 28111] New: Add file grouping and granular permissions to the 'Access files' tool
by bugzilla-daemon＠bugs.koha-community.org 02 May '22

02 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28111 Bug ID: 28111 Summary: Add file grouping and granular permissions to the 'Access files' tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org In comment 29 on bug 11317 I suggested that perhaps the feature could/should include the ability to refine access control for the different directories one might expose to the tool. That didn't happen at the time, but would still be a nice enhancement. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 24074] New: Access directory UX improvements
by bugzilla-daemon＠bugs.koha-community.org 02 May '22

02 May '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24074 Bug ID: 24074 Summary: Access directory UX improvements Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I noticed a few things about this feature when I was setting it up (which by the way, I LIKE A LOT!!) - We cannot do subdirectories here. We should allow that? - Multiple access directories don't show the path, that seems like useful information we should have - either we should pick the directory we want before we see the list, or we should show the path to the file. An example of a use case would be that a library wants to put their print notices there, but they also put other things in that access directory. They may only want to see the directory that has the notices in it. Currently we can't do that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 25674] New: Add RabbitMQ options to koha-create
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '22

29 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25674 Bug ID: 25674 Summary: Add RabbitMQ options to koha-create Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Now that we plan to use RabbitMQ as message broken for a task queue manager, we need to be able to set the RabbitMQ options on instance creation. It should fallback to localhost, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 52

[Bug 27756] New: background_jobs_worker.pl is memory inefficient
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '22

29 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27756 Bug ID: 27756 Summary: background_jobs_worker.pl is memory inefficient 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Once Perl allocates memory, it doesn't return that memory to the Operating System for the life of that Perl process. If memory is freed within a Perl program (nullifying a variable, for instance), that memory will be re-used within the Perl program, but it will not return the memory. This can cause unexpected excessive memory consumption for long-running Perl programs. misc/background_jobs_worker.pl runs all its code within the same process, so it will never return allocated memory. This means that 1 large background import could cause background_jobs_worker.pl to permanently use a large amount of memory (until it is restarted). The solution is to do the background work within a forked process. I was reminded of this when I read "The worker process will fork a new process for every job that is being processed. This allows for resources such as memory to be returned to the operating system once a job is finished. Perl fork is very fast, so don't worry about the overhead" at https://docs.mojolicious.org/Minion. It's the same premise as bug 27267. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 29411] New: Single result for checkout search by name should redirect to check out tab
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '22

29 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29411 Bug ID: 29411 Summary: Single result for checkout search by name should redirect to check out tab 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In bug 15812 the code was switched to redirect to members.pl if a single hit was not found by barcode. The members results page redirects to moremember if a single result is returned to the template. In the case of a 'circsearch' we should redirect to checkout, not member details -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 27077] New: Searching for patrons with guarantor_id criteria results in 500 error
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '22

28 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27077 Bug ID: 27077 Summary: Searching for patrons with guarantor_id criteria results in 500 error 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: arthur.suzuki(a)biblibre.com Tried to fetch all patrons who's guarantor is "someone", got 500 error. Due to changes in the borrower table to permit multiple guarantor. Curl command : <pre> curl http://localhost:8080/api/v1/patrons?guarantor_id=42 \ -H 'Authorization: Basic a29oYTprb2hh' </pre> Plack error log : <pre> [2020/11/23 10:20:33] [WARN] Use of uninitialized value $column_type in string eq at /kohadevbox/koha/Koha/Object.pm line 447. [2020/11/23 10:20:33] [WARN] DBD::mysql::st execute failed: Unknown column 'guarantorid' in 'where clause' [for Statement "SELECT `me`.`borrowernumber`, `me`.`cardnumber`, `me`.`surname`, `me`.`firstname`, `me`.`title`, `me`.`othernames`, `me`.`initials`, `me`.`streetnumber`, `me`.`streettype`, `me`.`address`, `me`.`address2`, `me`.`city`, `me`.`state`, `me`.`zipcode`, `me`.`country`, `me`.`email`, `me`.`phone`, `me`.`mobile`, `me`.`fax`, `me`.`emailpro`, `me`.`phonepro`, `me`.`B_streetnumber`, `me`.`B_streettype`, `me`.`B_address`, `me`.`B_address2`, `me`.`B_city`, `me`.`B_state`, `me`.`B_zipcode`, `me`.`B_country`, `me`.`B_email`, `me`.`B_phone`, `me`.`dateofbirth`, `me`.`branchcode`, `me`.`categorycode`, `me`.`dateenrolled`, `me`.`dateexpiry`, `me`.`date_renewed`, `me`.`gonenoaddress`, `me`.`lost`, `me`.`debarred`, `me`.`debarredcomment`, `me`.`contactname`, `me`.`contactfirstname`, `me`.`contacttitle`, `me`.`borrowernotes`, `me`.`relationship`, `me`.`sex`, `me`.`password`, `me`.`flags`, `me`.`userid`, `me`.`opacnote`, `me`.`contactnote`, `me`.`sort1`, `me`.`sort2`, `me`.`altcontactfirstname`, `me`.`altcontactsurname`, `me`.`altcontactaddress1`, `me`.`altcontactaddress2`, `me`.`altcontactaddress3`, `me`.`altcontactstate`, `me`.`altcontactzipcode`, `me`.`altcontactcountry`, `me`.`altcontactphone`, `me`.`smsalertnumber`, `me`.`sms_provider_id`, `me`.`privacy`, `me`.`privacy_guarantor_fines`, `me`.`privacy_guarantor_checkouts`, `me`.`checkprevcheckout`, `me`.`updated_on`, `me`.`lastseen`, `me`.`lang`, `me`.`login_attempts`, `me`.`overdrive_auth_token`, `me`.`anonymized`, `me`.`autorenew_checkouts` FROM `borrowers` `me` WHERE ( `guarantorid` LIKE ? )" with ParamValues: 0="%42%"] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. </pre> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 22204] New: Leading spaces in barcode should not allowed in cataloguing
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '22

28 Apr '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22204 Bug ID: 22204 Summary: Leading spaces in barcode should not allowed in cataloguing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When creating a new item, it is not allowed to add trailing spaces, it shows 'Barcode must be unique'. But it is allowed to use leading spaces :( In this case since circulation does a trim on barcode this item can not be checked-out. It also allows duplicates even with UNIQUE KEY constraint. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29