February 2013 - 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 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 6059] New: Problem with changing quantity on uncertain prices list
by bugzilla-daemon＠bugs.koha-community.org 17 May '15

17 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6059 Bug #: 6059 Summary: Problem with changing quantity on uncertain prices list Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All URL: /cgi-bin/koha/acqui/uncertainprice.pl?booksellerid=2&o wner=1 OS/Version: All Status: NEW Severity: major Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org On the list for managing uncertain prices there is a column for quantity that can be edited. When creating your items on order the possibility to create items there does not make sense. When changing the quantity the uncertain price will be unset and the quantity changes to your entered number. But no additional items will be created and there is no warning about that. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 12

[Bug 5534] New: koha does not ignore punctuation when searching
by bugzilla-daemon＠bugs.koha-community.org 15 May '15

15 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5534 Summary: koha does not ignore punctuation when searching Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When you're doing a search for a title like "Harrison's Internal Medicine" you can find it if you search for "harrison" or "harrison's" but not "harrisons" - the punctuation is required. This seems a bit odd since most search engines don't require that you enter the punctuation. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 16

[Bug 9269] New: Remove DefaultLanguageField008 syspref
by bugzilla-daemon＠bugs.koha-community.org 15 May '15

15 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9269 Bug ID: 9269 Summary: Remove DefaultLanguageField008 syspref Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul.poulain(a)biblibre.com CC: gmcharlt(a)gmail.com In MARC bibliographic frameworks, you can define a default value. I think this can be used to define a value for 008 field. In this case, the DefaultLanguageField008 is useless and can be removed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 9530] New: Allow separate 'Reply To' and 'From' email address for notices
by bugzilla-daemon＠bugs.koha-community.org 15 May '15

15 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9530 Bug ID: 9530 Summary: Allow separate 'Reply To' and 'From' email address for notices Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: katrin.fischer(a)bsz-bw.de Reporter: katrin.fischer(a)bsz-bw.de It should be possible to use different Reply To and From email addresses for sending out notices. -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 4960] New: No way to enter custom purchase order number
by bugzilla-daemon＠bugs.koha-community.org 15 May '15

15 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4960 Summary: No way to enter custom purchase order number Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 There needs to be a way on order to enter a purchase order number that will then print on the PDF receipt. Most organizations do not have purchase orders that are sequential for book orders only (the library may have sequential POs for all their orders - supplies, books, etc) and the ID generated by the DB won't work for them. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 6

[Bug 9157] New: inventory tool enhancement
by bugzilla-daemon＠bugs.koha-community.org 15 May '15

15 May '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9157 Bug ID: 9157 Summary: inventory tool enhancement Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: melia(a)bywatersolutions.com One library's workflow is such that volunteers go around and scan barcodes during a month long inventory process. At the end of the month, the librarian uploads the .txt files using the inventory tool. The problem is that some of the items have been checked out over the course of that month. For example, perhaps the item was on the shelf in August and was scanned by a volunteer, but then the item was checked out to a patron in September. When the librarian uploads the text file later in September, Koha updates the date last seen to today, even though the real date last seen is the date that the item was checked out to the patron. The librarian would prefer that the inventory tool were enhanced so that it's smart enough to skip any items that are currently checked out at the time the .txt file is uploaded. For this library, inventory is a long process that is not done in 'real time,' so their use of the inventory tool is a bit different from how it was designed to be used. -- You are receiving this mail because: You are watching all bug changes.

1 8