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

[Bug 23998] New: Messages REST API
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23998 Bug ID: 23998 Summary: Messages REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi Expose messages table via REST API. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 18583] New: Add the ability to merge multiple authorities
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18583 Bug ID: 18583 Summary: Add the ability to merge multiple authorities 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Since bug 8064 it is possible to merge multiple bibliographic records at once, it would be nice to be able to do the same thing with authority records. -- You are receiving this mail because: You are watching all bug changes.

1 26

[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 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '26

09 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 20

[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 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 23861] New: Add authorised value categories description option
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '26

08 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23861 Bug ID: 23861 Summary: Add authorised value categories description option 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I really like the way the authorised values page looks now. I think it's much more user friendly with the descriptions and the categories all laid out and not in a drop-down. Right now, the descriptions for each category are "hardcoded" in the template. Would it be feasible to move those in the DB? That way, when we add new categories, we would be able to add our own description. For example, if I add a category for RDA media type, I would be able to add a description saying it's meant to be used with 337$a. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 20638] New: Log actions on API keys
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20638 Bug ID: 20638 Summary: Log actions on API keys 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 Actions on API keys shoudl be logged and auditable (i.e. who creates the API keys, who revokes, etc). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 98

[Bug 17787] New: Suppressed items seems so still be included in number of search results
by bugzilla-daemon＠bugs.koha-community.org 07 Oct '26

07 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17787 Bug ID: 17787 Summary: Suppressed items seems so still be included in number of search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org We have a use case where like 99% of the collection is hidden and only a few selected items are displayed in the opac (by showing their covers up front on the main page). When going to the detail page and clicking the link for an author that has a long list of records (but only one visible in the opac) I might get indication of 63 hits in the search results and a the links to pages 1,2,3 etc for search results. Only problem is that there is actually only one result since the rest are suppressed. My guess is that the code calculating the number of hits and creating links to the pages of search results is not talking to the suppression system. I could not find any open bugs about this. Perhaps because our use of suppression is a bit of a edge case(?) I ended up "solving" the problem by removing the links on author etc. since we don't use search anyhow. I'll likely not research the issue further, but I felt I should at least report it and keep an eye out. All input is welcome. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 23562] New: Only one authorities search in header
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23562 Bug ID: 23562 Summary: Only one authorities search in header Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In authorities module, header contains 4 authorities search, from "main heading $a" to "entire record". This is more a search option than really different searches. I propose to merge them into only one with a select for where to search. This allow to always keep current search options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15