March 2018 - Koha-bugs - lists.koha-community.org

[Bug 20494] New: Remove unused code in neworderempty.pl and addbiblio.pl
by bugzilla-daemon＠bugs.koha-community.org 03 Apr '18

03 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20494 Bug ID: 20494 Summary: Remove unused code in neworderempty.pl and addbiblio.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org z3950authortemplate is referenced in some comments and there are a few other lines commented out that seem to be cruft -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 20392] New: Multiple biblio holding does not work when patron is not set
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '18

02 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20392 Bug ID: 20392 Summary: Multiple biblio holding does not work when patron is not set Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1) Set the system preference DisplayMultiPlaceHold to enable 2) Search in staff client catalogue 3) On results page check more then one result and click on Place hold button at the top of the page 4) Search for patron, but don't be to specific, you need to have more then one result 5) Click on one of the found patron 6) Now you are going to confirm a hold, but only for one record! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 19527] New: Alter Zebra indexing to sort by descending document ID
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19527 Bug ID: 19527 Summary: Alter Zebra indexing to sort by descending document ID Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk We are receiving complaints about the sorting order of relevance ranked searches. One specific example was where the older edition of a work appears higher up the list than the more recent version. According to http://www.indexdata.com/zebra/doc/administration-ranking.html: “If one defines the staticrank:1 directive in the main core Zebra configuration file, the internal document keys used for ordering are augmented by a preceding integer, which contains the static rank of a given document, and the index lists are ordered first by ascending static rank, then by *** ascending *** document ID.” Would it not be better to have the secondary rank in terms of ** descending *** document ID? That way there is much better likelihood that the most recently published version of various editions will appear closer to the top of the OPAC list, and certainly (all else being equal) above the earlier edition(s) of the specific work. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 8643] Add important constraint to marc subfields
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8643 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #44 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Charles, a lighter yellow would work for me. I retested, but I can't get the message to show up now, neither for an important field or subfield. Can you please check? Tiny thing: marc_tag_structure - maybe move the new field after mandatory? +-- $dbh->do("ALTER TABLE marc_tag_structure ADD COLUMN important TINYINT(4) NOT NULL DEFAULT 0 AFTER frameworkcode"); -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8457] No results found on term/phrase click in scan index results list
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8457 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|No results found on |No results found on |term/phrase click in scan |term/phrase click in scan |index results list . |index results list --- Comment #9 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I am still seeing very different result lists when clicking on an index term. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7882] Add ability to move and reorder fields in MARC editor
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7882 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #45 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > > Let [1,2,3,4] be the framework structure > Let [1,4,2] be the saved record > > Currently we load on the framework structure order, giving us > 1, 2, 3 (empty), 4 > This does not respect the saved record order. But if we load according do > the saved record order, where should the empty tag (3) go? Should we place > it before the saved record's fields or after? Or do some weird half-sorted > behavior? > > before : [3 (empty), 1, 4, 2] > after : [1, 4, 2, 3 (empty)] > weird : [1, 3 (empty), 4, 2] I'd put the empty ones at the bottom of the list, in alphabetic sequence. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11361] Add a Z39.50 search page in the OPAC to let members search for records on remote Koha instances
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11361 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add a Z39.50 search page in |Add a Z39.50 search page in |the OPAC to let members |the OPAC to let members |search for records on |search for records on |remote Koha instances. |remote Koha instances --- Comment #13 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Checked in my devbox too: Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 11361 - Add a Z39.50 search page in the OPAC to let members search for records on remote Koha instances fatal: sha1 information is lacking or useless (C4/Auth.pm). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 Bug 11361 - Add a Z39.50 search page in the OPAC to let members search for records on remote Koha instances The copy of the patch that failed is found in: /home/vagrant/kohaclone/.git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-11361---Add-a-Z3950-search-page-in-the-OPAC-to-mVnpFd.patch -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13044] Deprecate old book drop mode
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '18

01 Apr '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13044 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer(a)bsz-bw.de --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- We could keep the preference and use it to switch between the date being set automatically and being able to change it. Would that work? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 19779] New: Some notices not using Reply To email address
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '18

31 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19779 Bug ID: 19779 Summary: Some notices not using Reply To email address Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: rachel.dewar(a)cass.govt.nz QA Contact: testopia(a)bugs.koha-community.org If you specify a ReplyToDefault or a Branch ReplyTo email address some notices still do not use them. These are the ones that I have come across: - Holds - when a hold is placed on an item - Sharing a list - both the invitation to share a list and email confirming that the person has accepted the inviation - Overdue notices -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7047] Renewing serials note not visible
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '18

31 Mar '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7047 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|renewing serials note not |Renewing serials note not |visible |visible -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0