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

[Bug 18825] New: Elasticsearch - Update default authority mappings
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '18

23 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18825 Bug ID: 18825 Summary: Elasticsearch - Update default authority mappings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: nick(a)bywatersolutions.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We currently only include a few if they authority types in the initial mappings - we need to round these out -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 17373] New: Elasticsearch - Authority mappings are not defined for UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 23 Jul '18

23 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17373 Bug ID: 17373 Summary: Elasticsearch - Authority mappings are not defined for UNIMARC Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org The file admin/searchengine/elasticsearch/mappings.yaml does not contain any authority mappings for UNIMARC. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 17468] New: Remove koha-*-zebra scripts in favor of koha-zebra
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '18

18 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17468 Bug ID: 17468 Summary: Remove koha-*-zebra scripts in favor of koha-zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 18851] New: use Test::DBIx::Class in 00-load.t breaks packaging
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '18

16 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18851 Bug ID: 18851 Summary: use Test::DBIx::Class in 00-load.t breaks packaging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org Bug 18266 introduces a regression for a problem fixed in Bug 15150. Test::DBIx::Class is not mandatory because it is not available in Debian, packaging of Koha is broken because of the use in t/00-load.t. -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 17680] New: C4::Circulation - Replace GetItemIssue with Koha::Issues
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '18

12 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17680 Bug ID: 17680 Summary: C4::Circulation - Replace GetItemIssue with Koha::Issues Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 92

[Bug 18811] New: Visibility settings inconsistent between framework and authority editor
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '18

11 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18811 Bug ID: 18811 Summary: Visibility settings inconsistent between framework and authority editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: Needs Signoff Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: m.de.rooy(a)rijksmuseum.nl Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Blocks: 17380 Status: ASSIGNED Assignee: m.de.rooy(a)rijksmuseum.nl CC: jonathan.druart(a)bugs.koha-community.org, julian.maurice(a)biblibre.com, nick(a)bywatersolutions.com Status: Needs Signoff Patch complexity: Small patch Blocks: 17380 >From Nick Clemens on IRC: "Worth mentioning - you can't edit the 942 of an authority when creating, but it appears you can when editing, though you can't save it - confusing as end user." We should keep in mind that AddAuthority overwrites 942c when adding or modifying auth records. When adding a record: Since you choose the framework, we should not allow to change 942c here. The current behavior is fine; the field should normally be hidden via the framework. (We could even enforce it if it would not be hidden?) When modifying a record: The authorities.pl script (incorrectly) shows hidden fields when filled (which actually is weird). Since 942c is overwritten, this is useless. A closer look reveals that the visibility checks in authorities.pl do not completely correspond with the values used in auth_subfields_structure.pl. Auth_subfields_structure offers only two possibilities: 0=Show all and -5=Hide all. The code in authorities.pl now checks <=-4 or >=5 (probably remains from older code). Note that the sql install scripts initialize 942c to 8. The proposed patch adds more consistency between auth_subfields_structure.pl and authorities.pl. A non-zero value will be interpreted as hidden. IMPORTANT NOTE: This solution will remove values in hidden fields from the MARC record. Imo it is theoretically the best solution, but if we do not want to take that risk, we could also remove the two next statements at line 407 and 423 and add a specific next for 942c (enforcing to always hide it). --- Comment #1 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- In the previous comment 942c must be 942a. --- Comment #2 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Created attachment 64314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=64314&action=ed… Bug 18811: Change visibility checks in authorities.pl The check is now <=-4 or >=5, but the framework uses 0 for Show all and -5 for Hide all. (Note that sql installer scripts also use 8.) When modifying an authority, the script also showed hidden fields when filled, since it did not check the hidden field but only the tab field. NOTE: The proposed solution restores consistency, but will remove hidden fields from the MARC record. Test plan: [1] Set field 942a to Show all in an authority framework. [2] Open a new record in this framework and verify that you see 942a. [3] Edit an existing record in this framework and verify again. [4] Set field 942a now to Hide all in this framework. [5] Open a new record in this framework and verify that 942a is hidden. [6] Edit an existing record in this framework and verify again. --- Comment #3 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- Nick, Julian or Jonathan: Would you have any comment on the *risk* of this solution? --- Comment #4 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #3) > Nick, Julian or Jonathan: > Would you have any comment on the *risk* of this solution? This mail did not come through due to a mail problem that specific day. Second try :) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17380 [Bug 17380] Cannot edit authorities with authtypecode = default -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 16242] New: Move staff client JavaScript out of language directory
by bugzilla-daemon＠bugs.koha-community.org 04 Jul '18

04 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16242 Bug ID: 16242 Summary: Move staff client JavaScript out of language directory Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 16241 In the staff client, the prog/en/js directory doesn't need to be duplicated for each translation since JavaScript files are not translated. These files should be moved to prog/js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16241 [Bug 16241] Move staff client CSS out of language directory -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 17273] New: Batch MARC Modification - improve options to define which records to modify
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '18

02 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17273 Bug ID: 17273 Summary: Batch MARC Modification - improve options to define which records to modify 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: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Basically, duplicate the same thing we have for patrons bulk modification (create a patron list, use that list in the batch mod tool), but for biblios. Users should be able to do the following with this enhancement: * use a virtualshelf/list to provide targets for Batch MARC modification. Additionally, or alternatively, we could provide a "download file of biblionumbers" from a search result page that could then be imported into the tool using existing workflow of "Use a file." It could also be "download file of biblionumbers for selected results." Personally I think a list is a better choice, but don't want to be limiting in what the solution is. I do know that the workflow as it stands is pretty awkward. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 17153] New: Logging in during a search navigates to account page instead of back to search results
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '18

02 Jul '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17153 Bug ID: 17153 Summary: Logging in during a search navigates to account page instead of back to search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ldjamison(a)marywood.edu QA Contact: testopia(a)bugs.koha-community.org When a patron logs in the OPAC on any page, except opac-reserve.pl, they are always redirected to opac-user.pl. This can prove to be problematic in regards to tasks such as navigating search results (including both catalog and EDS searches if the EDS plugin is installed), adding tags, adding comments, or nearly any other action which requires a patron to login. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 18031] New: Update bootstrap in opac
by bugzilla-daemon＠bugs.koha-community.org 29 Jun '18

29 Jun '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18031 Bug ID: 18031 Summary: Update bootstrap in opac Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 2