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

[Bug 2493] addbiblio - Illegal tabindex (-1)
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2493 oleonard(a)myacpl.org changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |PATCH-Sent ------- Comment #1 from oleonard(a)myacpl.org 2008-08-08 09:59 ------- Patch submitted which changes instances of tabindex="-1" to tabindex="0" ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2344] No "New Member" button w/o js
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2344 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 2462] Holds may be placed on items with not-for-loan set at itemtype.
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2462 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Version|HEAD |rel_3_2 ------- Comment #2 from jmf(a)liblime.com 2008-08-08 09:40 ------- I can confirm that bib-level/next available holds are possible on the staff side, but can't reproduce the issue of item-level holds being allowed. However, although the checkbox is greyed out there's no good explanation for why. We should fix this in 3.2 when we clean up holds. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2462] Holds may be placed on items with not-for-loan set at itemtype.
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2462 jmf(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #1 from jmf(a)liblime.com 2008-08-08 09:32 ------- OK, the issue here doesn't apply to the OPAC, but to the staff view. My understanding is that staff do need to place holds on items ocassionally, so this will be best fixed by adding a warning, I'll see what I can do. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2495] Currently no way to correct a typo in an authority controlled bib tag $a in Koha
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2495 debra.denault(a)liblime.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicole.engard(a)liblime.com, | |jmf(a)liblime.com ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2496] New: Need more efficient way to edit authority data errors from bib frameworks
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2496 Summary: Need more efficient way to edit authority data errors from bib frameworks Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: MARC Authority data support AssignedTo: galen.charlton(a)liblime.com ReportedBy: debra.denault(a)liblime.com QAContact: koha-bugs(a)lists.koha.org CC: rch(a)liblime.com, jmf(a)liblime.com, nicole.engard(a)liblime.com Currently in Koha 3.0 if a bib tag (and specifically the subfield a) is defined to be under authority control via its framework setup, if the user needs to make any changes to the contents of $a to correct typos etc. they must edit the authority directly. Most cataloger's will catch errors when they are in the actual bib record editing it and do NOT want to have to wait until they have made the changes in the bib and saved them to then either a) link to the authority via the MARC tab in bib detail page in staff client to edit or search for the authority itself to edit. It would be a nice enhancement to add an "Edit" link to the search results list that opens up in the new window when a user clicks on "Tag Editor" from an authority controlled tags $a within the bib frameworks and searches for the authority. Clicking on edit should cause the authority framework editor to open in that same search results list window so once the change is made and saved the cataloger can close the window and return to the main staff client window to finish editing the bib. We will need to clearly document that this is the preferred way of making changes to errors in the $a for libraries that link tags to authority controlled data (versus editing directly in the bib framework (bug 2495)) and also to make it clear that the changes will not be reflected when the go back to the bib record and even after they have saved the bibs until merge_authority.pl has completed it's updates. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2466] can't remove value in item modif
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2466 ------- Comment #1 from joe.atzberger(a)liblime.com 2008-08-08 08:50 ------- Without disputing the symptom reported, I disagree that _koha_modify_item only updates populated values. ... my $query = "UPDATE items SET "; my @bind; for my $key ( keys %$item ) { $query.="$key=?,"; push @bind, $item->{$key}; } $query =~ s/,$//; $query .= " WHERE itemnumber=?"; push @bind, $item->{'itemnumber'}; my $sth = C4::Context->dbh->prepare($query); $sth->execute(@bind); ... So _koha_modify_item will modify values to empty-string if they are passed, i.e.: $item = { itemnumber=>531, field_x=>"", field_y=""}; ModItem also does not filter down the fields passed except to ensure cn.sort is calculated, and notforloan/damaged/itemlost/wthdrawn are 0 instead of "" or undef. That leaves ModItemFromMarc as the remaining suspect. It uses TransformMarcToKoha and _get_unlinked_item_subfields. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2495] New: Currently no way to correct a typo in an authority controlled bib tag $a in Koha
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2495 Summary: Currently no way to correct a typo in an authority controlled bib tag $a in Koha Product: Koha Version: rel_3_0 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P3 Component: MARC Authority data support AssignedTo: galen.charlton(a)liblime.com ReportedBy: debra.denault(a)liblime.com QAContact: koha-bugs(a)lists.koha.org CC: rch(a)liblime.com The current set-up/definition in the bib frameworks in Koha of the subfield a of tags deemed under authority control prevent the user from being able to edit any typos etc. that exist in the contents of the $a of these tags directly via the editor. This is especially a problem where the library has not loaded any authorities and had them linked to bibs nor have the syspref BiblioAddsAuthorities turned on to create brief authorities. They have NO way of changing this info. Suggestion is to add a syspref that will allow users to edit the contents of the $a in these tags directly from the editor. Caveat to be clearly explained to customer for short term - In the case where a library has loaded authorities or created stubbies and have them linked to the tag, they can/will need be directed to make the changes in the authority record itself and have the changes reflect back into the bib otherwise they are in the position where they will delink the authority from the bib. I will be adding another open enhancement request to make it more efficient to access the edit authorities via the bib frameworks editor. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2494] New: merge_authority.pl not updated for 3.0
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2494 Summary: merge_authority.pl not updated for 3.0 Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: critical Priority: P3 Component: Command-line Utilities AssignedTo: henridamien(a)koha-fr.org ReportedBy: rch(a)liblime.com QAContact: koha-bugs(a)lists.koha.org CC: debra.denault(a)liblime.com Utility to update bibs with recently modified authority data is not present in Koha 3. merge_authority.pl is a 2.2 script to merge two authorities, update the bibs linked to the 'old' authority, then delete the old authority. Require a script that checks for recently modified authorities, and updates all bib records linked to those authorities, preferably by datemodified so that it can be run as a cron job. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 2487] Collection code select boxes in Adv search show both code and description
by bugzilla-daemon＠pippin.metavore.com 08 Aug '08

08 Aug '08

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2487 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