November 2021 - Koha-bugs - lists.koha-community.org

[Bug 18148] New: Chronological order for public lists in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18148 Bug ID: 18148 Summary: Chronological order for public lists in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Some librarians ask us to have public lists in chronological order rather than in alphabetical order because some schools will have to kept them there for a long time. This results in a big list with many pages on which is more difficult to find the good list. 1) Go in an OPAC interface 2) Go to "Lists" normally in top left corner 3) A small list appears from the top of the screen, observe that this list is by modification date (not alphabetical order) 4) Clic then on public lists 5) Observe that all lists created are in alphabetical order and their order cannot be changed We are wondering if it's possible to have some sorting options for the results list like in the staff client interface. There, you can change for chronological (modification or creation date) but also by owner order. Thanks for helping us, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 60

[Bug 22212] New: Improve usability of column configuration page
by bugzilla-daemon＠bugs.koha-community.org 09 Sep '26

09 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22212 Bug ID: 22212 Summary: Improve usability of column configuration page 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- The column configuration page currently doesn't translate well. The modules on the tabs translate, but neither do the id= parts or the columns. I think as a first step it would help to navigate these pages if we could add a little description on where the table appears somewhere that is translatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

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

09 Sep '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 40

[Bug 21860] New: Marc modification templates cannot check or change indicators
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21860 Bug ID: 21860 Summary: Marc modification templates cannot check or change indicators Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org The marc modification templates have no way of checking or changing indicator values. This seems like a pretty big oversight. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 132

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

08 Sep '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 27

[Bug 22707] New: Allow manual definition of AutoMemberNum range
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22707 Bug ID: 22707 Summary: Allow manual definition of AutoMemberNum range 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- It'd be great to have a way to tell Koha where to start when assigning card numbers via AutoMemberNum and to see what the next number will be. Bug 19263 introduced a feature that uses an authorized value to set up ranges of auto-incremented control numbers in bib records. Could something similar be used for card numbers? Ideally, this could also allow the definition of separate card number ranges for different branches. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 73

[Bug 24194] New: Add system preference to hide expiration date options for reserves
by bugzilla-daemon＠bugs.koha-community.org 08 Sep '26

08 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24194 Bug ID: 24194 Summary: Add system preference to hide expiration date options for reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries do not need to set expiration dates for reserves (this functionality is used). Add the ability to hide these options when placing reserves in staff client and OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 161

[Bug 22322] New: Self-checkin module should provide for automatic logins (like self-checkout)
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22322 Bug ID: 22322 Summary: Self-checkin module should provide for automatic logins (like self-checkout) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.behnke(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- The self-checkin (SCI) module currently requires to set up a dedicated kiosk terminal for its purpose. The reason being that you can't provide user/password system preferences for an automatic login, like you can for the self-checkout (SCO) counterpart. Our use case is the following: we are already using the SCO module with automatic login of the dedicated SCO patron, and our actual patrons identify themselves via their cardnumber. While they can obviously check in their books via the SCO module, we'd like to streamline the process such that they don't have to login with their cardnumber in order to simply return a book. The SCI module would be ideal for this but, effectively, it can't be used on the same terminal as switching between the modules currently requires a manual login of the dedicated SCI patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 59

[Bug 16631] New: Show groups/categories of reports to authorized staff
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '26

07 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16631 Bug ID: 16631 Summary: Show groups/categories of reports to authorized staff Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have reports that are specific groups/categories to be authorized under the reports permissions in a patron account. Not everyone wants to see everyone else's reports, some are similar but are not. Some are for superlibrarians to test, and are not ready for use. It would be great if we could specify groups and even subgroups in the permissions that the staff could access, or specify all groups. All groups should be the norm for a superlibrarian. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 290