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

[Bug 7034] New: De-nesting C4::Branch
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '16

20 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7034 Bug #: 7034 Summary: De-nesting C4::Branch Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: paul.poulain(a)biblibre.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Blocks: 6875 Creating a specific bug report for this particular bit of cleanup. -- 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 4

[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 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

[Bug 7143] New: Bug for tracking changes to the about page
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '16

18 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7143 Bug #: 7143 Summary: Bug for tracking changes to the about page Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/about.pl OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: About AssignedTo: nengard(a)gmail.com ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org Bug for tracking changes to the about page (new release teams, new developers, companies, etc.) -- 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 513

[Bug 6322] New: It's possible to view lists/virtualshelves even when virtualshelves is off
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '16

15 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6322 Bug #: 6322 Summary: It's possible to view lists/virtualshelves even when virtualshelves is off Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Virtual Shelves AssignedTo: gmcharlt(a)gmail.com ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org In current head, setting the virtualshelves syspref to off removes the Lists "button" from the OPAC, but if you visit the URL of a list, you can still view it's contents. I would have expected to get a message like "this feature is currently turned off" or similar. -- 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 23

[Bug 6624] New: Allow Koha to use the new read API from OpenLibrary
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6624 Bug #: 6624 Summary: Allow Koha to use the new read API from OpenLibrary Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org http://openlibrary.org/dev/docs/api/read -- 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 14

[Bug 5334] New: add explicit foreign key constraints
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '16

14 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5334 Summary: add explicit foreign key constraints Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 There are many tables that lack explicit foreign key relationships to parent tables. For example: * serial (biblionumber, subscriptionid) * subscription (biblionumber) * subscriptionhistory (biblionumber, subscriptionid) * suggestions (suggestedby, managedby, rejectedby) * branch_transfer_limits (toBranch, fromBranch) and many, many others. Explicit foreign keys should be added for several reasons: * to promote better data integrity and to expose cases where the application code makes unwarranted assumptions about the database structure * to allow cascading updates and deletes in some cases * to make it easier for external reporting tools to correctly identify relationships between tables * to make use of an ORM more effective There are some arguments against this: * a complete set of FKs may decrease database speed (on the other hand, the Koha schema already uses a bunch of FKs) There are some implementation details to consider: * the database creation scripts may need some reordering * in some cases, a database update to add an FK may require dealing with rows that do not meet the new constraint. -- 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 12

[Bug 6657] New: Making 999 visible in framework duplicates 999 entry and affects index
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6657 Bug #: 6657 Summary: Making 999 visible in framework duplicates 999 entry and affects index Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com The 999 field is usually hidden in the frameworks; the 999$c is where Koha stores the biblionumber for the title. If someone edits the framework to make any field of the 999 visible, then any edit to any field of the MARC record results in a duplicate 999 with the biblionumber repeated. This can cause the record to appear twice in the zebra index, and can also make OPAC suppression not work. I have verified this behavior in current development head and several other versions. To replicate, export a title record and check its 999 field. There should only be one. For example: =999 \\$c219$d219 or <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> <subfield code="d">219</subfield> </datafield> Then edit the framework to make any field of the 999 visible, and edit that same record. Make any change to the title, such as adding a 5xx note. Export the record again and check the 999. There will now be two of them, repeating the biblionumber: =999 \\$c219$d219 =999 \\$c219 or <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> <subfield code="d">219</subfield> </datafield> <datafield tag="999" ind1=" " ind2=" "> <subfield code="c">219</subfield> </datafield> Changing the framework field back to hidden and forcing the MARC record back through zebraqueue does not fix the problem. The only fix we've found is to manually remove the extra 999 at the table level, then rebuild indexes. The first solution for the problem is to not set the 999 field as visible in any framework, but since you can't stop people from being adventurous, we also developed a code safeguard. It has not yet been backported from our current development head to the version in our public git repository; when it is, I'll add a link. In the meantime, here are the details of that commit. If the framework allows the biblionumber (999$c) field to be displayed and edited within the MARC editor, then this results in an additional 999$c value being added to the MARC record. This is because the code already pulled the biblionumber from the biblio table. This patch removes the addition of the extra 999$c field, although this field shouldn't really be editable in the first place. diff --git a/C4/Biblio.pm b/C4/Biblio.pm index 2e28f3f..3f61519 100644 --- a/C4/Biblio.pm +++ b/C4/Biblio.pm @@ -1858,13 +1858,13 @@ sub TransformHtmlToMarc { my $record = MARC::Record->new(); my $i=0; my @fields; + my ( $biblionumbertagfield, $biblionumbertagsubfield ) = + &GetMarcFromKohaField( "biblio.biblionumber", '' ); while ($params->[$i]){ # browse all CGI params my $param = $params->[$i]; my $newfield=0; # if we are on biblionumber, store it in the MARC::Record (it may not be in the edited fields) if ($param eq 'biblionumber') { - my ( $biblionumbertagfield, $biblionumbertagsubfield ) = - &GetMarcFromKohaField( "biblio.biblionumber", '' ); if ($biblionumbertagfield < 10) { $newfield = MARC::Field->new( $biblionumbertagfield, @@ -1903,6 +1903,12 @@ sub TransformHtmlToMarc { } else { while(defined $params->[$j] && $params->[$j] =~ /_code_/){ # browse all it's subfield my $inner_param = $params->[$j]; + my $biblionumbertagsubfield_string = "_code_" . $biblionumbertagsubfield . "_"; + if (($tag eq $biblionumbertagfield) && + ($inner_param =~ /$biblionumbertagsubfield_string/)) { + $j += 2; + next; + } if ($newfield){ -- 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 58

[Bug 5501] New: why is there a 'do not notify' option?
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '16

13 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 Summary: why is there a 'do not notify' option? Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons 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 Estimated Hours: 0.0 When looking at the enhanced messages for patrons there is a 'do not notify' option - which is basically the same as not checking any messaging choices - so why do we need that option at all? I recommend removing it since it's confusing. -- 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 16

[Bug 7065] New: reserves table needs a primary key
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '16

12 Jan '16

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7065 Bug #: 7065 Summary: reserves table needs a primary key Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5609 The reserves (and old_reserves) tables desperately need a primary key. reservernumber should be used for consistency sake. This will allow the possibility of multiple holds per biblio/patron combination, and a host of other improvements. This is included in bug 5872, but needs to be broken out into it's own enhancement for independent review. One cavaet: the values must be unique across the union of reserves and old_reserves. While this is easy enough to achieve in a new installation, adding the values into an existing install gets trickier. -- 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 50