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

[Bug 13680] New: Items list on edit items page separates add items form from header and sidebar
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '15

23 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13680 Bug ID: 13680 Summary: Items list on edit items page separates add items form from header and sidebar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nick(a)quecheelibrary.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 35720 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=35720&action=edit Proposed layout On records with multiple items attached the add items form can be pushed down the page, separating it from the header and sidebar and requiring a choice between where pages focus should fall and often leading to scrolling depending on your action. See bug 11905 A different solution would be to move the existing items list to the bottom of the page. This is a fairly striking difference, but with the addition of edit item links on the record detail page I don't think it makes selecting an item to edit more onerous. That being said, change is upsetting and I believe this would need some discussion. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 14595] New: Improve "Checkouts" list regarding due dates
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '15

23 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14595 Bug ID: 14595 Summary: Improve "Checkouts" list regarding due dates Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org The list of currently checked out items of the self-checkout system should be improved regarding due dates in the following ways: 1) Reverse the sort order: currently it's sorted descending while it should rather be sorted ascending. This could of course be made optional via a system preference. See related: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1552 2) Flag overdue items, say, by displaying them in red. Thanks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14593] New: Send notifications for pending staff actions (moderation, suggestions)
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '15

23 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14593 Bug ID: 14593 Summary: Send notifications for pending staff actions (moderation, suggestions) Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There should be an option to enable notices to the library staff whenever certain workflow actions are pending. These include at least all moderated entities like pending comment or tags, as well as new purchase suggestions. All of these are currently displayed on the staff client dashboard (should also be made more prominent) but it would be great to have the option to send, say, an email to all library staff (i.e. a certain patron category?) or to an optional pre-configured address (could be a mailing list) with an update on all pending actions, preferably with types, counts and links to the relevant staff pages. The use case for this are small libraries that primarily use a self-service model and hence don't have their staff continuously monitoring the dashboard for new TODOs. Notifying them about pending actions would streamline the process significantly. Thanks! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 12144] New: Book drop mode mode erasing fine when CalculateFinesOnReturn is enabled
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12144 Bug ID: 12144 Summary: Book drop mode mode erasing fine when CalculateFinesOnReturn is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When returning items with Book drop mode mode enabled and CalculateFinesOnReturn set to "calculate", the amountoutstanding for a fine, no matter how large, is reduced to 0.00 To reproduce: 1) Fine a patron with and overdue item that has fines 2) Ensure CalculateFinesOnReturn is enabled 3) Browse to the returns screen, check the "Book drop mode" but *not* the "Forgive overdue charges" box 4) Return the item 5) Check the fine for that item, it should now be reduced to 0.00 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 14591] New: book drop / drop box mode incorrectly decrements accrued overdue fines
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14591 Bug ID: 14591 Summary: book drop / drop box mode incorrectly decrements accrued overdue fines Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Book drop mode will always subtract the lastincrement value from accrued overdue fines, even if the loan is so overdue that it reached the max fine amount prior to effective return date. For example, if a loan was due on 1/15/2015 and is charged 0.20 per day with a maximum fine of 1.00, if it is returned on 2/1/2015 (assume no holidays), the fine should remain at 1.00. However, currently the fine will be reduced to 0.80 if the item is checked in using book drop mode. I believe this can also account for the behavior that Kyle reported in bug 12144 Bug 13044 is also relevant here: making book drop mode become a special case of the SpecifyReturnDate functionality (and in particular, removing the dropbox logic from _FixOverduesOnReturn) is an opportunity to avoid inappropriate reduction of max overdue fines. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13044] New: Deprecate old dropbox mode
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13044 Bug ID: 13044 Summary: Deprecate old dropbox mode 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We now have two ways to backdate returns, the older "Book drop" mode, and the newer arbitrary backdating of returns feature. We should deprecate the older mode by having the "Book drop" checkbox insert the date the library was last open into the date field. We would also need to remove the system preference to have the returns backdating feature always on. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 14437] New: Refactor C4::Auth::haspermission() to Koha::Object and return errors better.
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14437 Bug ID: 14437 Summary: Refactor C4::Auth::haspermission() to Koha::Object and return errors better. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Refactoring haspermission() and improving documentation. Also added a return value unintrusively (in the old context still RETURNS the same result) to tell which permission failed. Modification should have no adverse effects, other than killing the process (by throwing uncaught exceptions) if no valid parameters are given. Depends on Bug 13995 - Proper Exception handling so apply it first. Cannot create unit tests because there is no CRUD interface for permissions. Not even with TestBuilder. TEST PLAN: 1. Find a borrower with only the catalogue-permission. 2. try opening this page cgi-bin/koha/tools/manage-marc-import.pl 3. You get "Permission denied" -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 11512] New: Forced holds that violate issuing rules will never be filled
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11512 Bug ID: 11512 Summary: Forced holds that violate issuing rules will never be filled 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently in Koha, if you choose to force a hold from the staff side that would contravened the current issuing rules, that hold will never be filled, as it is always skipped over by CheckReserves. I think the only way to resolve this is to add a flag to the reserves table to alert the system that despite the fact that this hold should usually be skipped over, in this case, it should not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 14587] New: Acq: Make it possible to edit asort1 and asort2 values on receive
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '15

22 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14587 Bug ID: 14587 Summary: Acq: Make it possible to edit asort1 and asort2 values on receive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The values for asort1 and asort2 might change between order and receiving the book, but there is currently no way to change it, without reopening the basket which will mess with your order history. The other use case is changing the fund on receive - which might make the fund and the asort values not match as they are defined on the fund level. It would be nice if the statistic values could be edited during the receive process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 12160] New: Rename intranetuserjs to IntranetUserJS
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '15

21 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12160 Bug ID: 12160 Summary: Rename intranetuserjs to IntranetUserJS 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: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ... to match IntranetUserCSS The same should be done with opacuserjs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19