May 2008 - Koha-bugs - lists.koha-community.org

[Bug 2045] Network Printers Setting Does Nothing?
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2045 joe.atzberger(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |rel_3_0 ------- Comment #4 from joe.atzberger(a)liblime.com 2008-05-31 01:09 ------- I'm with Ryan on this one. We should hide it or suffer. We see multiple label/barcode/slip printing questions from clients every week, and users have no idea what the relationship between Koha and their printer is. They say "hey I have an HP 3160n, the 'n' is for 'network'" and conclude that this "network printer" setting is going to let them target it. You can't really document how to setup every kind of printer on arbitrary hardware, in an unspecified network environment, on an unknown OS. (Then: middleware, drivers, queues, firewalls, trays, etc.) I've been looking at this code for 45 minutes, and I am positive it cannot work for anyone. It all comes down to C4::Print::remoteprint that starts: sub remoteprint ($$) { my ($items, $borrower) = @_; (return) unless ( C4::Context->boolean_preference('printcirculationslips') ); my $queue = ''; # FIXME - If 'queue' is undefined or empty, then presumably it should # mean "use the default queue", whatever the default is. Presumably # the default depends on the physical location of the machine. # FIXME - Perhaps "print to file" should be a supported option. Just # set the queue to "file" (or " file", if real queues aren't allowed # to have spaces in them). Or perhaps if $queue eq "" and # $env->{file} ne "", then that should mean "print to $env->{file}". if ( $queue eq "" || $queue eq 'nulllp' ) { open( PRINTER, ">/tmp/kohaiss" ); } [..snip..] Well, after a lot of deliberation there, the coders ended up with: my $queue = ''; if ($queue eq "" ... Since that's *always* true, no matter how many printers are defined, or how many Koha's live on the same box, the best they will do is all print to the same /tmp file. Also printreserve has the same defects. But wait, it gets better. Here's the content of that file: atz@arwen:~/koha/production/koha$ cat /tmp/kohaiss Horowhenua Library Trust Phone: 368-1953 Fax: 367-9218 Email: renewals(a)library.org.nz 23529001000463 Acosta 0 Coping with venereal disease / 502326000056 00/02/0 =================================== Hardcoded HLT, mangled date handling, etc. So the code as is can't work for anybody, even HLT, since it doesn't actually send to printer. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2063] Windows: Can't add patron or organization members
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2063 joe.atzberger(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|other |Windows 2000 ------- Comment #1 from joe.atzberger(a)liblime.com 2008-05-30 23:20 ------- The Koha INTRANET (staff) error log is the one that would be useful. The regular Apache log tells us nothing about Koha. Please review your logs for activity related to the memberentry.pl and post back. --joe ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2073] Tag cloud doesn't seem to work at all
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2073 joe.atzberger(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2073] Tag cloud doesn't seem to work at all
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2073 joe.atzberger(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jmf(a)liblime.com |joe.atzberger(a)liblime.com Severity|critical |minor Priority|P3 |PATCH-Sent ------- Comment #6 from joe.atzberger(a)liblime.com 2008-05-30 23:10 ------- This is just an expectations problem with little to no technical dimension. I reworked the template to actually check if the syspref is enabled (instead of relying on the link in masthead to disappear). I also added some explanation for the case where OpacCloud is enabled, but no hits are found. This should resolve any outstanding confusion regarding this feature (though I'd be glad to take the term "Tag Cloud" for linking to the cloud of users' tags). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2000] separation of issuing & fines rules breaks defaults propagation
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2000 ------- Comment #4 from rch(a)liblime.com 2008-05-30 22:31 ------- Actually, this reveals a further issue with Paul's recent patch: http://lists.koha.org/pipermail/koha-patches/2008-May/000585.html Here we are using '*' in the branch and categorycode columns of the issuingrules table to mean 'default', but it means 'total' for itemtypes. But that is meaningless for fines, so a single entry in the issuingrules table then means 'total' for maxissueqty, but 'default' for fines columns. Thus, relabelling 'Any' to 'Total' in smartrules.pl for itemtype (as I suggest in http://lists.koha.org/pipermail/koha-patches/2008-May/000619.html ) Will not work. I think we need to add a 'default' for itemtype, which should be '*' in issuingrules table (i.e., don't push Paul's patch), and if we want to enforce a 'total', we need to test against another character, say '~' or '+' for a rule indicating total (only applicable to itemtype). I think it would be easier to code that than to write the documentation to explain the differences in issuingrules.pl and smartrules.pl and how 'Any' means one thing for maxissueqty but another thing for fines settings. If that is done, then I think it's sufficient to simply say 'use smartrules if you charge fines, if not, you can use issuingrules.pl', so there's no need to test for fines use. (In reply to comment #3) > The question is how to determine that a system is using fines or not. > Hopefully we don't need a syspref, and can just take the full-population of any > fines line as proof enough? > ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2000] separation of issuing & fines rules breaks defaults propagation
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2000 ------- Comment #3 from joe.atzberger(a)liblime.com 2008-05-30 19:45 ------- The question is how to determine that a system is using fines or not. Hopefully we don't need a syspref, and can just take the full-population of any fines line as proof enough? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1825] Hold awaiting pickup seems incorrect.
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1825 joe.atzberger(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmf(a)liblime.com ------- Comment #2 from joe.atzberger(a)liblime.com 2008-05-30 19:41 ------- Josh, can you attach the PHP? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2180] Check out disabled for some reason
by bugzilla-daemon＠pippin.metavore.com 31 May '08

31 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2180 nicole.engard(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal ------- Comment #7 from nicole.engard(a)liblime.com 2008-05-30 16:28 ------- I think you can close it if you show a warning like this - it might be even better if you link to the sys preference related to this. I'll make sure to document this in the manual in several places - but that may not be enough. Thanks so much for looking into it - I looked through all circ sys preferences and didn't see one I thought would cause this. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2182] Overdue Items list dates in European format
by bugzilla-daemon＠pippin.metavore.com 30 May '08

30 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2182 ------- Comment #6 from rch(a)liblime.com 2008-05-30 14:02 ------- accountlines should refer to a PK in one of several possible tables, though primarily either issues/old_issues or items, since the fine may be for a damaged/lost item or for an issue, or could be a checkout charge or a reserve fee. Unfortunately we don't have pks on some of these tables. I would prefer to hold off on 'fixing' this, and instead redesign fines management so that charges and payments can be reliably associated with the relevant issues, reserves or items. fines-ll.pl, btw, uses us dates format, also hardcoded. (In reply to comment #5) > This bug is caused by the fines scripts (fines2.pl, fines-ll.pl, and > fines-sanop.pl), each of which gets the due date, converts it to the European > date format without using C4::Dates and the the dateformat syspref, and stores > it (via UpdateFines) in accountlines.description. > > A fix would be straightforward - using C4::Dates to format the date before > storing it. However, there is one fly in the ointment - UpdateFines does a > query on accountlines to determine whether an existing overdue fine exists, and > that query includes the text of the due date from accountlines.description!!! > That means that the naive correction to the bug can break updates of overdue > fines that exist prior to the fix, since "05/09/08" would not match "09/05/08". > :( > > A better fix will have to include doing something better than relying on > specially formatted strings in accountlines.description to match an overdue > fine to the loan that inspired it. What this fix entails (it may involve > adding an explicit link between accountlines and isues) is not specified yet. > > Reassigning this bug to Andy since he's looking at the relevant fine jobs soon. > ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2048] Kohazebraqueue daemon MAJOR issue
by bugzilla-daemon＠pippin.metavore.com 30 May '08

30 May '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2048 ------- Comment #6 from galen.charlton(a)liblime.com 2008-05-30 14:01 ------- The patch to fix this bug has been pushed. Henri-Damien, please test and advise if bug can be closed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0