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

[Bug 28297] New: can't save system preference and field not marked as modified when changing value
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '26

18 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28297 Bug ID: 28297 Summary: can't save system preference and field not marked as modified when changing value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration 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 == Test plan == 1. Search any syspref that has a text input 2. input a value, like 3, you see "modified" 3. save 4. refresh (tech note: the <input> will now have value=3) 5. input 5, you see "modified" 6. save (tech note: the <input> still has value=3, this is the cause) 7. input 3, you don't see "modified" (this in wrong) 8. save 9 "nothing to save", this is wrong -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 17728] New: Move C4::Reserves code to the Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17728 Bug ID: 17728 Summary: Move C4::Reserves code to the Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 15449 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15449 [Bug 15449] Move stuffs to the Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 19871] New: Use new exceptions Koha::Exceptions::Object:: DuplicateID and FKConstraint
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19871 Bug ID: 19871 Summary: Use new exceptions Koha::Exceptions::Object::DuplicateID and FKConstraint Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are some reference of DBIx::Class:Exception in our code, they should be updated to use new Koha::Exceptions from bug 19828. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 112

[Bug 20644] New: Per itemtype setting for CheckPrevCheckout
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20644 Bug ID: 20644 Summary: Per itemtype setting for CheckPrevCheckout 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: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 6906 introduced the new CheckPrevCheckout syspref. The description says: "New feature: provide granular means to configure warnings about items that have been issued to a particular borrower before, according to their checkout history." I assume "items" here is shorthand for "items connected to the same bibliographic record"? Just checking on the item level would not be all that useful, if there are more than one copy of e.g. a book. On the other hand, this does not work so well for periodicals/journals where individual issues are entered as separate items. If a patron borrows the last three issues of a journal, the second one will give a warning that the patron has previously borrowed this "title". Could it be possible to have a setting on the itemtypes to choose one of these two? - Check if a patron has previously borrowed individual items (suitable for periodicals/journals) - Check if a patron has previously borrowed any items connected to a bib record (suitable for books, DVDs etc) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 125

[Bug 20125] New: Add a cron script to claim late orders
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20125 Bug ID: 20125 Summary: Add a cron script to claim late orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org We need a script that automatically send order claims by mail to the booksellers. The script should take 3 important paramters: delay: Number of days from which an orders is considered as late claimed-for: Minimum number of days since the last claim max-claim: Maximum number of claims -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 43

[Bug 30614] New: check-url-quick gives false error 404
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30614 Bug ID: 30614 Summary: check-url-quick gives false error 404 Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Many 404 errors come out after running the check-quick-url script while the urls are correct when checked manually. Apparently this is because the script uses HTTP HEAD instead of HTTP GET. HTTP HEAD returns only the headers of the urls and the header can return an error but the url is accessible when you do a GET. Is there a reason for this? My fellow analyst was pointing to line 104 of https://github.com/Koha-Community/Koha/blob/master/misc/cronjobs/check-url-… Thank you Marjorie -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 28486] New: MARCItemFieldsToOrder values lost when using Add Order button
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28486 Bug ID: 28486 Summary: MARCItemFieldsToOrder values lost when using Add Order button Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When populating a basket via a staged MARC file and checking for duplicates, if a duplicate is found then one is expected to use the "Add Order" button on that title to manage that title individually and decide whether to use the existing bib or create a new one. Either choice pushes one to neworderempty.pl (rather than addorderiso2709.pl). Values from MARCItemFieldsToOrder are not applied on neworderempty.pl, which complicates the workflow and requires the user to manually enter those values. To recreate: 1 - export a bib from your collection 2 - edit that bib to add some item values formatted in accordance with your MARCItemFieldsToOrder syspref 3 - create a basket in Acq set to create items at ordering 4 - add to your basket from a new file, select your exported and edited bib 5 - on addorderiso2709.pl, confirm your MARCItemFieldsToOrder values show up 6 - click Add Order 7 - select wither Use Existing Record or Create New Record 8 - confirm that you end up on neworderempty.pl without your MARCItemFieldsToOrder values -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 30529] New: Allow all item fields to be set in MARCItemFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30529 Bug ID: 30529 Summary: Allow all item fields to be set in MARCItemFieldsToOrder Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The MARCItemFieldsToOrder syspref allows values for a set list of item/order fields to be sent in MARC file used in acquisitions. We should broaden that out to include any item field to support a broader array of workflows. Bug 24334 already suggested adding barcode, but I see no reason not to take that idea further. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20253] New: Optionally use buyer's purchase order number from Edifact quote in basketname
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20253 Bug ID: 20253 Summary: Optionally use buyer's purchase order number from Edifact quote in basketname Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Current default behaviour is to use the filename of the QUOTE in the basketname. This would instead use the buyer's purchase order number (segment RFF with a qualifier ON) instead so that this would be searchable. This should be optional as even when supplied many (most) sites do not have meaningful or distinctive data in the field (e.g. 'Books for branch X'). Logical is to add it as a vendor option -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 117

[Bug 26261] New: Split calendar.inc into include file and JavaScript file
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '26

16 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26261 Bug ID: 26261 Summary: Split calendar.inc into include file and JavaScript file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 21156 Now that we have JavaScript internationalization there's no need to have strings defined in an include file like calendar.inc. I propose that we trim calendar.inc down to only those things which require template processing and move the rest of the JavaScript into its own JS file. This would allow us to do proper linting and allow browsers to cache the file. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 15