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

[Bug 14398] New: Duplicate inventory results when an item is in the wrong place (ie using branch/location filter)
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '15

31 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14398 Bug ID: 14398 Summary: Duplicate inventory results when an item is in the wrong place (ie using branch/location filter) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, if an item is in the "wrong place" during an inventory, it will show up with a "problem" of "Item should not have been scanned", which makes sense. However, a duplicate row will also turn up saying "Change item status". This is a row that comes up due to a bug in the processing of not for loan values http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12913. In other words... an item might have multiple problems, but instead of listing multiple problems, an entire extra row gets added to the inventory results. I suppose this could be by design, but it seems like a bug to me, especially if you're feeding your inventory results into "Batch Item Modify" later... -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 14337] New: AllowRenewalIfOtherItemsAvailable counts holdable not for loan items when checking renewability
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14337 Bug ID: 14337 Summary: AllowRenewalIfOtherItemsAvailable counts holdable not for loan items when checking renewability Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com AllowRenewalIfOtherItemsAvailable checks C4::Reserves::IsAvailableForItemLevelRequest to see if the item is holdable, which catches not for loan values less than 0 ( i.e. holdable, but not circ-able ). However, since this feature is about actually checking out items to patrons, we should not count *any* not for loan items when deciding if the available items will satisfy all current holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[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 13663] New: offline circ permission issue
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13663 Bug ID: 13663 Summary: offline circ permission issue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)biblibre.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com circ/offline.pl needs the perm circulate_remaining_permissions but tools/upload-file.pl needs tools => * That means a librarian cannot upload the .koc files generated offline -- 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 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