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

[Bug 28541] New: Incorrect default pickup location passed to HTML, causing UI show items unreservable
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28541 Bug ID: 28541 Summary: Incorrect default pickup location passed to HTML, causing UI show items unreservable 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, nugged(a)gmail.com, stalkernoid(a)gmail.com, tomascohen(a)gmail.com Depends on: 27071 The default pickup branch for holds through intranet was changed in Bug 27071 to be the branch returned by C4::Reserves::GetReservesControlBranch() function. However, the result of this calculation, $reserves_control_branch, is not passed to to the Template Toolkit template: > # pass the userenv branch if no pickup location selected > $template->param( pickup => $pickup || C4::Context->userenv->{branch} ); Instead the wrong value, currently logged in branch is passed. This causes the UI give false warning triangles about not being able to reserve some items even though the reservation works if you ignore those warnings. We should be passing the same branch as we did the availability calculation with, i.e. $reserves_control_branch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27071 [Bug 27071] Hold pickup library match not enforced correctly on intranet when using hold groups -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 Johanna Räisä <johanna.raisa(a)koha-suomi.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johanna.raisa(a)koha-suomi.fi -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38852] New: Make "Default holds policy by item type" work when record have also other item types than rule's given item type
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38852 Bug ID: 38852 Summary: Make "Default holds policy by item type" work when record have also other item types than rule's given item type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 admin/smart-rules.pl Default holds policy by item type Default hold policy by item type doesn't work when records all items don't have rule's given item type. For example Default holds policy by item type Item type = A Hold policy = From any library Hold picup library match = item's home library Return policy = item returns home Record - record has item with item type A and item with item type B - item type A is the same as rule's given item type - you place a hold Pickup at - all pickup libraries are shown and any of them is chooseable. You can even choose library that is not item's home library -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8088] Png-images of covers lost transparency
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8088 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8088] Png-images of covers lost transparency
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8088 --- Comment #11 from Hammat wele <hammat.wele(a)inlibro.com> --- Created attachment 176278 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=176278&action=e… Bug 8088: (follow-up) keep image transparency when importing a batch of cover images Images of covers must preserve transparency of png-images when uploading a batches of images in a ZIP file Plan test : Make sure you have a valid Zip file that contains the images to upload and a valid datalink.txt or idlink.txt file 1. Apply the patch. 2. In 'Cataloging > Upload local cover image', set 'LocalCoverImages' to 'show' and OPACLocalCoverImages to 'show'. 3. Click on « Drop files here » and select the ZIP file to upload then click «Process images» 6. For each notice check the transparency of images --->Notice the background is transparent -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38849] New: Unable to add multiple tags using MARC modification template
by bugzilla-daemon＠bugs.koha-community.org 09 Jan '25

09 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38849 Bug ID: 38849 Summary: Unable to add multiple tags using MARC modification template Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To Replicate on 24.05.05 1. Create a MARC modification template such as: Add new 500 $a value: This is a note 2. Find a bibliographic record which already contains text in 500$a or add it if it does not. 3. Apply the MARC modification template from the bibliographic page. See that the note is not added. Repeat these steps but find a bibliographic record in which the 500$a does not have any text. See that a note is added.* Repeat these steps for the record in which the note was added. See that a second note is not added. I tried other tags, such as adding a 655$a and was only able to add it one time and not a second time. In theory, the record should be able to have multiple 655$a. I was able to add multiple 500$a notes and 655$a tags using the basic editor as normal. I tested this on 23.05 and I could apply the same MARC modification template multiple times and add the note every time. *I was not able to replicate this consistently. On one site I was able to add the note and on another site the note was not added. The MARC modification templates and bibliographic frameworks were identical.The Frameworks had the 500$a enabled to show in the staff interface and editor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38464] New: Move funds between active budgets
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38464 Bug ID: 38464 Summary: Move funds between active budgets Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: holly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries would like the ability to move a single fund from one active budget to another. Current functionality only allows for all unspent funds to be transferred from a closed budget to a new budget. Ideally moving a fund from one budget to another would retain the history of orders from that fund. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38843] New: Ability to add note to patron charges without making payment
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38843 Bug ID: 38843 Summary: Ability to add note to patron charges without making payment Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries would find it helpful to be able to add notes to patrons' unpaid fines/fees without making a payment or writing off the charge. For instance, college/university libraries who send charge details to a centralized bursar's office could use this to indicate when the charge has been sent. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 38848] New: Add a "processing" status for notices between "Pending" and "Sent/Failed"
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38848 Bug ID: 38848 Summary: Add a "processing" status for notices between "Pending" and "Sent/Failed" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CHECKOUT, CHECKIN and HOLD digest notices have the potential for confusion when circ transactions happen while process_message_queue is running. We've seen instances in which large batch checkins via RFID happen during process_message_queue such that the notice received by the patron contains fewer titles than the notice shows in the database. We could prevent this if the cron were to gather the notices to act on, first set them all the "Processing" and then proceed with the rest of its work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29422] New: Add additional match types to dataTables api wrapper
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29422 Bug ID: 29422 Summary: Add additional match types to dataTables api wrapper 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart+koha(a)gmail.com, testopia(a)bugs.koha-community.org, tomascohen(a)gmail.com Depends on: 29302, 29408 The `criteria` key in the dataTables wrapper allows the developer to pick the type of comparison that is used in searches. However, it is currently limited to `contains`, `starts_with`, `ends_with` and `exact`. I propose to add some additional comparisons for numeric and date comparisons. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29302 [Bug 29302] The dataTables Koha RESTful API wrapper should allow picking match type at the column level https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29408 [Bug 29408] The datatables api wrapper is ambiguously named -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11