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

[Bug 2131] Enhanced Content - Multiple Choices
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2131 --- Comment #1 from Nicole C. Engard <nengard(a)gmail.com> 2009-08-25 16:43:15 --- Is this now possible? -- 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 2093] Add OPAC dashboard for logged-in users
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2093 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard(a)gmail.com --- Comment #2 from Nicole C. Engard <nengard(a)gmail.com> 2009-08-25 16:42:29 --- I love this!!! I say go for it ;) -- 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 1172] option to disable user details update via opac
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1172 --- Comment #4 from Nicole C. Engard <nengard(a)gmail.com> 2009-08-25 16:04:08 --- Created an attachment (id=1067) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1067) patch -- 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 1172] option to disable user details update via opac
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1172 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |PATCH-Sent -- 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 1172] option to disable user details update via opac
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1172 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nengard(a)gmail.com AssignedTo|joe.atzberger(a)liblime.com |nengard(a)gmail.com -- 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 3370] New: Add the support of a Get Method on biblio records
by bugzilla-daemon＠liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3370 Summary: Add the support of a Get Method on biblio records Product: Koha Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic data support AssignedTo: nahuel.angelinetti(a)biblibre.com ReportedBy: nahuel.angelinetti(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- This method should be based on a table like koha2marc mapping, but should map a "keyword" to "MARC field". This is a big enhancement, to the "generic" supporte of fields. Like when we want to retrieve "subtitle" we would do: C4::Biblio::Get('subtitle',$record); This will see in the mapping table for the keyword and record framework which field is attached. Like in unimarc we will find for "subtitle" keyword the field 200$e, so the function will return an array of strings. -- 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 4

[Bug 3549] New: Framework sorting in addbook
by bugzilla-daemon＠kohaorg.ec2.liblime.com 25 Aug '09

25 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3549 Summary: Framework sorting in addbook Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: jeanandre.santoni(a)biblibre.com ReportedBy: jeanandre.santoni(a)biblibre.com Estimated Hours: 0.0 Change sponsored?: --- In addbook.pl, the framwork options are sorted in random order. They should be sorted in alphabetical order of value or code. -- 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 3548] New: Incorrect directory/file ownership on /var/run/lock/koha
by bugzilla-daemon＠kohaorg.ec2.liblime.com 24 Aug '09

24 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3548 Summary: Incorrect directory/file ownership on /var/run/lock/koha Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux - Debian Status: NEW Severity: major Priority: P5 Component: Installation (command-line installer) AssignedTo: gmcharlt(a)gmail.com ReportedBy: cnighswonger(a)foundations.edu Estimated Hours: 0.0 Change sponsored?: --- After a regular install of koha on Debian (any) /var/run/lock/koha is owned by root:root rather than the koha user. This causes zebra many problems when attempting to index/reindex. -- 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 3288] New: Transit prompt not immediately triggered after hold is canceled
by bugzilla-daemon＠liblime.com 24 Aug '09

24 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3288 Summary: Transit prompt not immediately triggered after hold is canceled Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Mickey says: Canceling the 'hold over' from waitingreserves.pl should trigger a transit prompt, instructing the staff person to send the item on to the hold library, if a hold exists on the item. This doesn't happen. Nothing happens when the 'hold over' is canceled. A staff person, seeing the information displayed in the ACTION column, would naturally assume that the item is to return to its home library. So, regardless of whether a hold exists, the 'hold over' canceled item is being returned home. We have found that a hold transit prompt will trigger if the canceled hold item is checked in after it is canceled. But this is a two-step process that we have not trained any of our libraries to perform. We are seeing lots of problems associated with this, since many hold items are being sent back to their home locations, instead of their next hold location Galen says: The script does appear to have nascent but incomplete functionality to generate a transfer message. I recommend filing a bug for this one. -- 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 4

[Bug 3287] New: Cancel Hold script makes unjustified assumption of Home Library return
by bugzilla-daemon＠liblime.com 24 Aug '09

24 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3287 Summary: Cancel Hold script makes unjustified assumption of Home Library return Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Mickey says: The location displayed in the ACTION column when canceling a 'hold over'item is the item's home library; but often, there is a hold on the item for another library (not the home library). It is the next library in the holds queue that should display in this column, rather than the item home location. Galen says: Right, the script currently makes an unjustified assumption that the item should always be transferred back to its home library. While it would be possible for the script to figure out the next request in the queue, holds queue are dynamic enough that it is possible for the next request to fill to change between generating the report and the operator canceling a request. Consequently, a simple message of 'Cancel hold' or 'Cancel hold and transfer' may be better. Please file a bug for this. -- 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