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

[Bug 590] New: Title searches don't include biblio.unititle
by bugzilla-daemon＠wilbur.katipo.co.nz 02 Sep '03

02 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=590 Summary: Title searches don't include biblio.unititle Product: Koha Version: CVS Platform: PC Status: NEW Severity: normal Priority: P2 Component: Catalogue AssignedTo: chris(a)katipo.co.nz ReportedBy: shedges(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net Hmm.. I think the summary says it all. Since unititle is a title variant, it should be searched, too, whenever a title search is done. That doesn't seem to be happening now. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 589] New: Too many tags omitted from MARC searches and edits
by bugzilla-daemon＠wilbur.katipo.co.nz 02 Sep '03

02 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=589 Summary: Too many tags omitted from MARC searches and edits Product: Koha Version: CVS Platform: PC Status: NEW Severity: major Priority: P2 Component: MARC AssignedTo: paul.poulain(a)free.fr ReportedBy: shedges(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net It seems like all the MARC tags you define in your MARC tag structure (parameters) should be available for searching and editing. The selection of tags that shows up now for searching or editing/adding seems very random and doesn't even include all the tags we have mapped to Koha (let alone defined). For example, in the case of the 440 tag, it's mapped to biblio.seriestitle, so it's in both the 'old' Koha tables and the 'new' MARC tables -- yet you can't get to it! ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 532] Can't assign new password without changing UserID
by bugzilla-daemon＠wilbur.katipo.co.nz 02 Sep '03

02 Sep '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=532 ------- Additional Comments From oleonard(a)athenscounty.lib.oh.us 2003-09-03 03:15 ------- We thought this was working again for us, but it's definitely not. Can anyone verify this? It happens both in our custom template and in the default template. The workaround is to change both the username and the password at the same time, and then go back and change the username back to its original value. This obviously isn't very efficient. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 588] New: OPAC search results show '2 through x of x records'
by bugzilla-daemon＠wilbur.katipo.co.nz 30 Aug '03

30 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=588 Summary: OPAC search results show '2 through x of x records' Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: OPAC AssignedTo: chris(a)katipo.co.nz ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The firs OPAC search results pages says it is displaying records starting with number two. So, for 26 results, is displays 'Results 2 through 22 of 26 records.' Here's the relevant section in opac-searchresults.tmpl: Results <TMPL_VAR NAME="startfrom"> through <TMPL_VAR NAME="endat"> of <TMPL_VAR NAME="numrecords"> records. The problem shows in all templates. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 587] New: deleted items are not being removed from marc tables
by bugzilla-daemon＠wilbur.katipo.co.nz 29 Aug '03

29 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=587 Summary: deleted items are not being removed from marc tables Product: Koha Version: CVS Platform: Other OS/Version: Linux - Debian Status: NEW Severity: major Priority: P2 Component: MARC AssignedTo: paul.poulain(a)free.fr ReportedBy: shedges(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net When you delete items, biblioitems, or biblios, the functions called from C4/Biblio (&delitem, etc.) just call the &OLDdelitem, etc. functions in the same module. These old functions do not remove anything from the marc_subfield_table, so searches for deleted items still return a barcode, etc. It looks like someone started the process of making new, MARC versions of these functions and then stopped. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 562] Returns not showing 'on reserve' message for holds
by bugzilla-daemon＠wilbur.katipo.co.nz 28 Aug '03

28 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=562 chris(a)katipo.co.nz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From chris(a)katipo.co.nz 2003-08-29 09:25 ------- HLT arent running this version. But from your description it certainly sounds very broken. Ill try and work on it over the weekend. Stephen .. do you want to do a mysqldump of your reserves and reserveconstraints table? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 562] Returns not showing 'on reserve' message for holds
by bugzilla-daemon＠wilbur.katipo.co.nz 28 Aug '03

28 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=562 ------- Additional Comments From shedges(a)athenscounty.lib.oh.us 2003-08-29 09:13 ------- No, the problem doesn't seem to be our data. When I manually add a reserve on an issued item and then check it in, I still don't get a message. (How could this possibly be working for HLT?!? What is different?) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 562] Returns not showing 'on reserve' message for holds
by bugzilla-daemon＠wilbur.katipo.co.nz 28 Aug '03

28 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=562 ------- Additional Comments From shedges(a)athenscounty.lib.oh.us 2003-08-29 05:40 ------- Has anyone tried the latest CVS on a functioning database (like HLT)? This reserve business seems to be very complex, and I'm wondering if our 'virgin' database does not yet have all the parameters that need to be passed to the CGIs and modules, since it's imported data. If this seems to work elsewhere, perhaps the solution is to enter all of our current (1500+) reserves manually (yuk). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 586] New: additem.tmpl displays incorrect biblio number
by bugzilla-daemon＠wilbur.katipo.co.nz 28 Aug '03

28 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=586 Summary: additem.tmpl displays incorrect biblio number Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Acquisitions (Simple) AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net additem.tmpl (template for /cgi-bin/koha/acqui.simple/additem.pl) contains this snippet: <b>MARC biblio : <TMPL_VAR name="bibid"></b> ...But the value displayed here is not the biblio number of the record to which items are being added. Elsewhere in the template is the variable '<TMPL_VAR name="biblionumber">' which is correct. Why two variables? Is 'bibid' supposed to be something different? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 585] New: Using 'document.forms[0]' notation prevents use of other forms on page
by bugzilla-daemon＠wilbur.katipo.co.nz 26 Aug '03

26 Aug '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=585 Summary: Using 'document.forms[0]' notation prevents use of other forms on page Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Acquisitions (Simple) AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-bugs(a)lists.sourceforge.net The use in javascript of references like 'document.forms[0]...' prevents users from adding other forms on the page. We have a persistent navigation menu in our template which uses several forms for quick searches. Because they precede the 'main' form on the page, the 'document.forms[0]...' notation breaks, since it now points to the wrong form. I'm guessing the solution would be to identify forms by name and id. These references are used in the templates acqui.simple\addbiblio.tmpl, acqui.simple\additem.tmpl, circ\returns.tmpl, and search.marc\search.tmpl ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0