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

[Bug 5522] New: The 'open in new window' setting should apply to google preview and ebook links
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5522 Summary: The 'open in new window' setting should apply to google preview and ebook links Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 It doesn't seem to be working at the moment. -- 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 8

[Bug 5143] New: Subtitles not showing on view_holdsqueue.pl
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5143 Summary: Subtitles not showing on view_holdsqueue.pl Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 see: http://screencast.com/t/OWE5NzMxZWMt Subtitles are not showing on the Holds Queue list, making it very time consuming for librarians to pick items that are in a series. The holds queue used to show the barcode of the item to be picked, making it eas(ier) for the librarian to find the right item to fill a hold. Without the subtitles AND without the barcode, they have to click through to each subtitled item to figure out which item to pull. I propose adding the subtitles into the holds queue list, and considering adding the specific item barcode back in as well (though there may be a reason not to do that). -- 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 34

[Bug 4942] New: When a new patron is created and the expiry date is left blank, it comes up with an invalid date
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4942 Summary: When a new patron is created and the expiry date is left blank, it comes up with an invalid date Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 To reproduce: 1. Create a new patron, leave the expiry date blank (which the text claims will auto calculate) 2. Note that the expiry date for the new patron is something like '00/02/0'. Expected result: 1. The expiry date will be a valid date. Note: * Need to decide on what a good default date is. -- 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 4826] New: Choose either 'new basket' or 'add basket'
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4826 Summary: Choose either 'new basket' or 'add basket' Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: cgi-bin/koha/acqui/booksellers.pl OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: oleonard(a)myacpl.org Estimated Hours: 0.0 Created attachment 2176 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2176 basket language On the list of vendors you see 'add basket' to the left of the vendor and 'new basket' at the top - the language should be consistent - either of those phrases - but not both. -- 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 9

[Bug 5556] New: OPAC does not display the type of authority
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5556 Summary: OPAC does not display the type of authority Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 When displaying the results of authority search in OPAC the column "Type of Heading" remains empty. At the bottom is my workaround (2 files need to be considered: opac-authorities-home.pl and opac-authoritiessearchresultlist.tmpl). Regards, Janusz --- ../koha-3.2.2/opac/opac-authorities-home.pl 2010-12-22 01:58:29.000000000 +0200 +++ /usr/share/koha/opac/cgi-bin/opac/opac-authorities-home.pl 2010-12-27 19:25:58.000000000 +0200 @@ -141,6 +141,7 @@ to => $to, numbers => \@numbers, authtypecode => $authtypecode, + authtypetext => $authtypes->{$authtypecode}{'authtypetext'}, isEDITORS => $authtypecode eq 'EDITORS', ); --- ../koha-3.2.2/koha-tmpl/opac-tmpl/prog/en/modules/opac-authoritiessearchresultlist.tmpl 2010-12-22 01:58:29.000000000 +0200 +++ opac-authoritiessearchresultlist.tmpl 2010-12-30 10:59:49.000000000 +0200 @@ -51,7 +51,7 @@ <td><a href="opac-authoritiesdetail.pl?authid="></a></td> <td> -  +  </td>  <td> -- 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 6

[Bug 5398] New: staff advanced search page list of item type limits does not obey noItemTypeImages
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5398 Summary: staff advanced search page list of item type limits does not obey noItemTypeImages Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The item type images are always displayed in the advanced search page in the staff interface regardless of the value of the noItemTypeImages system preference. The expected result is that the images should not be displayed if noItemTypeImages is off. -- 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 10

[Bug 5649] New: Change wording on review.tmpl from white/blacklists to approved/rejected
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '11

14 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5649 Summary: Change wording on review.tmpl from white/blacklists to approved/rejected Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: dschust1(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 In the US this is a ratial slur. -- 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 5271] New: Should be able to merge authority records from w/in Koha
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '11

13 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5271 Summary: Should be able to merge authority records from w/in Koha Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 When in the authority interface it would be nice if you could merge duplicate authority records together, keeping their links to bib records. -- 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 5376] New: Batch & Edit and Delete need Full Tools Permissions
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '11

08 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5376 Summary: Batch & Edit and Delete need Full Tools Permissions Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: batchMod.pl OS/Version: All Status: NEW Severity: major Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: brendan(a)bywatersolutions.com, ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 When anyone with simply batch edit or batch delete permissions tries to perform either of these actions they are told they don't have the right permissions. In batchMod.pl if $op isn't defined, then we get a wacky '*' for permissions which means either superlibrarian or full tools permissions (i'm not sure which). At one of the stages, the $op variable is not posted, so the permission go weird -- 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 8

[Bug 5477] New: Test cases requiring database access fail
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '11

08 Feb '11

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5477 Summary: Test cases requiring database access fail Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Test Suite AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In the 3.2.1 release there are a number of test cases that fail because they 'use' modules that immediately attempt to access the database. As most machines won't have MySQL set up to contain the user/password and database required, these fail. My suggestions for fixing this are: * Move these tests into a 'db_dependent' directory so that they aren't run by default. Perhaps add a 'make test_all' rule that includes them. * Have the packages move the iffy ones out of the way (although they will still fail for anyone running 'make test' without the database set up.) * Introduce an environment variable that is set during testing that tells C4::Context (or whatever it is making the DB connection) that failures are OK. This may reduce test coverage however, which we don't want. The tests I've noticed with this problem are: 00-load.t External_BakerTaylor.t Reports_Guided.t Service.t Tags.t UploadedFile.t VirtualShelves_Page.t -- 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 7