October 2007 - Koha-bugs - lists.koha-community.org

[Bug 284] We should not be able to delete or cancel an order if a reserve is
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=284 ------- Comment #5 from jmf(a)liblime.com 2007-10-06 00:02 ------- The original bug was complaining that upon deletion of an order, a patron's hold remains as does the biblio record. So it sounds like the user (HLT) would prefer that the order not be deleted before something happens with the hold. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1433] 'Add Subscription' should populate biblionumber if done from the subscriptions view of a biblio
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1433 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jmf(a)liblime.com |paul.poulain(a)free.fr ------- Comment #2 from jmf(a)liblime.com 2007-10-05 23:59 ------- Using our new template design, the 'subscription' page is really just a 'view' of the bibliographic record. The subscription page currently lists all of the subscriptions attached to a biblio. If you click on the 'add subscription' link from a specific biblio (no matter what 'view'), it should pre-populate the biblionumber for that subscription to be the same as the biblio you started from. In this way, it would be trivial to add new subscriptions to a given biblio in the case where more than one subscription is needed. Does that clarify? All we need is a new param for 'biblionumber' that can be added ?biblionumber=N that pre-populates the bib number in the subscription planning page. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1453] Date acquired in item editor /cgi-bin/koha/cataloguing/additem.pl broken
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1453 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #2 from jmf(a)liblime.com 2007-10-05 23:55 ------- patch submitted, fixed. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1473] New: addbiblio.pl -> MARCfindbreeding breaks MARC21 records in reservoir
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1473 Summary: addbiblio.pl -> MARCfindbreeding breaks MARC21 records in reservoir Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P3 Component: Acquisitions (Simple) AssignedTo: paul.poulain(a)free.fr ReportedBy: jmf(a)liblime.com QAContact: koha-bugs(a)nongnu.org CC: henridamien(a)koha-fr.org The MARCfindbreeding was written for UNIMARC, it auto-changes fields by default (such as 010 and 100$a (title in MARC21)) in ways that destroy data (such as the '-' in an ISBN, etc. ... also, it's unclear what the features "z3950NormalizeAuthor" and "z3950AuthorAuthFields" do ... Do they only function if you have authority control enabled? do they find values from your authorities database? what exactly are they supposed to do, step by step? For the breeding farm to function properly for MARC21, these issues must be resolved. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1451] Plugins are broken in MARC editor
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1451 ------- Comment #6 from jmf(a)liblime.com 2007-10-05 17:57 ------- I've confirmed these work now, I still haven't tested authorities plugins, but the others work great. Thanks Paul! ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1452] Labels for item editor are truncated
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1452 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Comment #1 from jmf(a)liblime.com 2007-10-05 17:51 ------- Fixed by HDL, thanks! ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1459] checking out a book dies
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1459 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|Macintosh |All ------- Comment #2 from jmf(a)liblime.com 2007-10-05 17:46 ------- The solution proposed is the following: + if ( $borrower->{'dateexpiry'} eq '0000-00-00') { $issuingimpossible{EXPIRED} = 1; + } else { + if ( Date_to_Days(Today) > + Date_to_Days( split "-", $borrower->{'dateexpiry'} ) ) + { + $issuingimpossible{EXPIRED} = 1; + } This works when the patron's expiry date is set to 0000-00-00, so I've accepte the patch, but that's a nonsensical date, and in most cases, since the expirydate defaults to NULL, the date will be null. We need to handle the case of a null date, perhaps on the fly assigning a date based on the date the patron's record was created? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1442] AutoLocation does not actually work as advertised
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1442 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |major Status|RESOLVED |REOPENED Resolution|FIXED | ------- Comment #3 from jmf(a)liblime.com 2007-10-05 17:24 ------- OK, just tested three patches by Paul: http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=ebb9890ccb88727117… http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=ba569c3cfa6f8e9c38… http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=d24f28a4131f4e4b39… These do improve things slightly, but are buggy. If you have AutoLocation AND IndependentBranches defined, and you set a branch to have an IP, Koha will hide the link to 'setbranchprinter.pl' (Set). But, if you have AutoLocation turned OFF, the link will appear, but it won't work, and Koha will still AutoLocate you. If you have it turned off, it shoudln't use the IP addresses to set the branch. I'm re-opening this bug. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1472] Foreign key constraint fails on item checkout
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1472 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #1 from jmf(a)liblime.com 2007-10-05 16:58 ------- this only happens for the kohaadmin user ... it's OK :-) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 1472] Foreign key constraint fails on item checkout
by bugzilla-daemon＠pippin.metavore.com 06 Oct '07

06 Oct '07

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1472 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker Platform|Macintosh |All ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0