January 2016 - Koha-bugs - lists.koha-community.org

[Bug 15298] New: z39.50 admin setup, options column suggested changes
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15298 Bug ID: 15298 Summary: z39.50 admin setup, options column suggested changes Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On the z39.50 server admin page (cgi-bin/koha/admin/z3950servers.pl), the options column has three links lumped together for edit, copy, delete. Could those options be restyled to match the actions menu on the saved reports page? cgi-bin/koha/reports/guided_reports.pl?phase=Use%20saved -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 14810] New: Improve messages in patron anonymizing tool
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14810 Bug ID: 14810 Summary: Improve messages in patron anonymizing tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When successfully anonymizing circulation histories up to a specific date, the tool reports: "All patrons with checkouts older than 18/04/2015 have been anonymized" But... we are not anonymizing the patrons, but only their checkouts :) -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 15195] New: patron details should open in tab
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15195 Bug ID: 15195 Summary: patron details should open in tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 44888 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=44888&action=edit patron modifications When looking at patron modification requests the 'view record' link opens in a new tab, but the 'patron details' link doesn't. I'm not sure we need both links anyway, but if we have them both they should open in a new tab. Nicole -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 14968] New: found shouldn't be set to null when cancelling holds
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14968 Bug ID: 14968 Summary: found shouldn't be set to null when cancelling holds 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: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We want to provide statistics on canceled holds to know if they haven't been picked-up while waiting for the borrower or if the expiration_date on hold have been passed. But if we can see if a hold is waiting in found column of reserves table, this information disappeared from old_reserves table. Found shouldn't be set to Null when cancelling in order to keep this information in old_reserves. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 15434] New: Make search results breadcrumbs human readable
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15434 Bug ID: 15434 Summary: Make search results breadcrumbs human readable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: srdjan(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Humanise the breadcrumb text (or otherwise summarise what was searched for in a human readable format). The current formatting can lead to breadcrumbs such as Results of search for 'kw,wrdl: test 'with limit(s): 'holdingbranch:CPL su-to:Personality tests.' -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 8352] New: Add automatic printing of 'hold to pull' notices
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8352 Priority: P5 - low Change sponsored?: --- Bug ID: 8352 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Add automatic printing of 'hold to pull' notices Severity: enhancement Classification: Unclassified OS: All Reporter: kyle.m.hall(a)gmail.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Add the ability to have 'hold to pull' notices printed out automatically for librarians. These notices will be based on the data in the tmp_holdsqueue table. As each new row is added to tmp_holdsqueue, a notice for that given row is printed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 114

[Bug 6837] New: When AllowOnShelfHolds is OFF then holds on records with available items should not be possible
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6837 Bug #: 6837 Summary: When AllowOnShelfHolds is OFF then holds on records with available items should not be possible Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All URL: /cgi-bin/koha/opac-detail.pl?biblionumber=38132 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: axel.jacquin(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 2339 Created attachment 5285 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5285 Screenshot The error occurs in OPAC even though the following parameters are set: AllowOnShelfHolds is OFF OpacItemHolds is OFF RequestOnOPAC is ON When a title has two items, one is checked out, the other is available, then Koha allows the borrower to place a hold, which is then stored in Koha. This should not be possible, because one of the two items is still available on the shelf. -- 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 32

[Bug 14310] New: Add ability to suspend and resume individual holds from the patron holds table
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14310 Bug ID: 14310 Summary: Add ability to suspend and resume individual holds from the patron holds table Change sponsored?: --- Product: Koha Version: 3.18 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 64

[Bug 15544] New: Facets must be managed from the intranet
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15544 Bug ID: 15544 Summary: Facets must be managed from the intranet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: juan.sieira(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Add the ability to manage the facets from the intranet. Nowadays the facets are hardcoded. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 6979] New: LDAP authentication fails during password comparison
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '16

19 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6979 Bug #: 6979 Summary: LDAP authentication fails during password comparison Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: rfox2(a)nd.edu QAContact: koha-bugs(a)lists.koha-community.org Password is failing during comparison in Auth_with_ldap.pm in code (between lines 140 and 165) in this call: my $cmpmesg = $db->compare( $userldapentry, attr=>'userpassword', value => $password ); This was failing 100% of the time, even if a correct password was submitted with: "LDAP Auth rejected : invalid password for user ..." The attribute comparison is not always a valid way to check the password validity because not all LDAP databases support the userpassword attribute. Also, many LDAP databases require a valid DN string from the user as opposed to the uid for authentication purposes. I have a fix for this that does a recursive lookup of the user's DN in the LDAP database, and then uses that DN to perform a bind in a similar manner to the auth_by_bind method. The auth_by_bind method should also be changed so that it uses the retrieved DN of the user to perform a bind against the LDAP server. I plan on submitting a code revision for this and soliciting feedback. -- 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 18