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

[Bug 25939] New: Print multiple copies with quick spine label creator
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '23

04 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25939 Bug ID: 25939 Summary: Print multiple copies with quick spine label creator Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 For libraries that purchase several copies of the same title, it'd be nice to have a quicker way to print several copies of the same spine label. Maybe something on spinelabel-home.pl that would let the user specify a number of copies? -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 29174] New: Availability colors are not consistent in the codebase
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '23

04 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29174 Bug ID: 29174 Summary: Availability colors are not consistent in the codebase Change sponsored?: --- Product: Koha Version: master 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org OPAC Results has three blocks: Available for loan, Available for reference (a subset of some not for loan categories, see pref Reference_NFL_Statuses and Not available (some not for loans, checked out, damaged, etc) The not available group is RED, the two available groups are GREEN. At least talking about opac-search. (And opac-shelves too.) But now we still need to address a few other spots where we use these colors: opac-detail shows the reference items RED! opac-basket does the same. Would you know more code locations? It seems that staff already uses another algorithm to choose for RED. On catalogue detail red is used only for damaged, lost, etc? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[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

[Bug 23567] New: Printable QR links
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '23

01 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23567 Bug ID: 23567 Summary: Printable QR links Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Suppose there were a tool that would allow you to process items, much like you would for spine labels, but instead printed custom messages along with a QR code to useful things. For example, you might select a "Comment QR label". You would enter a generic message like "Tell us what you thought of this book." Labels would print for each item with this message, and the QR code beneath, and you would affix this label inside the back of the book. When the patron is done reading the book, they scan the code, and it takes them straight to the comment form in the OPAC (after signing in, if required) for that book, and they can fill out a comment right on their device. Other options, instead of comments, might include rating, tagging, or bragging about the book in a specific social media. For example, they scan the QR code and it would go to Facebook and start a post with a link to the book in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 28373] New: Items fields not used in default XSLT
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '23

31 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28373 Bug ID: 28373 Summary: Items fields not used in default XSLT Change sponsored?: --- Product: Koha Version: master 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[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 23997] New: sample_z3950_servers.sql is failing on MySQL 8
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '23

31 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23997 Bug ID: 23997 Summary: sample_z3950_servers.sql is failing on MySQL 8 Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 23996 koha_1 | DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'rank, syntax, encoding,recordtype) VALUES koha_1 | ('lx2.loc.gov',210,'LCDB','','','LIBRA' at line 2 at /usr/share/perl5/DBIx/RunSQL.pm line 273. https://dev.mysql.com/doc/refman/8.0/en/keywords.html => RANK (R); added in 8.0.2 (reserved) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23996 [Bug 23996] MySQL 8 support -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 32451] New: Acquisition imports are losing date accessioned
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '23

30 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32451 Bug ID: 32451 Summary: Acquisition imports are losing date accessioned Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Replacing items causes date accessioned to disappear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32456] New: Date accessioned is now cleared when items are replaced
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '23

30 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32456 Bug ID: 32456 Summary: Date accessioned is now cleared when items are replaced Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 29958 changed item edits so that a blank date accessioned would not auto populate. This broke workflows for libraries who have vendors processing their item records. When a library imports the final records, the date accessioned is not included, as the vendor doesn't know the date, and existing date is now blanked. I believe we should preserve the date accessioned unless the file includes a new one. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24