June 2024 - Koha-bugs - lists.koha-community.org

[Bug 36540] New: Consider modernising the checkout page to be an Vue page
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36540 Bug ID: 36540 Summary: Consider modernising the checkout page to be an Vue page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The checkouts page is a core function of Koha, The controller has grown very complicated and it can suffer from performance challenges that we keep trying to side step wit preferences work arounds. We should consider working to replace the page with a Vue app and use the modern API's that have been developed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 28989] New: Allow viewing systempreferences only
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28989 Bug ID: 28989 Summary: Allow viewing systempreferences only Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com See bug 28882. It might be helpful if we could distinguish between viewing sysprefs and changing them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 22439] New: Duplicated code in PrepHostMarcField and prepare_host_field
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22439 Bug ID: 22439 Summary: Duplicated code in PrepHostMarcField and prepare_host_field 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: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The C4/Biblio.pm subroutines PrepHostMarcField and prepare_host_field both do the same thing, so should be merged. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 35711] New: Compatibility levels before 10 are deprecated
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35711 Bug ID: 35711 Summary: Compatibility levels before 10 are deprecated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Seeing this when trying to build custom packages: dh clean --fail-missing --with bash-completion dh: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_auto_clean -O--fail-missing dh_auto_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) dh_clean -O--fail-missing dh_clean: warning: Compatibility levels before 10 are deprecated (level 9 in use) No idea what it means, but see bug 18908 for a similar fix. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36007] New: Add the ability to batch edit in Course Reserves
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36007 Bug ID: 36007 Summary: Add the ability to batch edit in Course Reserves Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be nice to have the ability to batch edit in course reserves. A scenario could be, a course is reactivated, the items in the course are the same, but they all need to be relocated for the course is happening at a different branch, or a different reserve location. A batch edit would allow staff to retain the list of items in the course, but easily update the new course reserves values. At this time, each item would need to be individually edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 21453] New: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21453 Bug ID: 21453 Summary: blinddetail-biblio-search.pl/.tt use hardcoded subfield values for MARC21 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: arouss1980(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org If you add or alter an authority record and edit one of the MARC fields in UNIMARC 5XX 'See Also Reference Tracing Block' [1], you can click on the ellipsis (...) next to a subfield [2] to launch the authority finder plugin. This plugin allows you to search for an authority and then pick an entry from the 'Special relationship:' dropdown menu in order to set the relationship between the two authorities. The results list of the authority finder contains 'Choose' buttons which _should_ insert all data from the chosen authority into the appropriate subfields of the MARC tag you are editing [3]. However, in UNIMARC setups this does not work: clicking on 'Choose' only populates subfield $a ('Entry Element') with data, but not subfields $3 and $5 ('Authority Record Number' and 'Tracing Control', respectively), which are just as important for correct authority linking. I've tracked this down to these lines of code which are MARC21-specific and use hardcoded subfield values in blinddetail-biblio-search.pl: 91 for ( $field->subfields ) { 92 next if $_->[0] eq '9'; # $9 will be set with authid value 101 push( @subfield_loop, { marc_subfield => 'w', marc_values => $relationship } ) if ( $relationship ); There is also this code in the template blinddetail-biblio-search.tt: 38 [%- END -%]‡9[% authid | html %]"; 138 if(code.value=='9'){ 139 subfield.value = "[% authid |replace("'", "\'") |replace('"', '\"') |replace('\n', '\\n') |replace('\r', '\\r') %]"; These code fragments don't work 100% because in UNIMARC authorities the authid value is stored in subfield $3 and the relationship code in $5. I propose to modify the Perl script above (which is currently MARC flavour agnostic), have it check the 'marcflavour' system preference, and use that to decide which subfield to push the authority relator code to. A similar approach in the template file will set the authid subfield value depending on whether you are a MARC21 or UNIMARC user. [1] Known as the 'Related Access Point Block' in recent IFLA updates. [2] For the ellipsis to appear next to a subfield, you must view the MARC structure of the relevant authority type and then edit the subfields of the tag you're interested in. Finally, you must select an authority type from the 'Thesaurus:' dropdown menu. [3] Under the hood each 'Choose' button is a call to the JS function doauth(), which in turn calls blinddetail-biblio-search.pl with the parameters required (authid, relationship, etc.). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 31506] New: Add "backup days" to /etc/koha/koha-common.conf
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31506 Bug ID: 31506 Summary: Add "backup days" to /etc/koha/koha-common.conf Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com koha-run-backups takes the --days argument to say how many days of backup we should keep around. The value of this is set to two in the default /etc/cron.daily/koha-common that is installed by the Debian packages. I routinely increase this value to keep more backup. One thing that can happen now is that I want to create fresh backups for all the sites on a server before doing an upgrade. So I run koha-run-backups manually, but I forget about the --days argument. Result: I loose a lot of backup! It would be nice if the default for --days could be set somewhere like /etc/koha/koha-common.conf. That way we could run koha-run-backups both from cron and manually, without the --days argument, and keep the same amount of backups either way. If --days is given as an argument, it should override the default. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 27138] New: Host items are not included in Z39 results when using EasyAnalytics
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27138 Bug ID: 27138 Summary: Host items are not included in Z39 results when using EasyAnalytics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a library enables EasyAnalytics and links two records in the catalog then the host items show on the child record. If you search for these records via Z3950 (via zebra directly or the responder) the host items are not shown -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 21309] New: Add flag to change password
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21309 Bug ID: 21309 Summary: Add flag to change password Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We should add a flag to patron accounts that, if checked, would require the patron to sign in to their account and change their password. This option could incorporate the following functionality: * Allow patron to sign in with old password then prompt for a new password. * E-mail patron notifying them with the need to change. * When active, it would block checkouts and sip authentication until done. * Anytime a password is changed in the account, whether staff side or opac, the change would clear the flag in the patron account. * Date of change should be time stamped. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47