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

[Bug 1618] Patron image upload succeeds silently
by bugzilla-daemon＠pippin.metavore.com 01 Feb '08

01 Feb '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1618 cnighswonger(a)foundations.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #1 from cnighswonger(a)foundations.edu 2008-01-31 15:17 ------- A patch has been submitted to correct the worst of the template errors. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1769] Error produced by Labels in Tools
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1769 cnighswonger(a)foundations.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cnighswonger(a)foundations.edu ------- Comment #1 from cnighswonger(a)foundations.edu 2008-01-31 12:02 ------- Which platform are you running? Maybe linux or fedora? If so, try manually installing Scalar::Util and using 'perl Makefile.PL -xs' then 'make,' 'make test,' 'make install' to see if that clears things up. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1810] New: News interface does not offer OPAC language choice
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1810 Summary: News interface does not offer OPAC language choice Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: Tools AssignedTo: chris.cormack(a)liblime.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)nongnu.org When creating or editing a news item, the only choic I have is 'Librarian Interface.' It should be offering 'en' as well, since that's my OPAC template language. Without 'en' as a choice I can't add news to the OPAC. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1809] Items editing page has to be scrolled horizontaly to edit items
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1809 ------- Comment #1 from frederic(a)tamil.fr 2008-01-31 04:47 ------- Created an attachment (id=166) --> (http://bugs.koha.org/cgi-bin/bugzilla/attachment.cgi?id=166&action=view) Item editing page screenshot ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1809] New: Items editing page has to be scrolled horizontaly to edit items
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1809 Summary: Items editing page has to be scrolled horizontaly to edit items Product: Koha Version: rel_3_0 Platform: All URL: http:///localhost/cgi- bin/koha/cataloguing/additem.pl?biblionumber=xxx OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Cataloging AssignedTo: galen.charlton(a)liblime.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)nongnu.org On item editing page, /cgi-bin/koha/cataloguing/additem.pl?biblionumber=xxx, multiple items are displayed in a table. This table has a lot of rows. And so, this table expands the page vertically requiring an horizontal scroll bar. You have to use this vertical scroll bar to click on edit or delete link. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1808] New: Holdings 'collection' displays diffent subfield in OPAC and Staff interface
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1808 Summary: Holdings 'collection' displays diffent subfield in OPAC and Staff interface Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: OPAC AssignedTo: jmf(a)liblime.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)nongnu.org In staff interface, /cgi-bin/koha/catalogue/detail.pl?biblionumber=xxx, in the Holdings section, 'collection' row displays data from item subfield: $c - Shelving location. But in OPAC interface, /cgi-bin/koha/opac-detail.pl?biblionumber=xxx, in the Holding section, 'collection' row displays data from item subfield:` $8 - Koha Collection. It's not clear me for what's the difference between this two fields. But both can't be displayed as 'Collection'. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1807] New: ':' character blocks search
by bugzilla-daemon＠pippin.metavore.com 31 Jan '08

31 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1807 Summary: ':' character blocks search Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: Searching AssignedTo: jmf(a)liblime.com ReportedBy: frederic(a)tamil.fr QAContact: koha-bugs(a)nongnu.org SEARCH RESULT black panthers Some biblio records black : panthers Nothing ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1774] New reserves do not go to end of list, but somewhere in middle
by bugzilla-daemon＠pippin.metavore.com 30 Jan '08

30 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1774 ------- Comment #5 from drdrulm(a)yahoo.com 2008-01-30 10:35 ------- Hello, I thought Ryan implied we were up to date. The bug is still there. Also, we do have the problem, when a specific item is put on hold, then no one else can request that specific item. This seems like a list of priority queues. http://en.wikipedia.org/wiki/Priority_queue Where each specific item has it's own priority queue. I need to think about an algorithm for this. I mean, if someone requests a specific copy and it is there you give it to them, but if someone else wants the same copy, then they would be at position 2, then 3 and so on. Each item would have a queue. One would ask themselves, how does one do this? Other ILSs seem to only allow patrons to request specific copies, and each ITEM has a queue. Of course it doesn't matter if the copies are alike. When the copies are different then we really need a queue on each item. Really that is the way it would work anyway. So how do we do this given there is a single numbered list. The way to do this, would be allow multiple position 1's, 2's, 3's etc. which reserves already does. When a reserve goes on, have some logic: if (! item level reserve) { This is *not* item level hold so... take MAX of all reserves FOR EACH ITEMNUM!! for this BIB add 1 -> new rank // say WIRED has 12 issues, and the latest 3 issues have 5 reserves each, // if a person then wanted ANY wired, they would be RANK 1 since there are // 9 other issues with NO holds. The SQL+Perl may be a bit tricky } else { This *is* an item level hold (easier!) take MAX of all reserves FOR *ONLY* THIS ITEMNUM, and add 1 -> new rank // so if we made a HOLD on the most recent WIRED magazine, it has 5 reserves // so we would be rank 6 for this item } The return algorithm is as strange, but still must look at the itemnumber Return() { Look at item coming in, decrease all ranks for BIB by 1 for *only* item-level holds for that item. After this, then take the MAX again of all item level holds, it may decrease or it may not! If it decreased (by 1) then subtract 1 from all general holds. If it did not decrease leave general hold ranks the same. The number would not decrease when an item was returned with a queue that was shorter than another item level queue. } This may sound complex, but thinking about this kind of thing is all I ever have done. My intuition with algorithms is pretty sound. Here is a reference in case you think the above is "nuts" http://citeseer.ist.psu.edu/cache/papers/cs/30321/http:zSzzSzwww.cs.kent.ed… So that should be the nuts and bolts of how to deal with an item level reserve without actually using lists of priority queues. Just let some SQL/perl logic deal with it. As for the other bug, it seems that MAX is not being computed correctly. 8) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1802] Cart link broken, script dependent and incorrect
by bugzilla-daemon＠pippin.metavore.com 30 Jan '08

30 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1802 oleonard(a)myacpl.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1806] perl Makefile.PL doesn't create a valid Makefile
by bugzilla-daemon＠pippin.metavore.com 30 Jan '08

30 Jan '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1806 ------- Comment #3 from frederic(a)tamil.fr 2008-01-29 23:01 ------- Thanks. I've sent the same patch! ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0