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

[Bug 8994] New: Make FindDuplicateAuthority behaviour customizable
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '15

01 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8994 Priority: P5 - low Change sponsored?: --- Bug ID: 8994 CC: m.de.rooy(a)rijksmuseum.nl Assignee: julian.maurice(a)biblibre.com Summary: Make FindDuplicateAuthority behaviour customizable Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Cataloging Product: Koha Make FindDuplicateAuthority behaviour customizable by adding 2 system preferences. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 11584] New: Add wysiwyg editor to system preferences dealing with HTML
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '15

31 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11584 Bug ID: 11584 Summary: Add wysiwyg editor to system preferences dealing with HTML Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, library staff have to hand-code system preferences that include HTML in them (e.g. OpacNAV, OpacHeader, etc.). This enhancement will add a wysiwyg editor for system preferences that are marked as "Htmlarea". Built-in system preferences (like those mentioned above) will need to have their .pref files changed (and I suppose the database even though the Type recorded there doesn't appear to be used by Koha itself). While a new type of "Htmlarea" will be available for Local System Preferences. People using Koha as a CMS (http://wiki.koha-community.org/wiki/Koha_as_a_CMS) might find this useful. Or anyone that has added local system preferences for injecting HTML into their templates. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 13142] New: Change "mobile phone" label back to "other phone"
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13142 Bug ID: 13142 Summary: Change "mobile phone" label back to "other phone" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: nengard(a)gmail.com Bug 12407 changed the "other phone" label to "mobile phone." However I think this conflicts with the changes made by Bug 5252 which changed the labels to the more generic "primary," "secondary," and "other" with the intention of letting the patron choose a primary contact number regardless of what kind of phone it is. If the OPAC didn't reflect this change then that was a bug which should have been fixed as a follow-up to 5252. As for the fact that the database column name says "mobile," I don't think that should dictate what kind of data we are storing. At this point we've created a lot of confusion about how patron contact information is stored. Before August 2011 phone data may have been entered according to the specific "home," "work," and "cell" labels. After that date we can assume that new phone data was added according to the priority defined by the new labels. Now with Bug 12407 we have a mix: Two phone fields in which the patron can prioritize contact numbers, and then "mobile," which is very specific. I don't think this makes sense. In my opinion the correct action at this point is to revert the label change made by Bug 12407 and make the corresponding change to the OPAC. If we feel that it's necessary to be able to identify what *kind* of phone number each one is, perhaps the solution is to add new columns to borrowers which can contain authorized values defining phone types: Primary phone: _________ [ Home | Work | Mobile | Etc ] -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 10961] New: Error in GetMarcBiblio can cause severe data loss
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10961 Bug ID: 10961 Summary: Error in GetMarcBiblio can cause severe data loss Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org A bug in GetMarcBiblio can cause severe data loss if your database has records where the biblionumber and biblioitemnumber do not match and the script misc/batchRebuildBiblioTables.pl is run. The Biblio::GetMarcBiblio makes a kall to C4::Biblio::_koha_marc_update_bib_ids which passes the biblionumber as both the biblionumber *and the biblioitemnumber*. Thus, if your biblio and biblioitem numbers are not always equal, you will end up with a record where the biblioitemnumber is incorrect in the record! This is usually not a severe issue, but since batchRebuildBiblioTables uses that record to update the database tables, it ends up updating the wrong biblioitem row! -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 11693] New: Default preferences not loaded for self registering patron
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11693 Bug ID: 11693 Summary: Default preferences not loaded for self registering patron Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: hissheep4(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com If a new patron uses the self registering option, their record is not created with the default emailing preferences, but is left blank. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 12669] New: "Template process failed: undef error - Invalid local time for date in time zone"
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12669 Bug ID: 12669 Summary: "Template process failed: undef error - Invalid local time for date in time zone" Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: rolando.isidoro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Created attachment 30268 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=30268&action=edit Error backtrace When accessing "Serial collection" for a given subscription the "Invalid local time for date in time zone" error message will show if any of the dates (publisheddate or planneddate) in the subscription is in fact a day where a timezone offset occurred at 00:00:00. Ex:. Date 1979-04-01 and timezone Europe/Lisbon. The day existed, but the 00:00:00 hour didn't, since after 1979-03-31 23:59:59 came 1979-04-01 01:00:00 source: http://www.timeanddate.com/time/change/portugal/lisbon?year=1979) I've debugged the issue and found out that it occurs when applying the KohaDates filter (lib/Koha/Template/Plugin/KohaDates.pm, specifically in the dt_from_string call @ line 32) in the serials collection template (intranet/htdocs/intranet-tmpl/prog/en/modules/serials/serials-collection.tt). The expected result would be for the dates to show up correctly since we're dealing with days and not timestamps, so 1979-04-01 should be valid even though 1979-04-01 00:00:00 isn't for the Europe/Lisbon timezone. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 13364] New: Add a call number browser in item edition page
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '15

27 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13364 Bug ID: 13364 Summary: Add a call number browser in item edition page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: simith.doliveira(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When editing an item, the call number browser search for existing call number. If it shows a line is green between two call numbers, the call numbers searched is available. If the call number is highlighted in red, it means that it already exists. This can be used to avoid repeated call numbers in your collection. The call number browser also shows its position relative to the rest of the collection. -- You are receiving this mail because: You are watching all bug changes.

1 98

[Bug 12637] New: UTF-8 problems when creating a patron list from the patron search results page
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '15

27 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12637 Bug ID: 12637 Summary: UTF-8 problems when creating a patron list from the patron search results page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Steps to reproduce: 1. Perform a patron search in the patrons module 2. Select one or more patrons 3. Choose "Add selected patrons to: [ New list ]" 4. Enter a patron list title with UTF-8 characters, ex: "Pàtron list five " 5. The list will be created with bad encoding: "P%C3%A0tron%20list%20five%20" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 13239] New: MySQL Character encoding utf8
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '15

27 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13239 Bug ID: 13239 Summary: MySQL Character encoding utf8 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: abl(a)biblos.pk.edu.pl, benjamin.rokseth(a)kul.oslo.kommune.no, bgkriegel(a)gmail.com, boutrosboutrosboutros(a)gmail.com, dpavlin(a)rot13.org, hbraum(a)nekls.org, jonathan.druart(a)biblibre.com, josef.moravec(a)gmail.com, katrin.fischer(a)bsz-bw.de, m.de.rooy(a)rijksmuseum.nl, magnus(a)enger.priv.no, martin.renvoize(a)ptfs-europe.com, paola.rossi(a)cineca.it, tomascohen(a)gmail.com, z.tajoli(a)cineca.it Depends on: 11248, 11906, 11944 Blocks: 7380, 10855, 11844, 12176, 12637, 12832 As discussed in bug 11944 we should use utf8_mb4 as default mysql encoding where the mysql version allows for it. This would allow for the entire utf8 character range rather than an arbitrarily truncated set as chosen by mysql during their first attempt at utf8 compatibility. As promised, I've opened this followup bug to track this issue. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12176] New: Remove HTML from additem.pl
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '15

27 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12176 Bug ID: 12176 Summary: Remove HTML from additem.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: bgkriegel(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There is HTML code on additem.pl In particular an untranslatable "Tag Editor" -- You are receiving this mail because: You are watching all bug changes.

1 70