June 2019 - Koha-bugs - lists.koha-community.org

[Bug 19498] New: Translatability: Get rid of [% block_budget.count %] and similar
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '19

19 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19498 Bug ID: 19498 Summary: Translatability: Get rid of [% block_budget.count %] and similar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Examples: [% block_budget.count %] fund(s) are attached to this budget. [% count %] item(s) are attached to this record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20743] New: Update two-column templates with Bootstrap grid: Administration part 7
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '19

19 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20743 Bug ID: 20743 Summary: Update two-column templates with Bootstrap grid: Administration part 7 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: 20668 Blocks: 20654 This patch will convert the last of the administration templates to use the Bootstrap grid: - printers.tt - searchengine/elasticsearch/mappings.tt - smart-rules.tt - sms_providers.tt - sru_modmapping.tt - systempreferences.tt - transport-cost-matrix.tt - usage_statistics.tt Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20654 [Bug 20654] Omnibus: Update two-column templates to use Bootstrap grid https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20668 [Bug 20668] Update two-column templates with Bootstrap grid: Acquisitions part 2 -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 19721] New: Tabulation in the description of a patron category breaks the patron search. Cause : tabs must be escaped in JSON
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '19

19 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19721 Bug ID: 19721 Summary: Tabulation in the description of a patron category breaks the patron search. Cause: tabs must be escaped in JSON Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com === Reproduce === 1. Go to staff: /cgi-bin/koha/admin/categories.pl 2. Edit a category with existing patrons 3. Add a tab in the description here is one to copy for convenience: " " 4. Save the category 5. Go to /cgi-bin/koha/members/members-home.pl 6. Filters → Category → select the just edited one 7. Hit search, just below 8. Then you should see "Processing..." As if the request was still running forever === Cause === In the browser dev tools, we can see that the XRH request to "search" actually comes back. The response seems normal. Except that Firefox warns "SyntaxError: JSON.parse: bad control character in string literal at line 23 column 29 of the JSON data" Which points to our tab. Which invalidates the JSON: https://stackoverflow.com/questions/19799006/unable-to-parse-tab-in-json-fi… > The whitespace characters are: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020). > Whitespace is not allowed within any token, except that space is allowed in strings. === Workaround === Remove the tab from the description of the category. In /cgi-bin/koha/admin/categories.pl One can use the filter in the table (called search). And search for a tab " " to get the "corrupted" ones. === Fix === It seems that we should escape the tabs (and CRs(\r) and LFs(\n)) Or just get rid of them. Another question is where? - Where the category form is processed? - early in the upper layers? (when the request just comes) - or in the lower layers? (if the category is managed by the ORM) - In the database itself with a trigger? - Other ideas? === Going further === How to find which other bugs like this one might cause hard to diagnose issues? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21465] New: Overlaying with Patron Imports cannot be done if user id and cardnumber are the same.
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '19

19 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21465 Bug ID: 21465 Summary: Overlaying with Patron Imports cannot be done if user id and cardnumber are the same. Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the Koha version of 18.05 using the patron import tool, if a patron has the same userid and cardnumber, and a library attempts of overlaying an updated file on patron information into Koha, an error will occur. Test Plan 1. Create patron csv according to the download starter CSV in Koha. 2. Patrons were assigned a card number by the library and this card number was also used for their User ID. 3. Import the Patron CSV into Koha. 4. Adjust this same Patron CSV file adding/updating an address, adding/updating a field of data. 5. Use this new file to import into Koha 6 Choose to match on the cardnumber 7. Choose to overwrite the existing one with this file. 8. Koha will produce an error saying that the userid already in use by another patron. Different Scenario Do Steps 1-5 the same 6. Choose to match on the User Id 7. Choose to overwrite the existing one with this file. 8. Koha will do the overwrite correctly. Libraries do tend to give patrons a cardnumber and also use that as the patron's userid. It would appear that matching on the userid works, however, this should not work this way, it should be able to match on either and produce same results- a successful overlay. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 19364] New: KOHA title search pulls documents with author matches
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '19

18 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19364 Bug ID: 19364 Summary: KOHA title search pulls documents with author matches 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: nikeshn(a)gmail.com Author results also appears when I limit my search to title only. I think it appears because KOHA indexing treats statement of responsibility as part of title. Other ILS systems pull only title matches from tag 245, 505 and 490 etc. We migrated from Millennium to KOHA and Millennium pulls only documents matches the word in title, series etc. For example : melm 245$a Title-cover:w,Title-cover:p,Title-cover:s,Title:w,Title:p,Title:s melm 245$c Author,Author-in-order:w,Author-in-order:p,Author-in-order:s melm 245$9 Cross-Reference:w,Koha-Auth-Number Here KOHA treats 245 $c (statement of responsibility ) as part of title. Live Example : I searched for Shakespeare in Title but document with Shakespeare as an Auhtor also appear in the search result. Please see the link below. https://opac.kustar.ac.ae/cgi-bin/koha/opac-search.pl?idx=ti&q=shakespeare -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 17131] New: Zebra index for Title is too broad
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '19

18 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17131 Bug ID: 17131 Summary: Zebra index for Title is too broad Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 54482 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54482&action=ed… Test file One of the zebra index definitions in marc21/biblios/biblio-koha-indexdefs.xml for Title includes the entire 245 tag:  <index_data_field tag="245"> <target_index>Title:w</target_index> <target_index>Title:p</target_index> </index_data_field> Since 245$c can contain Author, this means that author names will show up in Title searches. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 20366] New: More information about orders linked to subscriptions on "Acquisition details" tab
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '19

18 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20366 Bug ID: 20366 Summary: More information about orders linked to subscriptions on "Acquisition details" tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org On the 'Acquisition detail' tab on bibliographic record, we cant' know if orders are placed on bibliographic or subscription level. It is quite complicated when several subscriptions are attached to this record to have a clear history of the acquisitions. It would be great for order managers if we could have 2 more columns on this tab, one with the 'aqorders.subsciptionid' and one with 'subscription.callnumber'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 19490] New: Add a 'holds' column to the Batch Item Modification Tool
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '19

18 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19490 Bug ID: 19490 Summary: Add a 'holds' column to the Batch Item Modification Tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some librarians would like to know the holds activity for items when using the batch modification tool. We should display a holds count column to the batch item modification tool that will show the number of holds on an item / holds for entire record -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 18723] New: Dot not recognized as decimal separator
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '19

15 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18723 Bug ID: 18723 Summary: Dot not recognized as decimal separator Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org Since we work on 16.11, we can't use dot when we receive orders but only comma (for example : a price 11.25€ will be changed in 1125,00€ after receiving the order). It seems linked to syspref "Currencyformat" because the behaviour is different when we change it from FR to US format (a price 15,43€ will be changed in 15,430.00€). When we worked on 3.20 until this april, we could use both dot and comma when receiving books. This is quite disturbing for staff users because a dot is required when adding an order to a basket, whereas a comma must be used when receiving the book but there is no warning like it exist in the basket. I don't know if it's a similar problem to the "Bug 18186 - Amounts with decimal comma instead of decimal dot breaking payments" about the circulation module. We also work with plack, but even without it, we still have this bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 17359] New: Patron import results use wrong encoding
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '19

15 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17359 Bug ID: 17359 Summary: Patron import results use wrong encoding Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org When using the patron import tool, the summary at the end uses wrong character encoding. Upload a csv with a few fields and include some ü ö ä. To trigger an error, not providing a surname in the file should work, or a non numeric cardnumber. You will see broken Umlauts on the results page. (The imported data is ok, only the summary is not) -- You are receiving this mail because: You are watching all bug changes.

1 46