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

[Bug 14736] New: AllowRenewalIfOtherItemsAvailable slows circulation down in case of a record with many items and many holds
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14736 Bug ID: 14736 Summary: AllowRenewalIfOtherItemsAvailable slows circulation down in case of a record with many items and many holds Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This issue was originally reported in bug 14320. If the AllowRenewalIfOtherItemsAvailable sys pref is set to allow, and a borrower has an item checked out that has many items {30+} AND many holds {70+) on it, loading the checkouts table for this borrower takes FOREVER to load. The load time takes forever, because of the factoring that happens to determine if an item is truly available for renewal. At this time, the situation couldn't be improved in bug 14320, but I want this report out there, in case this becomes a bigger problem and/or someone comes up with a way to speed up the processing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 14557] New: Add holds count to holds tab
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14557 Bug ID: 14557 Summary: Add holds count to holds tab 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some librarians have expressed that it would be helpful if the holds tab displayed the count of holds for a record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 14714] New: koha-mysql tab-completion in bash
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14714 Bug ID: 14714 Summary: koha-mysql tab-completion in bash Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The koha-mysql script lacks tab-completion in bash which would be handy. It should complete using only one valid instance name. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 14732] New: Search patrons and add selected patrons to a new list gives an error
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14732 Bug ID: 14732 Summary: Search patrons and add selected patrons to a new list gives an error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: j.kylmala(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to reproduce this bug which disables the ability to create new list: 1. Search for patrons in staff side. 2. Select one or more patrons from the list. 3. Next to the text "Add selected patrons to:" choose [ New list ]. 4. Give that list a name. 5. Click save and notice the alert "an error occurred". -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 11943] New: AcceptShare should check for double accepts
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11943 Bug ID: 11943 Summary: AcceptShare should check for double accepts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl As a follow-up on bug 9032, noting a small problem here: If you share the same list twice and one patron accepts both invites, a second share record exists for the same combination of patron and list. Apart from that, there is no problem when viewing the lists or removing the share (both records are removed). When the user accepts the second time, he will be redirected to the list just as the first time. But for better housekeeping, I will still submit a patch here that deals with this situation. Imho this should not block pushing the 9032 patches. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14731] New: Sip2 not use Patron Attributes
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14731 Bug ID: 14731 Summary: Sip2 not use Patron Attributes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: ugurbulgan(a)sdu.edu.tr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com On KOHA when performing check out operations we can make the check out process possible via the user authentication from card number, user id and patron attributes informations. But on SIP2 the user authentication can only be made with the card number and user id. Is it possible to do user authentication with user id on SIP2 as well? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 6383] New: itemnumber not stored when a lost item is returned and credited to account
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6383 Bug #: 6383 Summary: itemnumber not stored when a lost item is returned and credited to account Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com When a lost item is returned and no longer lost the patron's account is credited, but the item number isn't stored in the itemnumber field in the db. To see what I mean try this report: select b.surname, b.firstname, bib.title, i.itemcallnumber, a.description from accountlines a left join borrowers b on (b.borrowernumber=a.borrowernumber) left join items i on (i.itemnumber=a.itemnumber) left join biblio bib on (bib.biblionumber=i.biblionumber) where a.accounttype='CR' and a.description like 'Item Returned%'; Since the barcode is printing in the description getting the itemnumber in to that table shouldn't be difficult ... I would think. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 1

[Bug 14730] New: let patrons upload their own images
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14730 Bug ID: 14730 Summary: let patrons upload their own images Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicole(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 if patrons could upload their own images - of course these would need to go in to moderation of some sort and have a switch to turn this option on/off. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 14729] New: circ rule for number of on shelf holds allowed
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14729 Bug ID: 14729 Summary: circ rule for number of on shelf holds allowed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nicole(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Would be nice to limit the number of on shelf holds allowed - so another option to the circ matrix for how many on shelf holds are allowed per patron/item type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14728] New: ignore warning for rest of session
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '15

26 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14728 Bug ID: 14728 Summary: ignore warning for rest of session 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: nicole(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 if there was an option to 'ignore warning' for the rest of the session when on a patron record and checking out. For example if you have it set to warn you that the patron owes money it will do it over and over for each item you check out and that's a bit annoying. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0