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

[Bug 33378] New: OPAC advanced search limits and OPAC facets no longer correspond
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '23

06 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33378 Bug ID: 33378 Summary: OPAC advanced search limits and OPAC facets no longer correspond Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you choose an advanced search limit in the OPAC of the item type "Books", that facet won't be selected in the OPAC search results. This appears to be due to a small change in what search qualifiers are used... -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 32728] New: ERM - Search header should change to match the section you are in
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '23

05 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32728 Bug ID: 32728 Summary: ERM - Search header should change to match the section you are in Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: david(a)davidnind.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com The ERM module search header has three options: Search agreements, Search packages, and Search titles. If you click through the sidebar options (Agreements, Packages, and Titles) the search header doesn't change to reflect the area you are in. If you change the header to another option, for example 'Search titles', then perform a search, the header goes back to 'Agreement search'. To replicate: 1. Enable the ERM module: ERMModule system preference. 2. Go to the ERM module: Home > E-resource management. 3. Select the options from the sidebar menu (Agreements, Packages and Titles), and note that the ERM search header options don't change. 4. Add a minimal agreement, package and title. 5. Change the search header to another option, for example 'Search titles', then perform a search. Note that: - the appropriate sidebar menu option is highlighted, for example: 'Titles' - the search header changes back to 'Agreement search' This was noted as a potential issue when testing bug 32683 - Convert header search tabs to Bootstrap. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 28609] New: Popularity sort is broken
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '23

05 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28609 Bug ID: 28609 Summary: Popularity sort is broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de Bug 13976 reported that the sort by popularity was only alphabetic and not numeric. I cannot confirm that... because now it's broken. When sorting by popularity the result list is sorted by biblionumber instead, which is the usual fallback when values are identical. When searching issues:74 or popluarity:74 records where the items have this number of issues are found correctly. So it appears the index is there and filled, but somehow not working when used for sorting? Verified in 18.11 and 20.11. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 33125] New: 2nd sorting level of titles in results lists should be configurable
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '23

05 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33125 Bug ID: 33125 Summary: 2nd sorting level of titles in results lists should be configurable Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: anke.bruns(a)gwdg.de QA Contact: testopia(a)bugs.koha-community.org The sort order in the OPAC is year (008) and then biblionumber (ASC). This means that in a result list with more than one title matching the first sort criterion, the earlier entries usually appear before the more recent ones. (Exceptions are possible, of course, if a title from an earlier publication year is catalogued after titles published later). The criteria for the first sorting level are configurable in the system preferences OPACdefaultSortField and OPACdefaultSortOrder. Currently there seems to be no way to configure the 2nd sorting level. Not sure whether this is a Zebra only issue. Suggestion: Add system parameter to configure the second sorting level, similar to those for the 1st level mentioned above. Alternatively: sorting by biblionumber on the 2nd level should be descending instead of ascending so newer (more recently catalogued) titles appear before older ones. Steps to Reproduce: Prerequisites: - A Koha OPAC (perhaps Zebra is required?) - First sort criterion must be functional, so if it is the publication year, the year must be present in positions 7-10 in the 008 field of the records. To reproduce: - Search for something with more than one result matching the first sort criterion, e.g. search for all titles published in a specific year. Actual Result: - In the results list the titles from the same year appear in ascending order of their biblionumbers. Expected Results: - Either: the titles appear in descending order of biblionumber - Or: the second sorting level (criterion and asc/desc order) is configurable in additional system parameters similar to OPACdefaultSortField and OPACdefaultSortOrder. -- You are receiving this mail because: You are watching all bug changes.

1 4

[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 33359] New: After the latest update koha is not calculating the fine. Previously it was calculating.
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '23

04 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33359 Bug ID: 33359 Summary: After the latest update koha is not calculating the fine. Previously it was calculating. Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: wbeimar23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 148928 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148928&action=e… error fines since the update of koha in the last version, no charge of fines is being presented in the borrowed books. when executing the fine.pl command it has the following error Can't use string ("Skipping execution of /usr/share"...) as a HASH ref while "strict refs" in use at /usr/share/koha/lib/C4/Log.pm line 135. library: 13 status returned by "/usr/share/koha/bin/cronjobs/fines.pl" tar: var/lib/koha/library/biblios/register/recdB-0.mf: file changed as we read it tar: var/lib/koha/library/biblios/register/isambD-0.mf: file changed as we read it I am using elasticsearch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33366] New: shelfbrowser doesn't publis local cover images
by bugzilla-daemon＠bugs.koha-community.org 04 Apr '23

04 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33366 Bug ID: 33366 Summary: shelfbrowser doesn't publis local cover images Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org We have realized that at least in koha 22.11 when configure shelfbrowser is turned on, local covers are not shown in shelfbrowse Googlejackets or amazon jacksts are publishing propertly -- You are receiving this mail because: You are watching all bug changes.

1 1

[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