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

[Bug 14514] New: LocalHoldsPriority and the HoldsQueue conflict with each other
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '15

07 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14514 Bug ID: 14514 Summary: LocalHoldsPriority and the HoldsQueue conflict with each other 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 It appears that the LocalHoldsPriority feature and the Holds Queue are fundamentally at odds with each other. The problem appears to be that both are attempting to choose the best way to fill holds. When you are using the holds queue and you check in an item that has been selected by the holds queue builder, that part of Koha where the LocalHoldsPriority feature lives doesn't get to see all the holds in order to pick the best one. Instead only the hold selected by the holds queue builder is returned so to the LocalHoldsPriority feature, that is only one hold to pick from! The solution *may* be to add the similar logic that appears C4::Reserves::CheckReserves for handling local hold priority to C4::HoldsQueue::MapItemsToHoldRequests at the very beginning before it even attempts to match item level requests. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 7377] New: Feature Request: Add Lexile Search for Ranges of Lexile Scores
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '15

07 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7377 Bug #: 7377 Summary: Feature Request: Add Lexile Search for Ranges of Lexile Scores Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: lzuares(a)collsk12.org QAContact: ian.walls(a)bywatersolutions.com I would really appreciate the ability to search by Lexile range from within the OPAC and/or Staff Client. I was doing some Googling and came across two submitted patches, which don't appear to have made it into 3.6. The links are listed below. -Thanks http://lists.koha-community.org/pipermail/koha-patches/2010-January/010872.… http://lists.koha-community.org/pipermail/koha-patches/2010-January/010874.… -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 10707] New: inventory not removing lost status
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '15

07 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10707 Bug ID: 10707 Summary: inventory not removing lost status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When doing inventory it should remove the lost status if an item is marked seen ... cause if it's seen it's not lost. The problem / discussion here is on what should happen to items that are still 'checked out' and marked lost - should the patron be refunded? -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 9942] New: Circulation module cannot anonymise if anonymity user is not set up correctly.
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '15

06 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9942 Bug ID: 9942 Summary: Circulation module cannot anonymise if anonymity user is not set up correctly. Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: peterAtKohaBugzilla(a)pck.co.nz CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This is related to bug 6506. The MarkIssueReturned sub of Circulation.pm contains the comment: # The default of 0 does not work due to foreign key constraints # The anonymisation will fail quietly if AnonymousPatron is not a valid entry As noted on bug 6506, this is unacceptable. Severity cloned from that bug. This is a guess, but I surmise that how to test is to enable privacy, check out a book, return that book, and see if the book is in your borrowing history. If it is, that's a fail. If it isn't, that's a pass. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 14531] New: Check-in statistical report broken
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14531 Bug ID: 14531 Summary: Check-in statistical report broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The check-ins statistical report shows wrong data (at least) if you choose itemtype -> column and grouping by month. Steps to reproduce: - Go to Reports > Circulation statistics - Choose a period (row) when there is circulation - Choose to group 'Checkout' by month - Run report => SUCCESS: you see checkouts numbers by month and by item type - Go back and choose to group 'Checkin' by month - Run report => FAILURE: you see all cells contain zeros (and they shouldn't) and there is a weird NULL column, with the sum of the checkins (same value as 'Total' column). -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 13885] New: Cataloging search header should include more options
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13885 Bug ID: 13885 Summary: Cataloging search header should include more options Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)quecheelibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When cataloging it would be nice to have the option of moving easily to check-in or regular catalog search -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 13886] New: Add ability to merge records directly from cataloging search
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13886 Bug ID: 13886 Summary: Add ability to merge records directly from cataloging search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nick(a)quecheelibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Current workflow requires that if one notices duplicated records in a cataloging search they must then perform a standard search, add the records to a list, then go to that list and merge them. It would be nice to be able to merge directly from the cataloging search screen (and the standard search screen, but one step at a time) -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 13023] New: Nonpublic note for items should be mapped to a database column like itemnotes
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13023 Bug ID: 13023 Summary: Nonpublic note for items should be mapped to a database column like itemnotes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl An item's public notes are mapped to a db column, but the librarian only notes are not. We need to map these so in the future we may display them in places other than the editor. -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 11714] New: GetBudgetHierarchy needs optimization
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11714 Bug ID: 11714 Summary: GetBudgetHierarchy needs optimization Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The method C4::Budgets::GetBudgetHierarchy() retreives from database budgets in an array containing a tree of budgets (parent -> children -> children, ...). The code generating this tree with the SQL results needs optimization because when a lot of budgets exists, it can run during several minutes. Have a look at code resume : while (1) { foreach my $r (@res) { foreach my $r2 (@res) { } } } With 1000 budgets there can be 1000x1000x1000 loops ... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 9936] New: SIP2 should use C4/Auth.pm for user authentication
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '15

05 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9936 Bug ID: 9936 Summary: SIP2 should use C4/Auth.pm for user authentication Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: colin.campbell(a)ptfs-europe.com SIP2 checks the password directly against the database instead of using C4/Auth.pm. This means that it won't work with LDAP and possibly CAS. Also, we should do authentication the same everywhere in Koha to ensure consistency. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5