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

[Bug 26295] New: Merge bib records - rebuild Zebra
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '20

30 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26295 Bug ID: 26295 Summary: Merge bib records - rebuild Zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org https://koha-community.org/manual//20.11/en/html/cataloging.html#merging-re… There is a paragraph that reads: "Important It is important to rebuild your zebra index immediately after merging records. If a search is performed for a record which has been deleted Koha will present the patrons with an error in the OPAC." One of our customers queried this as obviously having to rebuild the zebra index following one simple merge is not very efficient. It would appear that standard indexing deals with the merged records as standard now. A catalogue search on the terms in question (to locate the two records) will now only find the master record following the merge and there is no retrieval of the second record that has been merged. If a rebuild is no longer required, then it might be a good idea to remove this warning from the manual? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 26321] New: Anjimmm
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '20

30 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26321 Bug ID: 26321 Summary: Anjimmm Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: sitij0300(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 109298 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109298&action=e… Anjim -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26319] New: Disable holds when all libraries are set to be no pickup-location
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '20

29 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26319 Bug ID: 26319 Summary: Disable holds when all libraries are set to be no pickup-location 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When all libraries are set to "pickup location" = No, trying to place a hold should lead to a helpful error message in staff and hold functionality in the OPAC should be hidden altogether. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26318] New: The price mentioned on the pricing page is incorrect.
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '20

29 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26318 Bug ID: 26318 Summary: The price mentioned on the pricing page is incorrect. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: maytinee.apiwansri(a)sjsu.edu QA Contact: testopia(a)bugs.koha-community.org This is a web service bug! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9596] Allow longoverdue.pl to be configured by library
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9596 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew(a)bywatersolutions.com --- Comment #1 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- +1 -- But would that be limiting based on the patron branch, the item branch, the issuing branch? The branch specified by circcontrol? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 22939] New: Hard due date should block renewals when it wouldn't extend the due date
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22939 Bug ID: 22939 Summary: Hard due date should block renewals when it wouldn't extend the due date Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- It seems like it would make sense for renewals to be blocked if there is a hard due date set equal to or before the time the renewal would normally allow it would block renewing. aka: School branch (branch a) is closing for the summer. They set their hard due date to be 5/17/19. Their checkout period is 14 days, they allow 1 renewal, and the renewal is 14 days. Patron at branch b (not closing for the summer) gets a book from branch a on hold and checks it out 5/3/19. Due date is 5/17/19 and it says they have 1 renewal on the item. There is no warning about a hard due date and it looks like they should be able to renew it. On 5/16/19 they come in and want to renew the item, as their account says there is a renewal available. When the item is renewed it only gains 1 day. The patron has no indication why it is renewing differently than before. If the renewal was blocked (box grayed out or changed to zero) staff could preserve the previous renewal information without as much confusion for patrons. Lisette -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22269] New: Pay amount - modal confirmation of amount to return to patron should be suppressed if attempting to pay (not collect) more than owed
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22269 Bug ID: 22269 Summary: Pay amount - modal confirmation of amount to return to patron should be suppressed if attempting to pay (not collect) more than owed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: 1 - Add a fine or find a patron owing money 2 - Go to pay fines, pay amount 3 - Set amount to be paid higher than amount owed 4 - Set amount collected higher than amount paid 5 - Note you get a confirmation modal, confirm 6 - payment fails Expected action would be that modal is prevented or notifies user that they are trying to pay more than owed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 10758] Show bibliographic information of deleted records in acquisitions
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10758 rkuiper(a)roundrocktexas.gov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkuiper(a)roundrocktexas.gov -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julian.maurice(a)biblibre.com Status|Signed Off |Patch doesn't apply --- Comment #145 from Julian Maurice <julian.maurice(a)biblibre.com> --- This needs to be rebased (conflict on gulpfile.js - see bug 26228) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26315] New: statistics.datetime should keep the initial value
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26315 Bug ID: 26315 Summary: statistics.datetime should keep the initial value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: arthur.suzuki(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org It appears that statistics.datetime is created with SQL NOW(); Although this is perfect in most case, when using binarylogs to synchronize between two database server instance (like in master-slave configuration), this will lead to erratic data being imported into the slave server if a delay is encountered between creation on the master and import on the slave. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1