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

[Bug 3230] New: Automatic Credit when Lost item is returned
by bugzilla-daemon＠liblime.com 14 Sep '09

14 Sep '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3230 Summary: Automatic Credit when Lost item is returned Product: Koha Version: unspecified Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: dschust1(a)gmail.com Estimated Hours: 0.0 Change sponsored?: Seeking cosponsors 1 - When a lost item is found and returned the system doesn't alert the person checking in the item. 2 - nor does it provide a credit to the original person that has paid for the item. Plano ISD would like to see this functionality added to Koha and is seeking co-sponsors or those that may already have this under development. -- 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 12

[Bug 3227] New: Branch transfer limits builds display hash inefficiently, not suitable for consortia
by bugzilla-daemon＠liblime.com 14 Sep '09

14 Sep '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3227 Summary: Branch transfer limits builds display hash inefficiently, not suitable for consortia Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P3 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: rch(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- Timeouts are likely to occur when loading admin/branch_transfer_limits.pl if a Koha system has a large number of branches and itemtype / ccodes defined. This is due to a three level nested loop used to build the display data structure. For larger data sets, a more efficient method needs to be implemented, e.g. C4::GetBranchTransferLimits could build the whole structure rather than calling IsBranchTransferAllowed num_branches^2 * num_ccodes times (18,000 times for 30 branches & 20 ccodes). -- 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 1

[Bug 3332] New: Edit whole category of patrons
by bugzilla-daemon＠liblime.com 07 Sep '09

07 Sep '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3332 Summary: Edit whole category of patrons Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Patrons AssignedTo: mjr(a)ttllp.co.uk ReportedBy: mjr(a)ttllp.co.uk Estimated Hours: 0.0 Change sponsored?: Sponsored Libraries with some patrons that subscribe as a group need to have their dateexpiry or other attributes updated all at once. It's possible but fiddly to do this from the database command-line. I will add an interface to do this from the staff admin. It will probably be accessed from Administration: Patron Categories and require both parameters (from Patron Categories) and borrowers (from Patrons) permissions. Comments welcomed, at least until we start coding. -- 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 8

[Bug 3180] New: Active settings for label settings and templates should be a library level preference
by bugzilla-daemon＠liblime.com 02 Sep '09

02 Sep '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3180 Summary: Active settings for label settings and templates should be a library level preference Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Label printing AssignedTo: mason.james(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Active settings for label settings and templates should be a library level preference, not a global setting. In multi-branch/multi library settings this can cause interference when two libraries who are not in communication are using different settings and printing labels at the same time. -- 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 8

[Bug 3298] New: Separate item "Status Check" functionality needed
by bugzilla-daemon＠liblime.com 26 Aug '09

26 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3298 Summary: Separate item "Status Check" functionality needed Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Koha needs a separate Status Check functionality that is entirely separate from "Check In." Check In triggers transfers and other situationally undesirable behavior when the user is simply trying to determine the current status (checked out? on hold? in transit?) of an item. Checking In an item more than once also has undesirable ramifications in some situations. A separate Status Check function would resolve these issues. -- 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 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 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

[Bug 3409] New: returns does'nt take care of CircControl and HomeOrHoldingBranch
by bugzilla-daemon＠liblime.com 23 Aug '09

23 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3409 Summary: returns does'nt take care of CircControl and HomeOrHoldingBranch 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?: --- For the moment only a really poor rule is used in returns script. It should use CircControl syspref, and HomeOrHoldingBranch to check if some transfert is needed. -- 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 1

[Bug 3224] New: inventory tool does not accept dos newlines
by bugzilla-daemon＠liblime.com 20 Aug '09

20 Aug '09

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3224 Summary: inventory tool does not accept dos newlines Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Tools AssignedTo: rch(a)liblime.com ReportedBy: rch(a)liblime.com CC: maria.laude(a)liblime.com Estimated Hours: 0.0 Change sponsored?: --- Some Windows-generated barcode files may fail to load due to incompatible line endings. Also, an incorrect sql query fills the logs looking for issues.wthdrawn instead of items.wthdrawn, though this doesn't really break anything. Lastly, the script tests for an $item return from GetItem. In the case of a dos-newline file, GetItem returns a (mostly) empty hash, not undef, so the script incorrectly reports success. -- 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