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

[Bug 35211] New: Make it possible to add new tab to record’s detail page catalogue/detail.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '26

09 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35211 Bug ID: 35211 Summary: Make it possible to add new tab to record’s detail page catalogue/detail.pl Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: kati.sillgren(a)porvoo.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Make it possible to add new tab to record’s detail page/holdings table by using library groups. Library groups are made here: admin/library_groups.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 25284] New: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied)
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '26

09 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25284 Bug ID: 25284 Summary: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I have completely rebuilt my kohadevbox, but can't get rid of this error: Can't open /var/log/koha/kohadev/opac-error.log (Permission denied) at /usr/share/perl5/Log/Log4perl/Appender/File.pm line 143 First it appeared when I was trying to save system preferences. Now I ran into it, when trying to check out an item. I have no idea what's causing this and if this is a general or a kohadevbox issue. Help appreciated! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 18787] New: Create permission profils for staff user
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '26

09 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18787 Bug ID: 18787 Summary: Create permission profils for staff user Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would very useful if we could define different permission profils, depending on the library uses, to prefill permissions. For example, in our site, we could have : - a "catalog profil" to edit records and items - a "subscription profil" because there is a team which works specifically on periodical publications - a "circulation profil" because some of us don't work directly with patrons so they don't need to access to the Patron and Circulation module (but they could borrow books for themselves) - a "team manager profil" because they have permission to see acquisition budget for all their team - etc. It would be an easier way to define permissions for a new staff user and a way to be sure all the accounts are identically set. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 24180] New: maintain separate repeated subfields when linking authority in advanced catalog editor
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '26

09 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24180 Bug ID: 24180 Summary: maintain separate repeated subfields when linking authority in advanced catalog editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To test: - create an authority record with two 150$z fields - create a new bib in the advanced editor - link your bib to your authority - note your two $z subfields have been concatenated Tested this on master with specifically a topical term authority linking to a 650, though I don't suspect those details will make a difference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 35145] New: Add ability to order patron attributes
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35145 Bug ID: 35145 Summary: Add ability to order patron attributes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Right now, patron attributes are presented in code order. It would be nice to have a way to choose the order in which they are presented. I put this in OPAC because I noticed this in the self-registration form. But I guess it would be true for the staff interface too. My actual use case was for birth details of a baby. I had the birthdate, the number of weeks and the number of days of pregnancy, the weight of the baby, the surname of the baby, etc. I had specifically added them in the order I wanted because I thought the creation order would be the display order. But they were displayed in code order, and the order made no sense (file number, number of days of pregnancy, birth date of the baby, surname of the baby, weight at birth, number of weeks of pregnancy). I thought something like a "Display order" field like the ones we have in serial patterns and numbering and in the additional contents would be useful. To recreate: 1. Create several patron attributes with various codes 1.1. Go to Administration > Patron attribute types > New patron attribute type 1.2. Fill out the form - Code: enter any code, for example WEIGHT - Description: enter any description - Display in OPAC: check - Editable in OPAC: check 1.3. Click Save 1.4. Repeat to add a second code with a code alphabetically "before" the previous one, for example SURNAME 1.5. Optionnally, add more to really view the order 2. Enable self-registration 2.1. Go to Administration > System preferences 2.2. Search for selfreg 2.3. Set PatronSelfRegistration to Allow 2.4. Set a category in PatronSelfRegistrationDefaultCategory 2.5. Click Save all OPAC preferences 3. View self-registration form 3.1. Go to the OPAC 3.2. Click on Don't have an account? Register here. 3.3. Go to the bottom of the form --> Note that the patron attribute fields are presented in alphabetical order of the code. -- You are receiving this mail because: You are watching all bug changes.

1 146

[Bug 28833] New: Speed up holds queue builder via parallel processing
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28833 Bug ID: 28833 Summary: Speed up holds queue builder via parallel processing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The holds queue builder can take a very long time to run on systems with many holds. For example, a partner with 124,784 unfilled ( not found ) holds, is taking about 64 minutes to run. If we run that same number of holds in 5 parallel chunks ( splitting the number of records as evenly as possible, but *not* taking into account the holds per bib ), it takes 21.5 minutes. If we use 10 loops, it takes less then 14 minutes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 20053] New: Drop type attribute "text/javascript" used in OPAC template
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '26

