February 2010 - Koha-bugs - lists.koha-community.org

[Bug 1819] deletion of a holiday may not work in some browsers
by bugzilla-daemon＠kohaorg.ec2.liblime.com 22 Feb '10

22 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1819 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> 2010-02-22 13:52:04 --- Please re-open this bug if the behavior can be reproduced and documented. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4226] New: bulkmarcimport.pl doesn't replace 001 when keepids is not specified
by bugzilla-daemon＠kohaorg.ec2.liblime.com 22 Feb '10

22 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4226 Summary: bulkmarcimport.pl doesn't replace 001 when keepids is not specified Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Command-line Utilities AssignedTo: gmcharlt(a)gmail.com ReportedBy: brian(a)jhu.edu Estimated Hours: 0.0 Change sponsored?: --- When loading authorities, bulkmarcimport should replace the value in 001 with the Koha authid. If you use keepids, the 001 is deleted and replaced. Without keepids, the script attempts to reuse the 001 as the Koha authid. I'm submitting a patch which checks the 003 of MARC21 records and doesn't attempt to use the authid of the record unless it matches the MARCOrgCode, since you probably shouldn't re-use authids that aren't from your system. I wasn't able to find a UNIMARC equivalent to check. It seems to me that the whole attempt to re-use the 001 as the authid should simply be deleted, since it ends up attempting to insert it into an auto_increment field in the DB. Is there something I'm missing here? -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3344] New: Hold priority list needs additional status for items assigned but not waiting
by bugzilla-daemon＠liblime.com 22 Feb '10

22 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3344 Summary: Hold priority list needs additional status for items assigned but not waiting Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: galen.charlton(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- When looking at the existing holds priority list (reserve/request.pl) the priority dropdown should show assigned/in transit statuses and priority should be rearranged when items change status (like waiting status does). See screenshot: http://www.screencast.com/users/lizrea/folders/Jing/media/b6425793-f994-4ee… We don't think it's enough that the pick up library column (kind of) shows the status of the item. Discussion welcome. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2

[Bug 2655] Items waiting on the hold shelf display as "Available" in OPAC
by bugzilla-daemon＠kohaorg.ec2.liblime.com 22 Feb '10

22 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2655 --- Comment #17 from Galen Charlton <gmcharlt(a)gmail.com> 2010-02-22 01:26:11 --- Pushed patches from Garry Collumn to HEAD. Please test. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4016] New: holds listing wrong pick up location
by bugzilla-daemon＠kohaorg.ec2.liblime.com 22 Feb '10

22 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4016 Summary: holds listing wrong pick up location Product: Koha Version: HEAD Platform: PC URL: cgi-bin/koha/reserve/request.pl?biblionumber=1 OS/Version: All Status: NEW Severity: blocker Priority: P5 Component: Circulation AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- Created an attachment (id=1444) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1444) holds list See attached. On the list of holds for a bib record all items say they are being picked up at the first library on the list - even though they each had a different library selected when I put the holds on the items. This does not appear to be just a display problem either. When checking in an item that is on hold it is asking to be transferred to the library shown on this list - not the library I selected when placing the hold in the first place. Assigning Blocker Status since it's impossible to have a patron pick up a hold at a library other than the first one listed - seems like a big deal to me ;) -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 13

[Bug 2655] Items waiting on the hold shelf display as "Available" in OPAC
by bugzilla-daemon＠kohaorg.ec2.liblime.com 21 Feb '10

21 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2655 --- Comment #16 from Garry Collum <gcollum(a)gmail.com> 2010-02-21 01:14:49 --- Created an attachment (id=1653) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1653) Propose patch. Follow-up patch. - Fixes opac (no xsl) and intranet. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4227] New: opac-logout.pl is no longer used.
by bugzilla-daemon＠kohaorg.ec2.liblime.com 21 Feb '10

21 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4227 Summary: opac-logout.pl is no longer used. Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: PATCH-Sent Component: OPAC AssignedTo: gcollum(a)gmail.com ReportedBy: gcollum(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- Could not find references to this file in the current opac. Performed a recursive grep on the entire file structure. Just in case. Not found. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 2655] Items waiting on the hold shelf display as "Available" in OPAC
by bugzilla-daemon＠kohaorg.ec2.liblime.com 21 Feb '10

21 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2655 --- Comment #15 from Garry Collum <gcollum(a)gmail.com> 2010-02-21 00:09:29 --- Created an attachment (id=1652) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1652) Propose patch. Fixes opac results if data transformed thru xsl. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3609] New: updatedatabase from 3.0.x, new acq permissions
by bugzilla-daemon＠kohaorg.ec2.liblime.com 20 Feb '10

20 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3609 Summary: updatedatabase from 3.0.x, new acq permissions Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: blocker Priority: P5 Component: Acquisitions AssignedTo: rch(a)liblime.com ReportedBy: paul.poulain(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- The updatedatabase don't add specific (granular) acquisition permissions -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 3382] New: Need a way to suppress the call number display in OPAC search results
by bugzilla-daemon＠liblime.com 19 Feb '10

19 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3382 Summary: Need a way to suppress the call number display in OPAC search results Product: Koha Version: rel_3_0 Platform: PC URL: http://catalog.nexpresslibrary.org/cgi-bin/koha/opac- search.pl?q=metro+girl OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: smoreland(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- We would like the ability to customize what displays in the OPAC search results, specifically, we would like to suppress the call number. The LC call number displayed comes from the 050 of the Bib, which confuses our patrons. Discussion from #koha on July 1, 2009: [1:14pm] Sharon: Owen - do you all 'hide' the call number display in the OPAC, especially when it shows the LC call number from the Bib? (Call Number: PS3555.V2126 M48 2004 ) [1:14pm] owen: Can you show me an example? [1:15pm] Sharon: http://catalog.nexpresslibrary.org/cgi-bin/koha/opac-search.pl?q=metro+girl - 3rd record down [1:16pm] owen: Well, editing your XSL stylesheet is the obvious answer...not the greatest answer if you don't have access to those files [1:16pm] atz: if it is in an identifiable <span>, then you can use custom CSS [1:17pm] owen: That's the trouble atz, it isn't. [1:17pm] atz: it's a fairly easy enhancement to produce [1:17pm] owen: Which raises the question: should every line that comes out of the XSLT display have a unique ID for this purpose? [1:18pm] atz: owen: yeah, i think that should be a general guideline [1:18pm] gmcharlt: owen: class names, at least [1:18pm] gmcharlt: owen: unique IDs would be nice, as long as uniqueness was guaranteed [1:18pm] owen: It'd have to be class names for the search results screen [1:19pm] owen: I just hate to see the XSL option being used but the flexibility of it not being able to be tapped. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5