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

[Bug 8480] New: auth_subfield_structure is not cleared when deleting an authority type
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8480 Priority: P5 - low Change sponsored?: --- Bug ID: 8480 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: auth_subfield_structure is not cleared when deleting an authority type Severity: normal Classification: Unclassified OS: All Reporter: gaetan.boisson(a)biblibre.com Hardware: All Status: NEW Version: master Component: Staff Client Product: Koha To reproduce : - in authtypes.pl create a new authority type - have a look at it's MARC structure and fill it with the default type for instance - delete it - in the database the auth_subfield_structure table was not properly cleared : auth_type and auth_tag_structure were properly cleared but all the subfields for the test authority type are still there. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 9987] New: biblioitemnumber is useless for orders.
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9987 Bug ID: 9987 Summary: biblioitemnumber is useless for orders. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com The DB field aqorders.biblioitemnumber seems to be unused and useless. It should be removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 7806] New: Illegal dates are used to signal non existing dates.
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7806 Priority: P5 - low Change sponsored?: --- Bug ID: 7806 Assignee: gmcharlt(a)gmail.com Summary: Illegal dates are used to signal non existing dates. QA Contact: koha.sekjal(a)gmail.com Severity: major Classification: Unclassified OS: All Reporter: marc(a)msys.ch Hardware: All Status: NEW Version: unspecified Component: Database Product: Koha The illegal date '0000-00-00' is being used in Koha to signal a non-existing date. MySQL allows for such illegal dates. A database like PostgreSQL, which is much more strict when it comes to correct data, does not allow illegal values as date values. If a date is inexistant/invalid etc. an SQL NULL must be used instead. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 8962] New: Create a new index for OPAC simple search, more specific than "any"
by bugzilla-daemon＠bugs.koha-community.org 18 May '15

18 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8962 Priority: P5 - low Change sponsored?: --- Bug ID: 8962 Assignee: gmcharlt(a)gmail.com Summary: Create a new index for OPAC simple search, more specific than "any" Severity: enhancement Classification: Unclassified OS: All Reporter: mathieu.saby(a)univ-rennes2.fr Hardware: All Status: NEW Version: unspecified Component: Searching Product: Koha In the current record.abs, the index "any" is defined as "all any". So, all the fields indexed in other indexes are also indexed in "any". So, for example, in my unimarc catalogue, if I search for "fre" in the opac, I get 342825 results, because it is the code for french language in 101a field, index in "ln". Idem if I search for "lc" or "rameau" (equivalent to LCSH in France), or "texte" And with fuzzy or autotruncate activated, it is, very very annoying. My idea is : - to keep the "all any" - to create a more specific index, matching only important field, but in any event NOT matching coded fields and some boring notes... - use this index in opac simple search (and maybe in staff interface simple search but this could be discussed...) Todo : - check bib1.att & ccl.properties to see if some index not used in Koha today could be used. If nothing usable, create completely new index. - edit record.abs for unimarc, marc21 and normarc biblios - edit DOM config files for unimarc, marc21 and normarc biblios - check if it is necessary to edit zebra config files for authorities - edit the templates - maybe edit some perl files Mathieu Saby Rennes 2 University -- You are receiving this mail because: You are watching all bug changes.

1 68

[Bug 9139] New: Sending empty vendor or biblio when adding subscriptions gives error
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9139 Bug ID: 9139 Summary: Sending empty vendor or biblio when adding subscriptions gives error Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/serials/subscription-add.pl OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de CC: colin.campbell(a)ptfs-europe.com I can only reproduce this in Firefox, not in Chromium. To reproduce: - Add a new subscription - Put cursor in first field for 'Vendor' or 'Biblio' and hit enter - Perl error page is shown: No record at /home/katrin/kohaclone/C4/Serials.pm line 1382 Sending an empty field should open the search pop up and not give a perl error message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 11576] New: Untranslatable "manage" in serials-collection
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11576 Bug ID: 11576 Summary: Untranslatable "manage" in serials-collection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr PrepareSerialsData() in C4/Serials.pm has a hard-coded "manage", which is shown to the user in serials-collection -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 10335] New: UNIMARC authorities search doesn't display properly information on parallel form
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10335 Bug ID: 10335 Summary: UNIMARC authorities search doesn't display properly information on parallel form Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: januszop(a)gmail.com UNIMARC authorities can contain translated headings. The language is coded in $8 subfield: "Subfield $8 contains 6 character positions (designated as $8/0, 8/1, etc.) The first group of three characters specifies the language of catalogue into which the heading in the field is designed to fit; the second group of three characters specifies the language of the base heading. The language codes are listed in the ISO 639-2 standard and in Appendix A of the UNIMARC Manual - Bibliographic Format." (cf. UNIMARC manual : authorities format. -- 2nd rev. and enl. ed. -- München : Saur, 2001, p. 66) I.e. it is the second triple designates the language of in which the actual parallel form is entered. Currently the information is displayed wrongly. To reproduce: 1) Create an authority record with main heading (100) in Latin script (e.g. Oppenheimer, Aharon -- subfields $a and $b) and parallel form (700) in Hebrew (אופנהיימר, אהרן -- subfields $a and $b). Mark it correctly in $8 with freheb (or engheb if you like); 2) reindex and search; 3) you will see: Oppenheimer Aharon freheb: אופנהיימר Whereas you would rather like to see (mind language and lack of $b above): Oppenheimer, Aharon Hebrew: אופנהיימר, אהרן A patch will follow. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 10976] New: the assistant for reports uses the wrong value for the list of item types
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10976 Bug ID: 10976 Summary: the assistant for reports uses the wrong value for the list of item types Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When using the assistant to create a new report (guided_reports.pl), if you choose to limit according to the itemtype, the generated code is <<itype|itemtype>>, but the proper value for the report to work should be <<itype|itemtypes>> (with an extra 's'). (This was also wrong in the wiki. Fixed now.) -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 11574] New: Printing Lists
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11574 Bug ID: 11574 Summary: Printing Lists Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 24474 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24474&action=edit Sections that shouldn't print when printing list Would like to see list printing from staff client cleaned up. Right now, the list printing includes buttons and the "Add and item..." section below. These should be omitted to save paper. -- You are receiving this mail because: You are watching all bug changes.

1 41

[Bug 10388] New: acq edited items showing 'null's
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10388 Bug ID: 10388 Summary: acq edited items showing 'null's Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com Created attachment 18567 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18567&action=edit edited item says null When editing items on the receipt page in acquisitions you see 'null' in all fields that have no value. This used to be a blank - or clear column, but now in 3.10.x and 3.12 and master it's showing null. It should be blank instead. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12