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

[Bug 32316] New: Send invitations to share a list immediately
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '23

24 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32316 Bug ID: 32316 Summary: Send invitations to share a list immediately Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Invitations to share a list (SHARE_INVITE) are sent via the message_queue, so there can be a noticeable delay. It would be nice if we could use the same trick here as for password reset and self registration verification mails, that are sent through message_queue, but processed/sent immediately. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 19464] New: emailLibrarianWhenHoldIsPlaced email enhancement
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19464 Bug ID: 19464 Summary: emailLibrarianWhenHoldIsPlaced email enhancement Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: karen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A school library that I'm working with would like the email sent by the preference emailLibrarianWhenHoldIsPlaced to go the library where the hold is placed rather than the admin email address. Sending an email directly to the branch email address would be a really nice option for multibranch systems that want to use this system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 24231] New: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24231 Bug ID: 24231 Summary: Create classes to the message that was created with sys pref UpdateItemLocationOnCheckin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the introduction of this new system preference UpdateItemLocationOnCheckin, the cart to shelf system preference was removed and rolled into this one. However, the alert that comes along with this new system preference is not a welcome addition to the libraries that are using Cart to Shelf functionality. Prior to this, cart to shelf functionality was a backend process that would (without staff interaction) take an item that was checked in, move it to the cart. Now, when an item is checked in (at the system preference UpdateItemLocationOnCheckin has the value _ALL: CART - each time an item is checked in, the staff get a large yellow message box and an alert. If we add a class to this message or even 2 classes this would allow these alert/audio to be turned off for those libraries that don't wish to receive this yellow alert box with every checkin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 28895] New: Don't fill in items.location with NewItemsDefaultLocation if blank
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28895 Bug ID: 28895 Summary: Don't fill in items.location with NewItemsDefaultLocation if blank Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On bug 27545 we extended the use of NewItemsDefaultLocation to affect item creation in different place, not only the add item form from the cataloguing module. There is at least one unexpected behaviour (see bug 27545 comment 11): if an item is edited and has a blank location, the syspref's value will be used. We could fix the item edition but it will lead to another inconsistency: if we don't set a location when an item is created, we are enforcing the location to be set to the syspref's value anyway. What's the exact expected behaviour? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 30799] New: Add REST API route to update biblio metadata
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30799 Bug ID: 30799 Summary: Add REST API route to update biblio metadata Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: REST API Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com CC: tomascohen(a)gmail.com Blocks: 17371 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 28201] New: Add API routes to update and create biblio record
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '23

23 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28201 Bug ID: 28201 Summary: Add API routes to update and create biblio record Change sponsored?: --- Product: Koha Version: master Hardware: All URL: https://wiki.koha-community.org/wiki/Biblios_endpoint_ RFC OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi CC: tomascohen(a)gmail.com Blocks: 17371 We need PUT and POST API routes to modify and create biblio records. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17371 [Bug 17371] Add routes for biblios [OMNIBUS] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 27211] New: Shelving locations for holds
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27211 Bug ID: 27211 Summary: Shelving locations for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Every library handles holds differently, but one thing remains the same through most, if not all...when a hold is triggered, it waits somewhere in the building. Some libraries might have more than one shelving location. One issue that has always been a problem for libraries that have automatically expired holds, or any library that has a cancelled hold. Unless someone is going through each of the holds on the hold shelf daily, how do you find the item? If you look up an held item that has automatically expired (guessing on this, as we don't do this), or an item that is cancelled, the item shows the regular shelving location and that it is AVAILABLE. This is of no help to staff or the patron. One solution might be to use the CART feature, and update the temporary location to reflect a given shelving location for holds. There are a few issues for using this feature: 1) the CART location reverts back to the permanent shelving location after X amount of days. This would have to be overridden to stick until the item is actually not being held and is checked in, and then go through the regular CART routine, if any. 2) When triggering a hold, the hold would have to know which shelving location is being used. We could either define a default location that could be changed to a select few locations (maybe a HOLDLOC table?), so the default could be used without extra steps, OR even further, a default shelving location defined for each desk (I know the desk feature is part of an upcoming Koha upgrade). If staff don't want the public to know that the item is on a public hold pickup shelf, the OPAC description could simply read "See staff for assistance". Thoughts? Is this doable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17480] New: UpdateNotForLoanStatusOnCheckin preference requires space after colon
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '23

22 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17480 Bug ID: 17480 Summary: UpdateNotForLoanStatusOnCheckin preference requires space after colon Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 11629 YAML requires that there be a space after a colon, so the UpdateNotForLoanStatusOnCheckin preference does too: -1:0 will not work -1:<space>0 will work We should either handle this gracefully for the user (preferable, since this preference will only use numeric values), or update the preference's description to highlight the requirement. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11629 [Bug 11629] Add ability to update not for loan status on checkin -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 21700] New: Additional Patron information on purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21700 Bug ID: 21700 Summary: Additional Patron information on purchase suggestions Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org A library has suggested that it would be helpful to view the card type of the patron when managing purchase suggestions. For instance, if an item is not going to be purchased, the library would attempt to ILL the item, but since not all patron categories are eligible for ILLs, knowing the patron category from the beginning of the review process would be helpful. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 30483] New: Should issues.borrowernumber and issues.itemnumber be NOT NULL ?
by bugzilla-daemon＠bugs.koha-community.org 21 Mar '23

21 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30483 Bug ID: 30483 Summary: Should issues.borrowernumber and issues.itemnumber be NOT NULL ? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Sync problem between structure and dbrevs. For old prod databases only (that passed the 3.05 dbrevs) Note that I did not expect such a difference in a vital table like issues ! update $DBversion = "3.05.00.009"; $dbh->do("ALTER TABLE issues MODIFY COLUMN borrowernumber int(11) NOT NULL"); $dbh->do("ALTER TABLE issues MODIFY COLUMN itemnumber int(11) NOT NULL"); Current structure allows them to be NULL. I wonder if that is correct. An issue should have a borrower and an item, right? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27