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

[Bug 35465] New: Ability to select multiple funds for a single order
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '24

15 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35465 Bug ID: 35465 Summary: Ability to select multiple funds for a single order Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: cguenther(a)coloradocollege.edu QA Contact: testopia(a)bugs.koha-community.org Allow multiple funds to be selected for tracking payment on a single order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 36319] New: Splitting a single item between multiple funds
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '24

15 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36319 Bug ID: 36319 Summary: Splitting a single item between multiple funds Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: liberm(a)uhv.edu QA Contact: testopia(a)bugs.koha-community.org Periodically we run into instances where we need to split the cost of a book or database between two funds. Currently this is not possible in Koha and so we add and subtract money from funds to get the money to match, but it doesn't allow us to track the actuality of how the money was spent for reporting purposes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25375] New: Elasticsearch: Limit on available items does not work
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '24

15 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25375 Bug ID: 25375 Summary: Elasticsearch: Limit on available items does not work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com Currently what this limit does is a filter on onloan:false This means that: - Any biblio with at least one checked out item will be hidden from the results, even if it has other available items - A biblio whose items are all lost, damaged, withdrawn or "notforloan" will not be hidden, but the results will show "X items, none available" -- You are receiving this mail because: You are watching all bug changes.

1 70

[Bug 27937] New: Date of birth entered without correct format causes internal server error
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '24

12 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27937 Bug ID: 27937 Summary: Date of birth entered without correct format causes internal server error Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com In 20.05 when a birthdate is entered in patron registration form (memberentry.pl) incorrectly, and save button is clicked, you receive an Internal Server Error and all the data is lost. To recreate: 1. Add new patron 2. Enter birthdate as 2/11/1986 3. Complete required fields 4. Save 5. Get ISE Yes, the text below the birthdate does specify MM/DD/YYYY but an incorrect entry should not cause all the data entered to be lost. Perhaps a warning instead that the birthdate format is incorrect? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 35050] New: Self checkout and checkin interfaces don't use correct library for additional contents
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '24

11 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35050 Bug ID: 35050 Summary: Self checkout and checkin interfaces don't use correct library for additional contents Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org When using HTML customizations in the self checkout and self checkin interfaces, the content should respect both the language and the library. If the user is not logged in, content should be displayed according to $ENV{OPAC_BRANCH_DEFAULT}. If the user is logged in, content should be displayed according to their home library. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31330] New: Branchcode used for routing preview can be wrong
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '24

11 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31330 Bug ID: 31330 Summary: Branchcode used for routing preview can be wrong Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Noticed when working on bug 31318, and discussed on IRC http://irc.koha-community.org/koha/2022-08-09#i_2443598 It seems that we adding/modifying the hold using the holdingbranch of the serial item published first. If no item is created (or no holdingbranch), we are using the subscription.branchcode Shouldn't we use the branchcode of the issue we previously created (if an item exist) instead of the first published one? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 34985] New: Add a quantity field to the manual invoice form
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '24

10 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34985 Bug ID: 34985 Summary: Add a quantity field to the manual invoice form 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This plugin add a “quantity” field to the manual invoicing form this will allow to automatically multiply the amount when it has a default amount -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 26027] New: Add ability to let librarians know why higher priority holds were skipped
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '24

10 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26027 Bug ID: 26027 Summary: Add ability to let librarians know why higher priority holds were skipped 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are circumstances where higher priority holds are not trapped for a given item. These reasons range from requiring specific item or itemtype, to a hold being suspending, to a hold being given local holds priority. I think the best way to accomplish this would be to capture a list of the skipped holds and the reason for skipping them, then pass that to the template for display on the checkin screen when an item is trapped to fill a hold. This feedback would be especially useful if *none* of the holds were trapped for the given item. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 33398] New: Allow hold notification_method to be based on either messaging preferences or primary_contact_method
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '24

10 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33398 Bug ID: 33398 Summary: Allow hold notification_method to be based on either messaging preferences or primary_contact_method 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a waiting hold is triggered a popup appears that includes "Patron notification:". This is based on the patron messaging preferences for 'Hold filled'. We should allow libraries to choose between having this based on messaging preferences or primary_contact_method. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 33496] New: Add 'host_items' param to Koha::Biblio->items
by bugzilla-daemon＠bugs.koha-community.org 10 Oct '24

10 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33496 Bug ID: 33496 Summary: Add 'host_items' param to Koha::Biblio->items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org This patch will add an option to the $biblio->items method to allow retrieving the items and analytic items for a record. This is intended to allow fetching a single Items object, and related object, rather than having to fetch the items, and the host items, and push them together -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28