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

[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 23021] New: Quick Spine Label Creator doesn't use regex splitting rule
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23021 Bug ID: 23021 Summary: Quick Spine Label Creator doesn't use regex splitting rule Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I'm working with a library that enters their LCC call numbers in the format "PN6728 .B36" rather than "PN 6728 .B36." This means that the default LCC splitting rule doesn't insert a line break between PN and 6728. So I wrote a regex splitting rule that does that fine. However, the regex splitting is only applied when using the full label creator. When printing via the quick spine label creator it appears to still be splitting based on the default LCC splitting rule. -- You are receiving this mail because: You are watching all bug changes.

1 3

[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 23079] New: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo)
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '23

13 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Bug ID: 23079 Summary: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo) 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- We keep having issues especially with the TZ America/Sao_Paulo in certain areas of Koha. The most recent error was the checkouts page showing "Internal server error" resolving to: Invalid local time for date in time zone: America/Sao_Paulo The date expiry of this patron was: 2019-12-03 Changing the date expiry date to be a day later (2019-12-04) fixed the issue. The patron currently has no checkouts. I am not sure yet if other settings factor into this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

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

08 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 23580] New: Add C4::Context->yaml_preference
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '23

06 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23580 Bug ID: 23580 Summary: Add C4::Context->yaml_preference 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I propose to add a way to retrieve the decoded YAML from (YAML) system preferences. This way we don't need to write code in vain for decoding them in-place. Also, I propose we move pipe-separated sysprefs into YAML lists. This raised on reviewing 22996. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[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 23616] New: Private repeatable note field needed in Serials Subscription Record
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '23

01 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23616 Bug ID: 23616 Summary: Private repeatable note field needed in Serials Subscription Record Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: niamh.walker-headon(a)it-tallaght.ie QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com It is useful to have a record of emails and dates of correspondence in the note field of a journal record in KOHA serials subscriptions. We want to keep this type of note for staff view only while still having the option of a public note also. Staff need to see at a glance what and when action is taken when a claim is escalated. When a missing journal eventually arrives and is marked arrived?, Currently, the notes in the note field must be deleted, as they will show on the OPAC. So the record of what happened is lost in KOHA serials. It would be useful to have a repeatable private note field as well as the public one. See: Electrical Times: https://librarysearch.it-tallaght.ie//cgi-bin/koha/opac-detail.pl?biblionum… ? On this record, See the note for July 2018. It is far easier to see what is happening when the notes are in KOHA serials than stored elsewhere. Serials - Record: Serials administrators need a repeatable private note field, for administration of the subscription and claiming processes. This field would be attached to the subscription field and would not display on the opac. Serials therefore needs two note fields in subscriptions. One for public display and a separate repeatable one for non-public display only. This change would also mean that we can change the status of an issue to “missing (not received)” and be able to explain this status further, such as “not published” or “combined with December issue” in the public note, while still being able to use the non public note for recording details in relation to correspondence and actions relating to claiming the missing issue. These notes are kept to observe patterns in failure to supply, issues with delivery, non-publication etc., so that staff know who was contacted when regarding issues about issues. Processing of serials claims would be more accurate and efficient. This simple change would allow the serials workflow to stay within the serials module making it more streamlined and efficient.Staff feel that this data does not belong on the marc record. Loss of information re business relationship and contractual efficiency with supplier. We currently use this note field to record any problems/correspondence in relation to subscriptions. It enables us to spot patterns in non-supply. On arrival of an issue we must then delete the notes from this field or they will show to the public. The history of correspondence/problems will now be lost. These notes can be useful for tracking ongoing/previous problems. Having to ensure that notes are deleted before displaying publicly allows for possible human error. As far as I can see, this is not the same issue as bues 11492 and 23416, but related -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5