December 2009 - Koha-bugs - lists.koha-community.org

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

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

[Bug 3801] New: Cannot add item type, due to renewalsallowed deletion
by bugzilla-daemon＠kohaorg.ec2.liblime.com 19 Feb '10

19 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3801 Summary: Cannot add item type, due to renewalsallowed deletion Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- Some forgotten code is still 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 2

[Bug 3980] New: Vendor GST being ignored
by bugzilla-daemon＠kohaorg.ec2.liblime.com 19 Feb '10

19 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3980 Summary: Vendor GST being ignored Product: Koha Version: HEAD Platform: PC URL: cgi-bin/koha/acqui/basket.pl?basketno=8 OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- I have gist sys pref set to .09 and I have my vendor's GST set to 12% -- but the order is using the value from the sys pref and ignoring the vendor value. I would think that the sys pref should be the default -but should be overridden by the vendor value if one exists. If you can't have both set then we should make it so that you can't set a vendor gst if there is a sys pref value set. -- 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 3242] New: emailLibrarianWhenHoldIsPlaced system preference is non-functional
by bugzilla-daemon＠liblime.com 19 Feb '10

19 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3242 Summary: emailLibrarianWhenHoldIsPlaced system preference is non- functional Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: galen.charlton(a)liblime.com ReportedBy: rch(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- This feature was not implemented in 3.0. If no one steps up to implement it using the new messaging code, the system preference should be removed from Koha. Koha cannot currently generate an email to staff when a hold is placed. -- 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 15

[Bug 3825] New: Waiting reserves too big
by bugzilla-daemon＠kohaorg.ec2.liblime.com 18 Feb '10

18 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3825 Summary: Waiting reserves too big Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- The waitingreserves page is too big for big libraries networks. This page should only show "local" reserves, and use tabs to differentiate holds that are over, and waiting holds. -- 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 2

[Bug 3651] New: sending shelves and baskets
by bugzilla-daemon＠kohaorg.ec2.liblime.com 18 Feb '10

18 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3651 Summary: sending shelves and baskets Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- Atm, sending shelves and baskets via OPAC can be used to SPAM or spoof the kohaadminemailaddress, it's really bad. Only logged in user must be able to send shelves and baskets, and their name must appear in the sent email. -- 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 3229] New: The "Sort By" feature for lists does not work
by bugzilla-daemon＠liblime.com 17 Feb '10

17 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3229 Summary: The "Sort By" feature for lists does not work Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Virtual Shelves AssignedTo: jmf(a)liblime.com ReportedBy: debra.denault(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- There is the ability to define how lists sort, by title or author, using the "Sort By" feature. It does not currently seem to work (i.e. sort by title or author). -- 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 16

[Bug 3775] New: Accounts::chargelostitem uses title, but title not available to it
by bugzilla-daemon＠kohaorg.ec2.liblime.com 17 Feb '10

17 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3775 Summary: Accounts::chargelostitem uses title, but title not available to it Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: normal Priority: PATCH-Sent Component: Command-line Utilities AssignedTo: dbavousett(a)ptfs.com ReportedBy: dbavousett(a)ptfs.com Estimated Hours: 0.0 Change sponsored?: --- Every item selected by longoverdue.pl results in an error of the form: Use of uninitialized value in concatenation (.) or string at /home/ebpl/kohaclone/C4/Accounts.pm line <foo> The INSERT at this point is attempting to create a new fine, and is trying to concat in the title from the hashref loop from the selection earlier in the routine. Since titles is not in either issues or items, it is an uninitialized value at this spot. This patch backs up and includes biblio.title to resolve this problem. -- 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