06 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20053 Bug ID: 20053 Summary: Drop type attribute "text/javascript" used in OPAC template 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: indradg(a)l2c2.co.in QA Contact: testopia(a)bugs.koha-community.org If you run the Koha OPAC pages through the W3C validator it generates warnings about type attribute "text/javascript", since W3C now officially describes this as obsolete in HTML5 but still conforming to the standard with warnings [1] Since we are already pumping up HTML5 with <!DOCTYPE html>, I was thinking if we should consider an omnibus update to the following 47 templates so affected. The 47 templates: includes/calendar.inc includes/columns_settings.inc includes/datatables.inc includes/doc-head-close.inc includes/greybox.inc includes/opac-bottom.inc includes/password_check.inc includes/slip-print.inc modules/clubs/clubs-tab.tt modules/clubs/enroll.tt modules/opac-account.tt modules/opac-advsearch.tt modules/opac-auth-detail.tt modules/opac-auth-MARCdetail.tt modules/opac-auth.tt modules/opac-basket.tt modules/opac-course-details.tt modules/opac-course-reserves.tt modules/opac-detail.tt modules/opac-downloadshelf.tt modules/opac-full-serial-issues.tt modules/opac-idref.tt modules/opac-illrequests.tt modules/opac-imageviewer.tt modules/opac-MARCdetail.tt modules/opac-memberentry.tt modules/opac-messaging.tt modules/opac-overdrive-search.tt modules/opac-passwd.tt modules/opac-password-recovery.tt modules/opac-readingrecord.tt modules/opac-request-article.tt modules/opac-reserve.tt modules/opac-results-grouped.tt modules/opac-results.tt modules/opac-review.tt modules/opac-search-history.tt modules/opac-shareshelf.tt modules/opac-shelves.tt modules/opac-showreviews.tt modules/opac-suggestions.tt modules/opac-tags.tt modules/opac-topissues.tt modules/opac-user.tt modules/sco/help.tt modules/sco/printslip.tt modules/sco/sco-main.tt Reference: [1] https://www.w3.org/TR/2017/REC-html52-20171214/obsolete.html#warnings-for-o… -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 13580] New: item circ history has 'last seen' labeled wrong
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '26

05 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13580 Bug ID: 13580 Summary: item circ history has 'last seen' labeled wrong Change sponsored?: --- Product: Koha Version: master Hardware: All URL: cgi-bin/koha/circ/bookcount.pl?&biblionumber=106124&bi =106124&itm=140197 OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, sophie.meynieux(a)biblibre.com CC: katrin.fischer(a)bsz-bw.de CC: sophie.meynieux(a)biblibre.com On this page: cgi-bin/koha/circ/bookcount.pl?&biblionumber=106124&bi=106124&itm=140197 the 'last seen' column is actually the timestamp - not the date last seen so it's confusing. The label should be changed or the value should be changed. --- Comment #1 from Owen Leonard <oleonard(a)myacpl.org> --- *** Bug 13581 has been marked as a duplicate of this bug. *** --- Comment #2 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, it's not quite the timestamp either. It looks like a calculated date on when the item was 'last seen' in this library. It uses the newest date and time from issues, old_issues and branchtransfers. Maybe 'last seen at library'? --- Comment #3 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, it's not quite the timestamp either. It looks like a calculated date on when the item was 'last seen' in this library. It uses the newest date and time from issues, old_issues and branchtransfers. Maybe 'last seen at library'? --- Comment #4 from Sophie MEYNIEUX <sophie.meynieux(a)biblibre.com> --- The pb with this timestamp is that it is changed by anonymisation -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 33302] New: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33302 Bug ID: 33302 Summary: Placing item level holds in OPAC allows to pick forbidden pick-up locations, but then places no hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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(a)bywatersolutions.com, tomascohen(a)gmail.com A bit much to put in the description, but the problem is about item level holds failing to be placed silently in the OPAC. To test: With the sample data in ktd or sandboxes: 1) Enforce library transfer limits (UseBranchTransferLimits) on itemtypes (BranchTransferLimitsType). 2) In administration > branch transfer rules: disallow transfer from Midway to any other library for item type BK (Books) 3) Search for a record with at least one item in Midway in staff 4) Try to place an item level hold on a Midway item. I used: Intermediate Perl, biblionumber 126 For the Midway item, only Midway will show as possible pickup-location This is correct. 5) Switch to the OPAC 6) Try to place an item level hold there on the Midway item, for pick-up at Centerville. 7) Place a hold on the Midway item for pick-up at any non-Midway location 8) Verify the page saves without error, but the hold was not placed. - The basic issue here is that item specific pickup locations != record-specific pickup locations. In the staff interface we have a separate pull down "allowed pick-up locations" for each item in the list. I think we should implement the same in the OPAC to help the users see what is allowed and what not. And deacticate the pull down on top when an item is selected. But: At least we should give proper feedback that a hold could not be placed because of the pick-up location instead of failing silently! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35617] New: Make phone number as match point in in Identity providers
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35617 Bug ID: 35617 Summary: Make phone number as match point in in Identity providers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: slavashishkin(a)gmail.com Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 31378 Currently, the system supports match points by -email, -userid, and -cardnumber. Many external authorization systems have the authentication by phone number, which is also required for libraries. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31378 [Bug 31378] Add a generic OAuth2/OIDC client implementation -- You are receiving this mail because: You are watching all bug changes.

1 14