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

[Bug 17623] New: Two different fine amount for same record
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17623 Bug ID: 17623 Summary: Two different fine amount for same record Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: vimal0212(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Dear Friends, Our Koha version 3.22.11. Two different fine amount show on two occassion for same book issued. e.g. Rs. 18 at circulation page and Rs. 20 at Fine payment section. Please see the screen shots attached. https://s13.postimg.org/u4vhngr07/FINE_ERROR1.png https://s14.postimg.org/lrmptbjdd/FINE_ERROR2.png https://s11.postimg.org/6bapri2er/FINE_ERROR3.png Regards, -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 17541] New: Add ability to log all barcodes scanned at checkin
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17541 Bug ID: 17541 Summary: Add ability to log all barcodes scanned at checkin 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On occasion, librarians claim that a barcode was scanned successfully at checkin but the item was not returned. It would be useful to be able to log all scanned barcodes at checkin regardless of validity to know if the barcode scan made it to Koha or if there is an issue keeping it from being received by the server. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 17360] New: Test the installer process
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17360 Bug ID: 17360 Summary: Test the installer process Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org On bug 16554, we needed a script to test that all the .sql files were correctly inserted. It could be reuse later (and pushed?). -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 17413] New: Translatability: Rental fee, Renewal of Rental Item etc. are hard coded
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17413 Bug ID: 17413 Summary: Translatability: Rental fee, Renewal of Rental Item etc. are hard coded Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Descriptions for account lines are hard coded in C4/Criculation.pm, e.g. 'Rental', 'Rent', 'Renewal of Rental Item'. They are not translatable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 17412] New: Circulation rule for "not for loan" items
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17412 Bug ID: 17412 Summary: Circulation rule for "not for loan" items Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: costalc(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries set items with a "not for loan" status mark (tag 952, subfield 7). But many times, it is needed to loan this material for few days. In Koha it is possible to check out "not for loan" items. But nevertheless it is not possible to set a circulation rule for these cases. So, it would be nice to add a column in the circulation rules parameters to set a new "not for loan period" column. Now, "not for loan" checkouts inherit the normal rule that is defined in the circulation rules parameters for it's itemtype. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 17408] New: paycollect.pl should show more information
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17408 Bug ID: 17408 Summary: paycollect.pl should show more information 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you click Pay selected on pay.pl, paycollect.pl should show a list of what is being paid as confirmation, and not just a total. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 17306] New: Update scripts fail with Mysql 5.7
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17306 Bug ID: 17306 Summary: Update scripts fail with Mysql 5.7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: rsantellan(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Doing a complete migration from koha 2 to koha 3 with the update22to30.pl and updatedatabase.pl found a few problems with the consistencies of the SQL with the new MySQL 5.7. I have changed the script to be able to run, the only one that is not working properly is 3.09.00.051 that have a bad group by condition but I never have use that module and don't know how to fix it. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 17259] New: Allow batch removal of restrictions
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17259 Bug ID: 17259 Summary: Allow batch removal of restrictions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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 It would be nice to have a ways for librarians to remove blocks of debarments (end of the school year, etc) using the batch patron modification tools -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17198] New: KOha database resotre
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17198 Bug ID: 17198 Summary: KOha database resotre Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: matsyufsms(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org HEllo I get error whever i try to restore koha.sql on new installaion Error = ERROR 1062 (23000) at line 113372: Duplicate entry 'INNODB' for key 'name' HOw cna i get about it Yusuf -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 17150] New: Cancelling holds over process needs improvement
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17150 Bug ID: 17150 Summary: Cancelling holds over process needs improvement 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 Created attachment 54584 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54584&action=ed… Cancel Hold buttons I'm not seeing a bug with all of this spelled out exactly, so if I repeat something already posted, I'm sorry. It may be that some of this needs to be broken into different bugs, or is already addressed in another bug. I am linking together what I know to be part of the problem, but not the whole picture. Cancelling a hold that is over is a tedious process at best. I'll try to explain what we are seeing. So, when we go to the Holds over tab in the Holds awaiting pickup, we find the item. Issue #1 (holds01.png): Even though the buttons are different, they don't act different, they are not even necessarily accurate about the item, and they have lost functionality between 3.18 to 3.22. Issue #2: Even though a transfer might be triggered, you have to check the item in to get the slip. Waste of time. It should come up with this choice when the transfer is triggered while cancelling (holds04.png). Issue #3: Even though the item might have another hold request, it isn't revealed when you cancel the hold. So, you have to check EVERYTHING in that you cancelled to see if there is a hold, or a pending transfer. Again, this should happen when cancelling the hold. Issue #4: As mentioned in issue #1, the buttons are not very accurate about what happens next with the item. Sometimes there is a hold request at the current location (holds05.png). So, you have to check ALL of these items in to find out if they have holds. Again, this should happen when cancelling the hold. Issue #5: Even though there is a hold request for an item you are cancelling, cancelling the hold applies a transfer. So, when you check the item in after cancelling, you see a transfer to the item's home location AND the hold request (holds06.png). This is CONFUSING and crazy. Especially if it is to the same location. We end up having to cancel the hold, check the item in, cancel the transfer, check the item in again, and then trigger the hold. Why not just skip cancelling the transfer and trigger the hold? Because the transfer will still be in the system! Crazy! Issue #6: When you cancel a hold, you get bounced back to the Holds waiting tab, so you have to click back over to the Holds over tab for the next item. I think there is another bug on this one, but I can't find it at the moment. So, why don't we just use the Cancel All button (by the way, shouldn't it read "Cancel all")? Because not all the items are still in our hands. Some items end up walking out without being checked out. Issue #7: It would be great if there were a button to mark the item missing, or maybe someone calls and finds out the person has the item, so a button to check the item out to that patron would be great. Issue #8: I've noticed another little quirk. If you compare holds04.png with holds06.png, you'll see that the transfer popups are different. holds04.png has no buttons. Just links. I know that one transfer is related to the hold, which doesn't make sense because when we cancel it, it doesn't affect the hold. Issue #9: You may also notice on holds06.png, the address fits on the full line in the transfer popup, but not in the holds popup. The popup boxes are the same size, and the bullets offset in the same place, so something is off on the formatting. Issue #10: Cancelling a hold takes 2 to 3 times longer in 3.22 than it did in 3.18. This is surprising since the popups were taken away! So, ideally, if these are legitimate issues, and are addressed, this is what we would expect to see: 1: Just show a Cancel button for all items with the words "Cancel hold". What happens when you click the button should be self explanatory. Perhaps if Koha didn't have to determine the next status of the item just to create a button, the refresh of the page would improve. Hmmmmm.... 2: When you cancel a hold, if the item needs to go home, it will show the transfer popup to let you print the slip. 3: When you cancel a hold, if the item has a hold, it doesn't trigger a transfer, and only shows the hold popup, whether it is a local hold or going somewhere else. 4: Whether it has a popup or not, when done with the popup it should put you back on the same tab you were last on. 5: Buttons should be on the transfer popup. 6: Formatting should be consistent between the hold and transfer popups (I know, this is sooooo trivial). 7: We should have more options for holds that are over, than just Cancel, since there are other things that can be happening, like missing or already with the patron. A "Mark missing" button and a "Checkout to this patron" button would be nice. Sorry if this sounds like a rant. I know that how we do things isn't the way everyone does things, but this has bugged me for a LONG time, and I think these are some great improvements, even if they need to be tweaked a bit to accommodate other workflows. I will add the screens and see alsos in a moment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20