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

[Bug 3534] Patron quick add form
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3534 --- Comment #66 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 84851 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84851&action=ed… Bug 3534: (QA Follow-up) Fix the return value for the new format, it should be a hashref, not a string -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 6685] circ rules by groups of items
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6685 Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com --- Comment #14 from Caroline Cyr La Rose <caroline.cyr-la-rose(a)inlibro.com> --- I've also had a request for this. My case is pretty much the same as what the others said. This particular library has several itemtypes that need to be limited as a group, but the rest of the parameters change. For example, they have adult DVD fiction, adult DVD non-fiction, children's DVD fiction and children's DVD non-fiction. Users can borrow 5 DVDs total. Fiction DVDs go out for 3 days and non-fiction DVDs go out for 21 days. Adult can borrow both adult and children's DVDs whereas children can only borrow children's DVDs. Right now, there is no easy way to enter these rules and limit the loans correctly. Either I group fiction DVDs together and non-fiction DVDs together, but then I have to have another subterfuge for limiting children from borrowing adult DVDs plus there is no way of limiting the total number of loans to 5. Or I group children's DVDs together and adult DVDs together, but then I have no way of varying the loan period and no way to limit to 5 total loaned DVDs. Anyway, it's a brain wrangling puzzle, no matter how you look at it. Chris' idea of using itemtypecat is good. The other idea I had was to use something similar to Default checkout limit by patron category, but for itemtype categories. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 7088] Cannot renew items on hold even with override
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7088 Andrew Isherwood <andrew.isherwood(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off --- Comment #28 from Andrew Isherwood <andrew.isherwood(a)ptfs-europe.com> --- (In reply to Katrin Fischer from comment #24) > 4) I'd also have expected the renewal to be locked initially and the > checkbox to unlock it. Reasoning: Renewing an item with a hold should always > be an exception. The way it's now a "renew all" checked on top will also > check the "on hold" ones which might be easily missed. We could relabel the > checkbox and use it for both: Allow override of renewal restrictions? Hi Katrin I've just attached a patch that addresses this. The on hold items now behave in the same way as items that have reached their renewal limit, they are not selectable until the checkbox is checked. Speaking of which, I've re-labelled the checkbox from "Override renewal limit" to "Override renewal restrictions" as per you suggestion. So now, "Select all" and "Renew all" will not act upon the on hold items unless the override is checked. I'm not familiar with the process when a UI label is changed, is there any maintenance work that needs to happen so translations don't break? >3) I don't understand the new entry form for the hold due date. My feeling is that we should use the one existing already for entering the new due date for any override. Having 2 forms seems confusing. We discussed this internally at great length when speccing out the development. It was felt by both our customers and us that having two date selection boxes made most sense since it's conceivable that the user may wish to have different due dates for on hold items and non-on hold items. The fact that the "On hold due date" date input doesn't appear until an on hold item is checked for renewal (if you're not seeing this behaviour, rebuild your CSS) reinforces it's purpose. I'm going to set this back to Signed off as I believe it's ready for another QA run :) Thanks for your feedback! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7088] Cannot renew items on hold even with override
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7088 --- Comment #27 from Andrew Isherwood <andrew.isherwood(a)ptfs-europe.com> --- Created attachment 84850 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84850&action=ed… Bug 7088: (follow-up) Default hold checkbox display As per item 4 here: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7088#c24 Now, the checkbox for renewing on hold items behaves the same way as the checkbox for renewing items that have reached their renew limit. It is necessary to check the re-labelled "Override renewal restrictions" checkbox before it is possible to select on-hold items for renewal. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 16840] New: URLs for old releases are broken with every new release
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16840 Bug ID: 16840 Summary: URLs for old releases are broken with every new release Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: jsn.sherman(a)gmail.com I'm working up a nice CentOS 7 ansible role that builds Koha from the tarball release. The way you shuffle tarball upon release makes automating koha builds more difficult than it has to be, and is user hostile. When you move tarballs under old releases, you don't offer a redirect to the new location, instead you return a 404. When you publish content to the web, you should treat that URL as valid for as long as you have the associated content. In this case, you still have the content, and you know exactly where it is. Ideally, you would offer clients a 301 redirect to the new location. You should only return a 404 when you deleted content or honestly have no idea what the client is asking for. This is a general website stewardship issue, and it may not seem like the most critical thing when you are trying to get a release out the door, so I would be happy to contribute my expertise and/or time to improve this aspect of release management for Koha. Thanks! -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 11055] Add 'minutes' as a load period unit
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11055 Arthur Suzuki <arthur.suzuki(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14293] Error in the calculation of the suspension of users per day
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14293 Arthur Suzuki <arthur.suzuki(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.suzuki(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14293] Error in the calculation of the suspension of users per day
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14293 Koha Team Lyon 3 <koha(a)univ-lyon3.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha(a)univ-lyon3.fr Status|In Discussion |Failed QA --- Comment #5 from Koha Team Lyon 3 <koha(a)univ-lyon3.fr> --- The present path doesn't apply anymore : t/db_dependent/Circulation/IssuingRules/maxsuspensiondays.t CONFLICT (content): Merge conflict in t/db_dependent/Circulation/IssuingRules/maxsuspensiondays.t Auto-merging C4/Circulation.pm CONFLICT (content): Merge conflict in C4/Circulation.pm error: Failed to merge in the changes. To give a feedback to Kyle'question : > I suppose the question is, should hourly loans suspend in days the number of hours overdue? If an hourly loan is 3 hours late, should the patron be suspended for 3 days? If so, changes are needed. In our library, we don't want hours late to be change in days suspension. If "Suspension in days (day)" = 1, we want that 2h or 2mn late calculate 1 day of suspension. If there more than 24h, then it will be 2 days of suspension. I hope that this bug could be correct easily. Sonia -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13342] not logged in user can place a review/comment as a deleted patron
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13342 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de Severity|trivial |minor --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- This problem caused us some headache as it happened quite often in one of the libraries we support. I just confirmed that the problem still exists in 18.11 and therefore possibly master as well. Thx, Olli, for reporting! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 3514] Returning items through patron Details tab doesn't activate all circulation functions
by bugzilla-daemon＠bugs.koha-community.org 07 Feb '19

07 Feb '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3514 --- Comment #15 from Ray Delahunty <r.delahunty(a)arts.ac.uk> --- Assisted by our support company we have been able to make improvements. We have hidden the Return functionality on the Patron Detail screen using the Administration > Configure columns feature. Under Circulation in the id=issues-table, we ticked the Hide checkbox for "checkin", and under User in the id=issues-table we ticked the Hide checkbox for "checkin". However I don’t see a way of using this columns configuration functionality to hide the ability to cancel a reservation on the Patron Detail page. I guess what I am looking for is a id=holds table under Users (there is currently one under Circulation). If there were that table with the Column name being Delete we could hide the functionality that is causing the problem. (We are on 17.05 and I checked 18.05 and while there is an additional table / view under Users it doesn’t offer what I need). Our support company has used css to hide the “actions” options (including the Cancel marked holds and Suspend all holds), which works- it does leave the Delete? column with the tickbox, but applying the actions is not possible. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are the QA Contact for the bug.

1 0