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

[Bug 18686] New: TalkingTech_itiva_outbound.pl fails with Illegal mix of collations
by bugzilla-daemon＠bugs.koha-community.org 25 Apr '23

25 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18686 Bug ID: 18686 Summary: TalkingTech_itiva_outbound.pl fails with Illegal mix of collations Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: larry(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the big bug fix to clean up UTF8 (bug 11944), the default collation was set to utf8_unicode_ci. However on sites that predate that change, the overduerules table may still use utf8_general_ci. This leads to the following error when running the cronjob TalkingTech_itiva_outbound.pl: DBD::mysql::st execute failed: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' [for Statement "SELECT borrowers.borrowernumber, borrowers.cardnumber, borrowers.title as patron_title, borrowers.firstname, borrowers.surname, .... [snip] .... "] at /usr/share/koha/bin/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl line 230. The problem is fixed manually by altering table overduerules and changing its collate setting. However, perhaps there should be a fix in updatedatabase.pl to change the collate if the table is still using the old value. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 21762] New: ES: Is it possible to differentiate between any and anywhere?
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '23

17 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21762 Bug ID: 21762 Summary: ES: Is it possible to differentiate between any and anywhere? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl See also bug 8962 about differentiating any from anywhere in Zebra. Any would be the sum of all user defined indexes, and anywhere would really be all data. Is this possible in Elastic Search ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 18280] New: Item barcodes should be locked when record is created
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18280 Bug ID: 18280 Summary: Item barcodes should be locked when record is created Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When several cataloguers are cataloguing simultaneously and the autoBarcode system preference is set to generate the barcodes in 1, 2, 3 form, it is possible that the same item barcode will be assigned to two different items at the same time which prevents the record from being saved. Koha should lock the barcode in some way once it has been allocated, even if the item record is not yet saved. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 18618] New: Mana - Add reading suggestions (crontab - scripts)
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18618 Bug ID: 18618 Summary: Mana - Add reading suggestions (crontab - scripts) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 18496] New: Membership renewal fee
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18496 Bug ID: 18496 Summary: Membership renewal fee Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: amitddng135(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This feature help to collect the fees while renewal of membership. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 20913] New: allow multiple if/unless statements in MARC modification template actions by adding AND/OR qualifiers
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20913 Bug ID: 20913 Summary: allow multiple if/unless statements in MARC modification template actions by adding AND/OR qualifiers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: hughr(a)brimbank.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org Actions in MARC Modification templates have the following syntax: [action] all/first [field] (plus optionally... if/unless [field] [conditional]) But there is only the option for one if/unless. This is usually enough, but sometimes it would be useful to be able to add another qualifier linked with and/or. For example, libraries importing embedded items might want to apply a different shelf location or call number depending on the home location. In this case, they would want to do something like: Add/Update field '952c' with value 'Animals' IF field '984c' matches /^(57+[0-9]+.?.*)/ AND IF field '952a' matches 'Main' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21255] New: memberetnry.pl is missing categories in the Category pull-down list
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21255 Bug ID: 21255 Summary: memberetnry.pl is missing categories in the Category pull-down list Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnighswonger(a)foundations.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In some instances, when editing a patron, the Category pulldown under the "Library management" section is missing categories. I'm at a loss as to how to accurately describe the problem, but here goes: 1. The given patron's category shows up correctly on every other screen. 2. Navigating to the Patron Detail screen and selecting the edit option for Library use section results in the Modify Patron screen. 3. The heading on the Modify Patron screen displays the correct category. 4. However, the Category pulldown does not. 5. Furthermore, the pulldown does not even contain the correct category for the given patron. Doing a bit of looking around turned up a few things which may or may not be related. For the given patron: 1. The problem seems to be with the child category. 2. The Koha::Patron::Categories object may contain missing or incorrect category information. Here is a snip of the object returned for the 'C' category type by this line http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=members/memberent… 'attrs' => { 'bind' => [], 'join' => 'categories_branches', 'order_by' => [ 'categorycode' ], 'where' => { 'category_type' => 'C', 'categories_branches.branchcode' => [ 'JL', undef ] }, 'alias' => 'me' }, 3. The underlying data appears to be sound. 4. This was not a problem prior to upgrading a month ago. Unfortunately, I'm not sure what version this system was at prior to the upgrade. Maybe this will get the discussion started and someone with more knowledge of this area of the code can give some direction to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 19436] New: Add SRU support for authorities
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '23

04 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19436 Bug ID: 19436 Summary: Add SRU support for authorities Change sponsored?: --- Product: Koha Version: master 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be great if Koha also supported SRU for authorities, as libraries like the National Library of Germany only support SRU and no longer offer Z39.50 access. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 57

[Bug 17515] New: Advanced Editor - Rancor - Z39 sources not sorted properly
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '23

31 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17515 Bug ID: 17515 Summary: Advanced Editor - Rancor - Z39 sources not sorted properly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This appears to be a bug, the list of servers is retrieved from the database in order, however, it is stored in an unordered object, so the lists are posted to the page in a random order. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 17649] New: Create only one message per borrower and overdue level
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '23

30 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17649 Bug ID: 17649 Summary: Create only one message per borrower and overdue level 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: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Following a discussion on french list koha-infos, it appears that, among other ones, 2 things are expected from the overdue_notices.pl script (but not currently achieved) : 1) It should be possible to send only one message grouping all branches overdue items with same delay level => by now there are as much messages sent as overdue items branches with same level ( a patron that have overdue with same level in library A and B will received 2 messages claiming the same items.) This patch try to solve this problem ( provided to use only a default notice model in Notices and Slips). It introduces a new option (a|all_in_one) that has to be followed by a branchcode from which will be set the sender address of the message. 2) each branch should be able to send claims including only its very overdue items => by now messages also include, if they exist, all overdues with same delay level from other branches, even if library option is used. Patch from bug 17470 aims to solve this problem. Test plan (almost entirely and shamefully copied from bug 17470 !) 0/ Have (or create) at least two branches B1 and B2. Have (or create) a default notice for all branches in Notices and Slips Module 1/ Make sure you're logged in with an account belonging to B1, or switch to branch B1 2/ checkout item I1 (belonging to B1) to patron P (preferably while specifying a due date < today) 3/ switch to branch B2 4/ checkout item I2 (belonging to B2) to patron P (preferably while specifying a due date < today) 5/ make sure you have defined "Overdue notice/status triggers" for that patron category, ie with Delay=1 so that "Overdue Notice" is selected and "Email" is checked. 6/ from cli run 'perl ./misc/cronjobs/overdue_notices.pl' (optionally specifying also '-library B1 -library B2') example (say that B2CODE is the branchcode of B2 branch ): ./overdue_notices.pl -t -a B2CODE 7/ Two new entries will be generated in message_queue DB table, coming from different branches that have the SAME list of overdue items 8/ either see the 'content' field in these entries, or run 'perl ./cronjobs/process_message_queue.pl' to receive the actual emails (provided the email is properly setup). Apply patch redo step 6/ You will see that only one message had been created. Its content shows both B1 and B2 overdue items and the sender address matches B2 address as well. Olivier Crouzet -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45