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

[Bug 42575] New: Spelling: OPAC is an abbreviation
by bugzilla-daemon＠bugs.koha-community.org 10 May '26

10 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42575 Bug ID: 42575 Summary: Spelling: OPAC is an abbreviation Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Found while translating: requests a particular language for the output, default is the opac cookie language if set, the first language in opac language list or english koha-tmpl/opac-tmpl/bootstrap/en/modules/ilsdi.tt:128 opac should be: OPAC english should also be: English Shown for 22.11, needs confirmation in newer versions. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42574] New: Ability to define multiple descriptions for a location, depending on the library
by bugzilla-daemon＠bugs.koha-community.org 10 May '26

10 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42574 Bug ID: 42574 Summary: Ability to define multiple descriptions for a location, depending on the library Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It could be nice to have the ability to define multiple descriptions for a location, depending on the library For example a location code "FICTION" could have a description "Fiction" in a library, and "First floor - Fiction" in an other. Currently we have to create 2 codes for handling this situation The mechanism could apply to OPAC and staff descriptions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 42572] New: Can't edit patron that has library specific required borrower attribute
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42572 Bug ID: 42572 Summary: Can't edit patron that has library specific required borrower attribute Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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(a)bywatersolutions.com When editing a patron that has a required borrower attribute that is set to a value that is only assignable by specific libraries and not your own, it blanks out the value and requires you to fill it in, and obviously with something different since your library can't use the value. Expected behavior would be to show that value set, and not blank it out, or balk about it if you are not changing that particular value. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27978] New: Marc modification templates should allow for copying an entire field to a field/subfield and vice versa
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27978 Bug ID: 27978 Summary: Marc modification templates should allow for copying an entire field to a field/subfield and vice versa 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently you are limited to copying from a field/subfield to another field/subfield This prevents operations like copying from a subfield into a control field and vice versa see bug 9921 for an example of a desired behavior biblionumber into control field -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 42556] New: Give Additional fields (additional-fields.pl) the option to make required
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42556 Bug ID: 42556 Summary: Give Additional fields (additional-fields.pl) the option to make required Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Additional fields needs to have an option to make the field required. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 32750] New: Additional fields: Allow fields to be marked as mandatory
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32750 Bug ID: 32750 Summary: Additional fields: Allow fields to be marked as mandatory 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, michaela.sieber(a)kit.edu It would be nice if additional fields could be marked as mandatory. This would add the "required" to the forms where the data is entered/edited, enforcing that data is entered before the record can be saved. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 30815] New: Use of uninitialized value $charge in numeric gt (>) at /usr/share/koha/lib/C4/Circulation.pm
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30815 Bug ID: 30815 Summary: Use of uninitialized value $charge in numeric gt (>) at /usr/share/koha/lib/C4/Circulation.pm Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Blocks: 25798 The code on 20.11.17 is: # Charge a new rental fee, if applicable my ( $charge, $type ) = GetIssuingCharges( $itemnumber, $borrowernumber ); if ( $charge > 0 ) { AddIssuingCharge($issue, $charge, 'RENT_RENEW'); } But it's the same on current master. The line given is the if-clause in line 3171. The default for rentalcharge and rentalcharge_daily in itemtypes is NULL, maybe that's the cause? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25798 [Bug 25798] Copyright year to Holds to pull report -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 42539] New: When patron category set to Enforce patron account expiry notice, notices are not sent to all patrons in that category
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42539 Bug ID: 42539 Summary: When patron category set to Enforce patron account expiry notice, notices are not sent to all patrons in that category Initiative type: --- Sponsorship --- status: 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 30301 To recreate: - have your category set to not enforce patron account expiry notice - find/create a patron in that category who has an email address but does not have their messaging prefs set to get an account expiry email - set your patron's expiration date such that they should get an expiry notice (based on the MembershipExpiryDaysNotice system preference) - edit your patron category messaging defaults to send an email for account expiry and to Enforce patron account expiry notice - run the membership_expiry cron - confirm your patron did not get a notice The wording on 'Enforce patron account expiry notice' is: 'Make the account expiry notice mandatory for all patrons in this category and prevent patrons from opting out in the messaging preferences' That wording suggests the notice will be sent to all patrons in the category regardless of their messaging preferences. What we're actually doing is just preventing changes to those messaging preferences. On Bug 40646 I suggested the messaging preference should continue to show while 'Enforce patron account expiry notice' is enabled but prevent changes by the users. Perhaps we should also trigger an update to all patrons in the category to update their account expiry messaging preferences when a category is edited to enable 'Enforce patron account expiry notice.' At the least, we should update the wording here to make it accurate. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30301 [Bug 30301] Add an option to specify the patron expiration notices as mandatory by patron category -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 35630] New: Add ability to log changes to Authorized Values
by bugzilla-daemon＠bugs.koha-community.org 09 May '26

09 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35630 Bug ID: 35630 Summary: Add ability to log changes to Authorized Values Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the increase in number of authorized values, and with the newer sys pref CreateAVFromCataloguing, it is becoming essential to be able to determine who/when/how changes are made to authorized values, and this not currently being logged. It would be a great help to be able to log these changes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 11808] When searching for a cardnumber in the intranet, also try to search for it on the LDAP server if one is configured and add/update user
by bugzilla-daemon＠bugs.koha-community.org 08 May '26

08 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11808 --- Comment #29 from Hammat wele <hammat.wele(a)inlibro.com> --- Created attachment 198907 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198907&action=e… Bug 11808: Add the SearchCardnumberWithLDAP system preference Add option to search patrons on ldap server when not found in local database and import it Test plan: 0. You need to have an ldap server containing patron informations configured in Koha. 1. Apply patch and update database. 2. Check that the new system preference SearchCardnumberWithLDAP has been added and set as 'never'. 3. Choose a patron who exists in your ldap server but not in Koha. (you can delete an existing patron from Koha if needed) 4. Search for the patron by it's cardnumber in the following locations. Do not choose from the dropdown list, use the submit button. - circ/circulation.pl - circ/article-request.pl - reserve/request.pl - members/member.pl both at the top and in the filter box - any page using common/patron_search.tt, for example adding a guarantor with the members/guarantor_search.pl popup => Should return cardnumber/patron not found or no results 5. Change SearchCardnumberWithLDAP to 'if not found locally'. 6. Repeat step 4. => The patron should be added to Koha. 7. Edit the patron and change any of the existing information. 8. Repeat step 4. => The patron has not been updated (the change made in step 7 is still there) 9. Change SearchCardnumberWithLDAP to 'always'. 10. Repeat step 4. => The patron has been updated. Change made in step 7 has been rewritten and patron informations is the same as in step 6. 11. Try searching for a patron who doesn't exist in Koha and has a nonexistant branch on the LDAP server. An error message should appear accompanying the absence of results. -- You are receiving this mail because: You are watching all bug changes.

1 0