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

[Bug 37001] New: Locale ignored for serial numbering when using {MonthName} {DayName} substitutions
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37001 Bug ID: 37001 Summary: Locale ignored for serial numbering when using {MonthName} {DayName} substitutions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Moved from bug 35646 comment 17. Tt doesn't work because we don't set Locale for the DateTime objects we create in Koha::DateUtils: https://metacpan.org/pod/DateTime#Locales We could easily pass through the 'locale' from the Serial (subscription table) however, I spot tested and got an error for 'Ethiopic'/'gez' though it is listed here: https://metacpan.org/pod/DateTime::Locale::Catalog Our list comes from here: https://www.loc.gov/standards/iso639-2/php/code_list.php Maybe our datetime modules need an update? Here is a full list of ones that throw an error: Invalid locale code or name: akk Invalid locale code or name: tut Invalid locale code or name: grc Invalid locale code or name: ave Invalid locale code or name: bnt Invalid locale code or name: bra Invalid locale code or name: cel Invalid locale code or name: chp Invalid locale code or name: cho Invalid locale code or name: chu Invalid locale code or name: syc Invalid locale code or name: cop Invalid locale code or name: cre Invalid locale code or name: prs Invalid locale code or name: dgr Invalid locale code or name: egy Invalid locale code or name: gez Invalid locale code or name: gem Invalid locale code or name: got Invalid locale code or name: gwi Invalid locale code or name: her Invalid locale code or name: hit Invalid locale code or name: inc Invalid locale code or name: iku Invalid locale code or name: ipk Invalid locale code or name: ira Invalid locale code or name: jrb Invalid locale code or name: csb Invalid locale code or name: lad Invalid locale code or name: lat Invalid locale code or name: myn Invalid locale code or name: dum Invalid locale code or name: enm Invalid locale code or name: frm Invalid locale code or name: gmh Invalid locale code or name: mga Invalid locale code or name: mul Invalid locale code or name: nah Invalid locale code or name: zxx Invalid locale code or name: nya Invalid locale code or name: arc Invalid locale code or name: ang Invalid locale code or name: fro Invalid locale code or name: goh Invalid locale code or name: peo Invalid locale code or name: pro Invalid locale code or name: ota Invalid locale code or name: pal Invalid locale code or name: pli Invalid locale code or name: pbr Invalid locale code or name: pra Invalid locale code or name: roa Invalid locale code or name: rom Invalid locale code or name: sam Invalid locale code or name: sem Invalid locale code or name: den Invalid locale code or name: sla Invalid locale code or name: wen Invalid locale code or name: sux Invalid locale code or name: syr Invalid locale code or name: tgl Invalid locale code or name: tet Invalid locale code or name: uga Invalid locale code or name: mis -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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

[Bug 22762] New: Collection codes not displayed on receiving
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22762 Bug ID: 22762 Summary: Collection codes not displayed on receiving Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Acquisitions Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Caused by commit 31c29fd31f557306233e6a2936148a5bb10b89a1 Bug 21206: Replace C4::Items::GetItem The log says: The method Koha::Item->collection is not covered by tests! It has highlighted an older problem: Since commit bb1e9c500c810402c64436c53bcc00ffb9a0b857 Bug 17248 - Koha::AuthorisedValues - Remove GetKohaAuthorisedValueLib the "Collection code" is not filled correctly (items.collection vs items.ccode). -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 27834] New: CircControl syspref is used wrong in TooMany function C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '26

04 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27834 Bug ID: 27834 Summary: CircControl syspref is used wrong in TooMany function C4::Circulation 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The CircControl syspref description says > Use the checkout and fines rules of > PickupLibrary: the library you are logged in at. > PatronLibrary: the library the patron is from. > ItemHomeLibrary: the library the item is from. This is mostly true but there is one exception in the TooMany function where it actually doesn't just change which libraries rules are used but how the the calculation is performed. With PatronLibrary set the behaviour is as expected by reading the syspref description. However with the setting PickupLibrary the behaviour changes now, instead of just using the rules of the pickup library we also only take into account the loans in the pickup library when calculating whether we are over the checkout limit or not. The same happens with ItemHomeLibrary where we instead calculate the patron's checkouts in the home library of the item being checked out. We should really try to fix this either by a) showing that ItemHomeLibrary and PickupLibrary is unacceptable and no one actually wants that, that would allow then making the behaviour similar as what it is to PatronLibrary (so just selecting the right circ rule instead of changing calculation method). b) Provide a new syspref for changing the calcutation method when PickupLibrary or ItemHomeLibrary CircControl values are used, and set it on upgrade enabled as default. Ps. svc/letters/preview might use CirControl wrongly as well, I'm not 100% I didn't quite understand but as for other usages of CircControl syspref I grepped where it was used and it correctly only changed the circ rules to be used instead of changing behaviour. So in addition to TooMany we might have to do some changes to svc/letters/preview if it turns out it changes behaviour as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 22436] New: add move or copy control field from or to subfield in MARC modification templates
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22436 Bug ID: 22436 Summary: add move or copy control field from or to subfield in MARC modification templates 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- MARC modification templates does not allow to mix control field and the subfield of a regular field, we should allow that. But of course not the mix of an entire regular field and the subfield of a regular field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 31268] New: Clearly indicate reason for failed item creation when receiving expired subscription
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31268 Bug ID: 31268 Summary: Clearly indicate reason for failed item creation when receiving expired subscription Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Bug 29188 points out that while the manual says one cannot receive issues in an expired subscription, Koha is currently allowing one to do so. However, Koha *is* refusing to create an item when receiving an issue on an expired subscription. To recreate: 1 - create a subscription set to *not* create items, subscription end date in the past 2 - save subscription, confirm it shows as expired, confirm you can receive an issue anyway 3 - create a subscription set *to* create items, subscription end date in the past 4- save subscription, confirm it shows as expired, confirm you can get to the receiving page but setting the dropdown for the expected issue to "Arrived" does not cause an item edit box to appear 5- create a subscription set *to* create items, subscription end date in the future, number of issues set to 1 6- save subscription, receive 1 issue, confirm it works as intended 7- confirm subscription now shows a confusing "Subscription will expire on [subscription end date]" message even though the date isn't the problem 8- Attempt to receive another issue, confirm that now the item edit box won't pop up, as in step 4 In steps 4 and 8, the item edit box will appear if one attempts to receive a supplemental issue, but the item will refuse to save, giving an erroneous "missing required field" message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 31612] New: koha-z3950-responder breaks if it's run in a Koha that was created before bug 28364 was applied
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31612 Bug ID: 31612 Summary: koha-z3950-responder breaks if it's run in a Koha that was created before bug 28364 was applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The problem is the same as Bug 28364 but that it affects upgraded Koha instances rather than new Koha instances. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 27704] New: Group locations for advanced search
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27704 Bug ID: 27704 Summary: Group locations for advanced search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 116878 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=116878&action=e… Add a goup Locations option - Advanced search.png Like the option exists for itype with ITEMTYPECAT authorized value, it could be useful for users if we would group locations into several categories in OPAC advanced search and facets. For example, we have 29 different storage location only accessible to staff and 4 public locations in our catalog, which are quite confusing descriptions for opac users. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 24082] New: Add a 'refund' option to anonymous payments
by bugzilla-daemon＠bugs.koha-community.org 02 Feb '26

02 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24082 Bug ID: 24082 Summary: Add a 'refund' option to anonymous payments Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org With bug 23442 we add a process for recording refunds to patrons. We need to expand this for anonymous payments once bug 23354 is available. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 53