April 2020 - Koha-bugs - lists.koha-community.org

[Bug 22572] New: Garbled content of MARC control fields in MARC view
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22572 Bug ID: 22572 Summary: Garbled content of MARC control fields in MARC view Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mik(a)adminkuhn.ch QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- MARC control fields consist of a fix number of positions that can contain blanks. The "MARC view" in the Koha staff client and the Koha OPAC garbles the content of such fields when the field contains more than one consecutive blank - in this case more than one consecutive blank is automatically collapsed down by the webbrowser to just one. Additionally blanks may be trimmed at the end of the content of a field. For example MARC 008 does and must consist of exactly 40 positions, thus a line like the following (as shown via webbrowser in the MARC view) is always wrong: 800422s1978 sz a 1 ger In fact the correct content of MARC 008 would look like the following 800422s1978 sz a 1 ger Or better visible, when using # instead of blanks: 800422s1978####sz########a#####1###ger## Seemingly, this applies to all MARC control fields: 006 (fix length 18 positions), 007 (variable length of up to 23 positions), 008 (fix length of 40 positions). In the database the content of these fields is correct. Maybe before showing the blank character in the "MARC view" it should be coded as HTML entity   so the webbrowser doesn't collapse it. Also it may be a good idea to show the beginning and the end of such fields because otherwise (like in the above example) it is not visible that the field does contain two positions with blanks at the end. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 25049] New: Changes to overduerules.pl are not being saved
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25049 Bug ID: 25049 Summary: Changes to overduerules.pl are not being saved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When trying to save a notice and transport type in cgi-bin/koha/tools/overduerules.pl, there is a message saying that the changes have been saved, but the screen refreshes to the previous version. Nothing gets saved to the database either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 19349] New: Allow to store biblio record' s creator and last modifier in MARC
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19349 Bug ID: 19349 Summary: Allow to store biblio record's creator and last modifier in MARC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This will allow to store borrowernumber and name of biblio record's creator and last modifier in the MARC record. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 25269] New: MARC21slim2OPACResults.xsl does not display all formats (physical descriptions)
by bugzilla-daemon＠bugs.koha-community.org 23 May '20

23 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25269 Bug ID: 25269 Summary: MARC21slim2OPACResults.xsl does not display all formats (physical descriptions) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In MARC21slim2OPACResults.xsl we set the 'Format' or physical description by a combination of the 007 first position and 007 second position. In most cases this displays some text (example: chip cartridge or magneto-optical disc) But some set an png icon instead of any text. Like: <img src="/opac-tmpl/lib/famfamfam/world.png" alt="earth moon globe" class="format"/> These will not display at all that is because of this: <xsl:if test="string-length(normalize-space($physicalDescription))"> <span class="results_format"> <span class="label">; Format: </span><xsl:copy-of select="$physicalDescription"></xsl:copy-of> </span> </xsl:if> Without any text the string length is 0 and nothing at all displays. We need to add text along with each png icon. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 25278] New: Z3950 Responder does not work with Authorities under elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25278 Bug ID: 25278 Summary: Z3950 Responder does not work with Authorities under elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On top of 25277 authorities are not searchable under elasticsearch - query is built on bib fields -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 25277] New: Z3950responder does not work with Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25277 Bug ID: 25277 Summary: Z3950responder does not work with Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The Z3950 responder is hardcoded to search the '_all" field if no field is passed. This breaks as of Koha 19.11 where the "_all" field is removed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 25308] New: When cataloguing search fields are prefilled form record, content after & is cut off
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25308 Bug ID: 25308 Summary: When cataloguing search fields are prefilled form record, content after & is cut off Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To test: - Add a new record from default framework in cataloguing - Enter something containing an & in the middle (Stuff & stuff) in 245$a 100$a - Click on Z39.50/SRU search - Verify the fields author and title are prefilled, but information is cut off at the & See also bug 11446 in this context. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 17932] New: Koha::Object should provide a TO_JSON method
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17932 Bug ID: 17932 Summary: Koha::Object should provide a TO_JSON method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The Koha::Object class should provide a TO_JSON method that prepares data for JSON output. Right now, booleans are returned as integer values, and thus invalid for JSON output as boolean values. -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 19410] New: Koha::Objects needs a ->search_for_api method
by bugzilla-daemon＠bugs.koha-community.org 22 May '20

22 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19410 Bug ID: 19410 Summary: Koha::Objects needs a ->search_for_api method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We should extend Koha::Objects so searching can deal with squery parameters, specially handling pagination, results sorting, matching criteria, etc. This could be easily implemented using: - Bug 19196 (Pagination handling helpers) - Bug 19278 (Make REST api default page size configurable) - Bug 19234 (Query params handling helpers) - Bug 19369 (Query pagination to SQL::Abstract) - Bug 19370 (Query order by to SQL::Abstract) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 59

[Bug 20567] New: "Holds per record (count)" limit is not enforced after item is captured for hold
by bugzilla-daemon＠bugs.koha-community.org 21 May '20

21 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20567 Bug ID: 20567 Summary: "Holds per record (count)" limit is not enforced after item is captured for hold Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 74042 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=74042&action=ed… Multiple holds on one item record in staff client "Holds per record (count)" limit is not enforced after an item on the record is captured for hold and moves from Pending to Waiting Pickup status. At this point it is possible to place another hold on that record in violation of the "Holds per record (count)" setting. I was able to replicate this behavior with the following steps: 1. Set "Holds per record (count)" to 1 for your patron category/item type rule 2. Create a record and add at least two items, making sure the MARC and Item Koha Item Type is filled in 3. Place a hold on the record for a patron 4. Check in one of the items and confirm/transfer/capture the hold for the patron 5. Place a second hold on the same record for the same patron In either Staff or Opac the second hold on this bib is allowed after the first hold moves to Waiting for Pickup status. I think that this problem is very closely related to bugzilla 17978 and or 15404, but I did not see a specific mention of the "Holds per record (count)" limit upon perusal of those bugs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31