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

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '12

14 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 --- Comment #18 from Kyle M Hall <kyle.m.hall(a)gmail.com> 2012-02-14 14:37:33 UTC --- (In reply to comment #17) I was actually thinking a new table using only patron category and branch would be the ideal solution. I was hoping to fix it without removing holdsallowed from the issuingrules table, but I think that approach is just untenable at this point. I should be able to create the new table/columns and import the issuingrules.holdsallowed where possible. -- 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. You are watching all bug changes.

1 0

[Bug 5461] New: Cannot set Issuing Rules
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '12

14 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5461 Summary: Cannot set Issuing Rules Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: costas.magnuse(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 Created attachment 2795 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2795 video demonstrating the problem Dear koha friends and developerss, going to More > Administration > (Patrons and circulation) Circulation and fines rules I vist the http://koha.library:8080/cgi-bin/koha/admin/smart-rules.pl (the Defining default issuing rules page) but I cannot set any rules, as the http://dl.dropbox.com/u/6526828/2noteverdelete/default-issuing-rules-proble… demonstrates. The same happens: * after setting the library of the koha user (upper right corner) and * after Selecting a library in the middle of the page Koha was installed in this system 2 years ago, when the original issuing rules were properly set. During these years there were made various upgrades, without changing any rules, so I cannot determine if these upgrade are responsible for the problem... Could you please help me with this? If not, could you please tell me what exactly should I do to the database in Order to set Patron Category: Student Item Type: Books Fine Amount: 1 Fine Days: 2 Fine Grace Period: 3 Fine Charging Interval: 4 Current Checkouts Allowed: 6 Loan Period: 7 ?? Thank you very much in advance,... :) Constantine Tsardounis http://www.costis.name PS: Koha version: 3.02.00.004 OS version ('uname -a'): Linux [...] 2.6.32-5-686 #1 SMP Sat Oct 30 22:47:19 UTC 2010 i686 GNU/Linux Perl interpreter: /usr/bin/perl Perl version: 5.010001 Perl @INC: /usr/share/koha/lib /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 . MySQL version: mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (i486) using readline 6.1 Apache version: Server version: Apache/2.2.16 (Debian) Zebra version: -- 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 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '12

14 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> 2012-02-14 14:19:40 UTC --- Hi Kyle, I can only suspect that not a lof of people have used it, because they didn't trust it to work. I think things are even a bit more complicated here: We have an itemtype on biblio level, but I think it should only be checked for holds, when the system preference item-level_itypes is set to biblio record. So in that case it can work correctly for biblio level holds, because all items on the record are of the same item type. So both item level and biblio level hold will work here. When you use item level itemtypes, things get a lot more complicated. I started testing the patch that moves AllowOnShelfHolds to issuingrules and the problems here are similar I think. We allow a biblio level hold, if at least one of the items can be put on hold for the patron. If he missed items on the shelf and the library doesn't offer to get those items for the patrons, it will mean the patron has to wait longer, but the hold will still be filled at some point (If I didn't miss something here, and I feel like I did). If we follow the same approach for maxreserves it means that as long as at least one item is 'holdable' for the patron, it will be possible to place an item level hold on that item and a biblio level hold on the record. The problem with 3) is, that at the time the item will be checked in, the conditions can have changed totally. The numbers of holds for that patron might look totally different at the time one item is returned. While it was holdable when the patron placed the hold, it might no longer be holdable when it's returnd (and the other way round). Holds may have been filled in the meantime and other holds placed or cancelled. For this I think we can't really check on return - we must determine when placing the hold and then it's ok or not. Perhaps for use with item level itypes the current approach is too granular? I am thinking about a solution similar to "Total Current Checkouts Allowed". That would mean combinations of branch and patron category. And make the branch be the branch specified in ReservesControlBranch. I think that could work, but I might be wrong and missing some major things. Hope that makes sense. -- 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. You are watching all bug changes.

1 0

[Bug 4045] No check for maximum number of allowed holds.
by bugzilla-daemon＠bugs.koha-community.org 14 Feb '12

14 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045 --- Comment #16 from Kyle M Hall <kyle.m.hall(a)gmail.com> 2012-02-14 12:52:01 UTC --- I've been looking at the code, and there seems to be a fundamental flaw with having having the the maximum reserves in the issuingrules table. Issuing rules are defined by a combination of Branch Code, Patron Category, and Item Type. The problem is the item type. Most holds are placed at a bibliographic level, and bibs in and of themselves, have no item type. Each bib can have attached items of multiple item types. Furthermore, there was also a new system pref added, ReservesControlBranch, which is supposed to define whether to use the patron's home library or the item's home library, again, there can be multiple items each with a different home library attached to a bib. So, unless all item's attached to a bib are not hold-able based on the issuing rules, we cannot disallow a bib level hold to be placed on the record. Of Note: It does appear that the smart rules correctly disallows the placing of item level holds, but does nothing for bib level holds. Even if all the items on a record disallow item level holds, if a borrower has a bib level hold on the record, and one of those items is returned, Koha will try to use it to fulfill the hold ( even though it was specifically not hold-able ). I am reticent to remove issuingrules.holdsallowed, as that would be going backwards, not forwards. Removing this would probably cause serious problems for any library that has been using it. Here is the best solution I can come up with: 1) Re-add maxreserves ( renamed to MaxReserves ) to updatadatabase.pl 2) Use the hybrid approach that was previously decided against. Really, there should be a way to define a maximum total number of holds, even if there is a specific holds limit for a given Library/Patron/Item Type combination. 3) When an item was returned, and is about to fill a hold for a borrower, check to see if that item was specifically hold-able for that person or not. If not, either skip trying to use it to fulfill a hold, or keep going down the list of people with holds for that bib until we find one that could have put an item level hold on it, or until there is no one left. The commit for this was added on Aug 24, 2009, in commit 3c741d2376e939dea0554a05eddd4f9e9b2d9449. It's amazing that this went unreported for a year, and went three years without a solution. -- 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. You are watching all bug changes.

1 0

circulation bug
by alaa Badri 14 Feb '12

14 Feb '12

Dear All I re install my system and restore data base but now i facing this bug http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=1794 Do you have any solution for this bug , i'm waiting for your response

1 0

[Bug 3754] Language detection doesn't take really care of syspref
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '12

13 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3754 Chris Cormack <chris(a)bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical --- Comment #4 from Chris Cormack <chris(a)bigballofwax.co.nz> 2012-02-13 20:42:47 UTC --- This is still a major problem -- 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. You are watching all bug changes.

1 0

[Bug 7393] New: Date::ICal deprecated, suggested replacement by DateTime::Format::ICal
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '12

13 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7393 Bug #: 7393 Summary: Date::ICal deprecated, suggested replacement by DateTime::Format::ICal Classification: Unclassified Change sponsored?: Seeking cosponsors Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: mjr(a)ttllp.co.uk ReportedBy: mjr(a)ttllp.co.uk QAContact: ian.walls(a)bywatersolutions.com See http://bugs.debian.org/653301 - Koha should switch too. This will become more important as the removal spreads to more distributions. On Mon, 26 Dec 2011 17:07:26 +0100, gregor herrmann wrote: > I suggest to remove libdate-ical-perl from the archive. > > Upstream writes (in Changes) that people should be using DateTime > modules nowadays, and he's just fixing occasional bugs. > > It has no build or runtime reverse dependencies (apart from a > spurious Suggests in libtest-class-perl in oldstable). > > libdatetime-format-ical-perl exists as a nice replacement (I've > switched a script yesterday from Date::ICal to DateTime::Format::ICal > yesterday after stumbling over a design flaw in the former). -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 4042] Public OPAC search can fall prey to web crawlers
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '12

13 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4042 Fred P <fred.pierre(a)smfpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fred.pierre(a)smfpl.org --- Comment #1 from Fred P <fred.pierre(a)smfpl.org> 2012-02-13 15:46:58 UTC --- Very cool. We were experiencing slow-downs related to Google searches. Much of our catalog was visible on Google, by searching the library name and book title. We used robots.txt to effectively block googlebots. However Baidu spiderbots from China continue to plague us from time to time. Using the robots.txt helped, but did not completely solve the problem, although it seems to have decreased the frequency. We also get hit with port scans through the koha-tmpl directory (maps to root?), although our security seems to be strong enough to resist those. A system preference option would help us. Thanks for your hard work! -- 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. You are watching all bug changes.

1 0

[Bug 7293] New: new fields in vendor table
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '12

13 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7293 Bug #: 7293 Summary: new fields in vendor table Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: claire.hernandez(a)biblibre.com ReportedBy: claire.hernandez(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7163 Add 2 fields to the vendor : vendor internal number (our number at the vendor), and delay to recieve order. Estimate recieving date will be displayed in various places (BibLibre 5850) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 3652] XSS vulnerabilities
by bugzilla-daemon＠bugs.koha-community.org 13 Feb '12

13 Feb '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3652 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0