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

[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 14487] New: Warns from returns.pl during checkin
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14487 Bug ID: 14487 Summary: Warns from returns.pl during checkin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: indradg(a)gmail.com Reporter: indradg(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Suppress these warns during returning an item returns.pl: Use of uninitialized value $holdingBranch in string eq at /home/l2c2technologies/koha/circ/returns.pl line 623., referer: http://kohamaster.l2c2.co.in/cgi-bin/koha/members/readingrec.pl?borrowernum… returns.pl: Use of uninitialized value $collectionBranch in string eq at /home/l2c2technologies/koha/circ/returns.pl line 623., referer: http://kohamaster.l2c2.co.in/cgi-bin/koha/members/readingrec.pl?borrowernum… -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 14387] New: Merge reference selection has no effect when merging authorities.
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14387 Bug ID: 14387 Summary: Merge reference selection has no effect when merging authorities. 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: maxime.beaulieu(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When merging authority records, the merge reference is always set to the first selected record. How to reproduce: 0 Create authorities/reindex if necessary. 1 Search for authorities 2 Click merge on two entries (Keep note of the CLICK order 1&2) 3 Select the second authority (authority 2) as merge reference 4 In the following page: The authid in the tabs are correct. The record data is wrong. First tab is authority 1, second is authority 2. The resulting record is generated using authority 1 as reference. A patch will follow. -- You are receiving this mail because: You are watching all bug changes.

1 13

[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 14456] New: EmbedSeeFromHeadings record filter shouldn't process MARC holding fields
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14456 Bug ID: 14456 Summary: EmbedSeeFromHeadings record filter shouldn't process MARC holding fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org If the system preference IncludeSeeFromInSearches is enabled, records exported for zebra indexing are being additionally processed by EmbedSeeFromHeadings record filter (right now used only in rebuild_zebra.pl script). This filter embeds 'see from' fields (extracted from authority records linked with the given biblio via $9 subfields) into target MARC record, which is then subsequently indexed in zebra. Currently all fields containing $9 are getting the same exact treatment by this filter. But on the export stage when the filter is applied, MARC record being processed already does have holdings data fields added in the previous stage (usually 952 / 995, depending on the MARC format). Problem is that holdings data fields use to have $9 subfields in them as well (mapped to item.itemnumber by default). As a consequence, some (great many in the typical setup) records exported for zebra indexing may have surplus "see from" fields added erroneously in semi-random fashion, so biblio searches would often return some completely unexpected additional results. EmbedSeeFromHeadings record filter should not process holdings fields when dealing with MARC records intended for zebra indexing. To reproduce: 1) database with as many sample or real-world biblio, item and authority records as possible is recommended for testing purposes 2) enable IncludeSeeFromInSearches 3) export a bunch of biblio records for zebra (e.g.: misc/migration_tools/rebuild_zebra.pl -I -b -x -k -length=1000), inspect the result xml records in /tmp/<whatever> file; observe that at the end of many records, here and there some extra "see from" (= 1st indicator: 'z') fields tend to appear, which shouldn't be there ;) -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 14569] New: Typo for borrowers
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14569 Bug ID: 14569 Summary: Typo for borrowers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 14445] New: Noisy warns in Notices (letter.tt) module
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14445 Bug ID: 14445 Summary: Noisy warns in Notices (letter.tt) module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org A few noisy warns in koha-tmpl/intranet-tmpl/prog/en/modules/tools/letter.tt: In staff interface, go to Tools, then Notices & Slips Error: Click 'new notice' --> Argument "" isn't numeric in numeric gt (>) at line 400 Error: Change Koha module any other module --> same error Error: Change Koha module to 'Circulation' --> same error, and use of uninitialized value $code in string eq at line 230 -- You are receiving this mail because: You are watching all bug changes.

1 23

[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 14465] New: Broken umlauts/diacritics in feedback of last checkout
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14465 Bug ID: 14465 Summary: Broken umlauts/diacritics in feedback of last checkout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 40650 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=40650&action=edit Screenshot showing the problem This was tested in 3.18 after upgrading to the security release. The feedback on the last checkout information introcuded by bug 13315 has encoding problems in the displayed title (see screenshot). This is a really prominent place to display broken encoding. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 13888] New: 'Lists' permission should allow/disallow using the lists module in staff
by bugzilla-daemon＠bugs.koha-community.org 27 Aug '15

27 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13888 Bug ID: 13888 Summary: 'Lists' permission should allow/disallow using the lists module in staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl With bug 13417 a new permission was added to allow/disallow deletion of public lists. The lists permission doesn't work like other module level permissions as turning it off won't disallow use of the lists module. It would be nice if this could be added. It might need a 'remaining lists permissions' permission, so that you can only disallow the deletion of public lists but allow general use of the module. -- You are receiving this mail because: You are watching all bug changes.

1 5