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

[Bug 38893] New: Longoverdue cronjob gives error when run with "--library" flag and CircControl syspref set to "The library you are logged in at"
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38893 Bug ID: 38893 Summary: Longoverdue cronjob gives error when run with "--library" flag and CircControl syspref set to "The library you are logged in at" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 9596 Bug 9596 added the ability to limit longoverdue by library. The determination of which library to use for a given checkout is made based on the CircControl system preference. One of the options for CircControl is "The library you're logged in at." If CircControl is set to "the library you're logged in at" and you run the longoverdue cron with the --library flag set, you get the error "Use of uninitialized value $lib in hash element at misc/cronjobs/longoverdue.pl line 484." because Koha doesn't know how to pick a branch -- no one is logged in. Setting this to normal as it seems like mostly a "don't configure it like this" issue. But maybe we should give the cron something to follow if the syspref is logged-in-branch? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9596 [Bug 9596] Allow longoverdue.pl to be configured per library on the command line -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 37992] New: Patron search results: table header with column filters isn't sticky anymore
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37992 Bug ID: 37992 Summary: Patron search results: table header with column filters isn't sticky anymore Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Run empty patron search 2. Assuming there are enough results, when scrolling down the #searchheader with "select all" button would get hidden. But no, it's sticky so it follows you and stays visible. This is expected. 3. The table header (thead) with filters for each column is not sticky. This is a regression. (It was sticky in 23.11, but not anymore in 24.05 and main) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 38601] New: Framework default value for control fields not being passed to editor
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38601 Bug ID: 38601 Summary: Framework default value for control fields not being passed to editor Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate in 24.05 1. Use the basic editor to define the leader using the tag editor. 2. Copy the data in the field. 3. Edit the Default framework and paste the data into the 000 tag, default value field, save. 4. Go to the cataloging module and New Record, default framework. See that the 000 Leader field is blank. In 23.05 and 23.11, the field would contain the default value as assigned in the framework. Possibly due to CSRF changes for 24.05? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 20112] New: Optionally show invalid ISBN/ISSN 020/022 $z
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20112 Bug ID: 20112 Summary: Optionally show invalid ISBN/ISSN 020/022 $z 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently the invalid ISBN and ISSN are indexed (bug 14617), but aren't displayed. It would be nice to find a way to display them if the library wants to do so. Having a class or similar for hiding them if necessary would be enough. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28218] New: Additional fields for vendors
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28218 Bug ID: 28218 Summary: Additional fields for vendors 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 It's possible to add additional fields to baskets and subscriptions, but it would be great if this could be extended to other areas as well. One of those would be vendor records. For example at the moment it's not possible to store banking/account information in our vendor records. We could add the fields or we could add a configuration option to make this easy to add. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23764] New: Add printable version of "Change password" in patron details
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23764 Bug ID: 23764 Summary: Add printable version of "Change password" in patron details 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: kugler_stefan(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The button "Change password" in patron details allows to set a new password for OPAC users. Please add an option for a printer friendly version of this page so a librarian can hand out a nice document with header/notice/footer and new credentials. Proposal: Use CSS media queries to hide Koha intranet header and menue and add a header/footer only visible for the printable version. Also hide notice "Koha cannot display existing passwords...", input box for password confirmation and save/cancel buttons. Show current date and time to be sure which one was the last printed page if you print out multiple version. Add notice to make sure to save the new password. --------------------------- My Library Address today's date Dear firstname lastname, welcome... Your credentials are: Username: 012345 Password: generatedpassword123 Visit https://opac.url to log in. Sincerly, your library Printed on date/time. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31642] New: Additional contents: Allow free text in location field for html blocks
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '25

10 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31642 Bug ID: 31642 Summary: Additional contents: Allow free text in location field for html blocks 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org I ran into this limitation on e.g. bug 31503. I want to add locations that match authorised values for category CONSENT_TYPE. But Koha only allows a selected set of locations for html blocks. If we could allow picking a field from the combo or typing free text, we provide more flexibility in the use of this feature. Obviously this triggers a development discussion on field names. We have category, location and code. And their use becomes a bit unclear. Category is the most clear one. Although html and pages are quite similar. Location is opac or staff etc. for news and pages. But is used as a kind of block name for html_customizations. Code is used to group the records for default and translated languages for an item in all categories. The name is rather obscure. While describing this, bug 31383 comes to mind again.. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 29872] New: Article requests: Include information on host record in article requests table
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29872 Bug ID: 29872 Summary: Article requests: Include information on host record in article requests table 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If an article request is placed on an analytical record, it would be very helpful to display the information about the host record in the table of article requests. A first step would be to display the information from 773 and maybe create a search link for the record using the title or number from $w. If we can look-up the host record on server side, we could also provide a link with the biblionumber could also be provided. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22265] New: Processing article requests requires borrowers permission
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22265 Bug ID: 22265 Summary: Processing article requests requires borrowers permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com Target Milestone: --- I just noticed that you will only be able to see article requests if the staff patron has "borrowers" permission. You can still access the article requests page without the permission, but it will always show "no pending article requests". This dependency doesn't seem logical, especially since you can still access the page and it just seems like there are no requests. The problem seems to come from this part of the code: Koha::ArticleRequests: sub search_limited { my ( $self, $params, $attributes ) = @_; my $userenv = C4::Context->userenv; my @restricted_branchcodes; if ( $userenv and $userenv->{number} ) { my $logged_in_user = Koha::Patrons->find( $userenv->{number} ); @restricted_branchcodes = $logged_in_user->libraries_where_can_see_patrons; } # TODO This 'borrowernumber' relation name is confusing and needs to be renamed $params->{'borrowernumber.branchcode'} = { -in => \@restricted_branchcodes } if @restricted_branchcodes; $attributes->{join} = 'borrowernumber'; return $self->search( $params, $attributes ); } Not sure yet what the best way would be: Do we want to allow article request processing without borrowers? If no, we could hide article requests from view if the staff user doesn't have the required permission. If yes, what would be the consequence? (stuck on that one) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 28652] New: Enforce maximum on article request charges
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '25

09 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28652 Bug ID: 28652 Summary: Enforce maximum on article request charges 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Just like we enforce a maximum charge for fines, rentals etc. we should not allow article request charges to pile up unlimited. See also bug 27946. Compare: maxoutstanding, OPACFineNoRenewals, MaxFine, noissuescharge, RentalsInNoissuesCharge. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3