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

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

28 Aug '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 6

[Bug 35203] New: Koha::Biblio->get_coins support 214 field in addition to 210 (pubyear and publisher values)
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35203 Bug ID: 35203 Summary: Koha::Biblio->get_coins support 214 field in addition to 210 (pubyear and publisher values) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hello, The publisher info and publication date for the <span Z3988> tag (corners) are based on the 210 but more and more records are now based on 214. Hence a loss of information. NB This is also the case for BIBTEXT and RIS formats. I will therefore propose a patch to add the new 214 field to the get->coins() method. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20859] New: SMS and other notification preferences during self registration
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20859 Bug ID: 20859 Summary: SMS and other notification preferences during self registration Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Some libraries would prefer the option for patrons to choose their notification preferences and setup their SMS information during registration. -- You are receiving this mail because: You are watching all bug changes.

1 37

[Bug 18002] New: Add functionality to create a vendor and budget in the onboarding tool
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '26

28 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18002 Bug ID: 18002 Summary: Add functionality to create a vendor and budget in the onboarding tool Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 17855 Add two additional interfaces to the onboarding tool to allow the user to create a vendor and budget before logging into Koha for the first time, thereby allowing users to get acquisition requirements set up. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17855 [Bug 17855] Updated Koha web installer and new onboarding tool feature to guide users through setting up Koha -- You are receiving this mail because: You are watching all bug changes.

1 97

[Bug 17387] New: Add an undelete feature for items/biblios
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17387 Bug ID: 17387 Summary: Add an undelete feature for items/biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries would like to be able to restore items accidentally deleted. This should be possible, rows can be copied over as long as there are checks in place for unique ids. -- You are receiving this mail because: You are watching all bug changes.

1 274

[Bug 30515] New: Move Overdue transports to patron messaging preferences
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30515 Bug ID: 30515 Summary: Move Overdue transports to patron messaging preferences 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The idea of this bug would be to allow patrons to choose which format they would like to receive their overdues in while maintaining at least one selection as mandatory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 110

[Bug 26129] New: Add a new 'configurations' table
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '26

27 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 Bug ID: 26129 Summary: Add a new 'configurations' table 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This table should be designed from the beginning to allow global and per-library configuration entries. It would replicate the circulation_rules schema, but adapted to be a(n eventual) replacement for system preferences. This came up on my development for an SMTP configuration page, in which I originally added an smtp_servers page, that could really be generalized like this for other uses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 95

[Bug 32196] New: One should be able to remove a borrower relationship whenever one exists
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32196 Bug ID: 32196 Summary: One should be able to remove a borrower relationship whenever one exists Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 12446 Per bug 32195, there is still at least one way for a patron to end up with a guarantor in a category that does not allow guarantors. When that happens, the patron edit screen does not show one the relationship and therefore the relationship cannot be removed. One should *always* be able to remove an existing relationship. To recreate: 1: have a patron category where CanBeGuarantee is set to Yes. 2: Create a patron in that category, give them a guarantor 3: edit the patron category to set CanBeGuarantee to No 4: confirm your patron still has a guarantor that shows on the details page, but the guarantor no longer shows on the edit screen 5: this means the guarantor cannot be removed :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 [Bug 12446] Enable an adult to have a guarantor -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31681] New: Daily digest notice for ALL notices
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '26

26 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31681 Bug ID: 31681 Summary: Daily digest notice for ALL notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org What if a patron had the option to have a SINGLE notice per day, that was a digest of all notices to them? So, if they have this option checked, they would get a notice at the end of the day, or beginning, that would contain any hold, overdue, predue, etc notices. So, if this is checked, instead of queuing up for the regular cron, maybe the notice is sent in a new cron that is once a day. If done, it might also be beneficial to note on the parton's notifications how the notification was queued (right away/daily). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33374] New: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons
by bugzilla-daemon＠bugs.koha-community.org 25 Aug '26

25 Aug '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33374 Bug ID: 33374 Summary: Holds captured at different branch when pickup branch has a copy on shelf can create long wait times for patrons Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1. Have a multibranch system where holds can transfer between 2 or more libraries 2. Have a bib with 2 or more items at different branches. 3. At Branch A checkout Branch A's copy of the item to a patron 4. At Branch B place a record level hold for a Branch B patron (where branch b has a copy of the item available on the shelf) 5. Return Branch A's book at Branch A. It fills the hold for Branch B patron In some cases this makes the patron wait much longer for a hold. It would be great if there was a way to set holds not to fill from other libraries if there was a copy available at the pickup location. Some consortiums have branches that only get deliveries once or twice a week. If they happen to check in an item that could be filled at the pickup branch before the pickup branch scans the hold there, it could take much longer for the patron to get the item. Lisette -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5