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

[Bug 23082] New: Fatal error editing a restricted patron
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '19

05 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23082 Bug ID: 23082 Summary: Fatal error editing a restricted patron Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: frinaudo(a)infocpt.com.ar QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Para reproducir el error, se debe tener un socio con una restricción, ya sea manual o automática: 1- Editar el socio 2- Marcar el checkbox "eliminar" en la restricción 3- Guardar En ese momento aparece un internal server error En los logs el mensaje es: ==> /var/log/koha/eco/plack-error.log <== No property remove_debarment for Koha::Patron La restricción se elimina, pero se debe abrir una ventana de koha nuevamente. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 23429] New: ilsdi.pl GetRecords documentation does not match output
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '19

04 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23429 Bug ID: 23429 Summary: ilsdi.pl GetRecords documentation does not match output Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: J.P.Knight(a)lboro.ac.uk QA Contact: testopia(a)bugs.koha-community.org The ILS-DI GetRecords self generated documentation no longer matches up with the output that the script generates. It probably should. :-) For example, the documentation says that the <item> element contains a <date_due> element. This was the case back in 16.x versions of Koha, but on our production 18.11.04 we no longer get this field, but we do get an <onloan> field in item instead (which luckily serves the same purpose as we need - we just need to know if each item is on loan or not). Here's the example format for the <item> part of the record generated by http://ourserver/cgi-bin/koha/ilsdi.pl?service=Describe&verb=GetRecords <items> <item> <biblioitemnumber>1</biblioitemnumber> <withdrawn>0</withdrawn> <holdingbranchname>Bibliothèque Jean Prunier</holdingbranchname> <notforloan>0</notforloan> <replacementpricedate>2008-08-20</replacementpricedate> <itemnumber>1</itemnumber> <location>Secteur Adulte</location> <itemcallnumber>R ABE</itemcallnumber> <date_due></date_due> <itemlost>0</itemlost> <datelastseen>2008-08-20</datelastseen> <homebranch>BIB</homebranch> <homebranchname>Bibliothèque Jean Prunier</homebranchname> <biblionumber>1</biblionumber> <holdingbranch>BIB</holdingbranch> <timestamp>2008-08-20 17:15:51</timestamp> <damaged>0</damaged> <cn_sort>R_ABE</cn_sort> <dateaccessioned>2008-08-20</dateaccessioned> </item> </items> And here's what we get out for an actual search: <items> <item> <onloan>2019-10-01</onloan> <holdingbranch>MAINLIB</holdingbranch> <location>MAIN</location> <datelastborrowed>2019-07-18</datelastborrowed> <biblioitemnumber>526315</biblioitemnumber> <permanent_location>MAIN</permanent_location> <datelastseen>2019-07-18</datelastseen> <withdrawn>0</withdrawn> <itype>LONG</itype> <notforloan>0</notforloan> <biblionumber>526315</biblionumber> <itemnumber>847332</itemnumber> <price>22.17</price> <dateaccessioned>2016-09-13</dateaccessioned> <issues>10</issues> <homebranchname>Main Library</homebranchname> <homebranch>MAINLIB</homebranch> <timestamp>2019-07-18 17:03:03</timestamp> <cn_sort>005_550000000000000_SPS_BRA</cn_sort> <itemlost>0</itemlost> <renewals>28</renewals> <barcode>040444587X</barcode> <damaged>0</damaged> <replacementpricedate>2018-02-01</replacementpricedate> <itemcallnumber>005.55 SPS/BRA</itemcallnumber> <holdingbranchname>Main Library</holdingbranchname> </item> </items> Note the <date_due></date_due> in the example is missing from the real output, which has <onloan>...</onloan> instead. I guess we need to decide if the documentation is just out of date with the code, or if the code should be generating things it isn't any more. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 22128] New: koha-remove fails mysql ERROR 1133 (42000) at line 2: Can't find any matching row in the user table
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '19

04 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22128 Bug ID: 22128 Summary: koha-remove fails mysql ERROR 1133 (42000) at line 2: Can't find any matching row in the user table Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: Heinrich.Hartl(a)email.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Target Milestone: --- The script fails in in a GRANT command - the user does not exist This probably is due to changed behaviour of mysql 5.7ff From https://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-overview: Note If an account named in a GRANT statement does not already exist, GRANT may create it under the conditions described later in the discussion of the NO_AUTO_CREATE_USER SQL mode. It is also possible to use GRANT to specify nonprivilege account characteristics such as whether it uses secure connections and limits on access to server resources. However, use of GRANT to create accounts or define nonprivilege characteristics is deprecated as of MySQL 5.7.6. Instead, perform these tasks using CREATE USER or ALTER USER. In my case mysql hosted a koha 16.11 database upgraded to 18.5 and the only existing user was koha_library@%. There was no user koha_library@localhost. mysql was running in the version (> 5.7)supplied with ubuntu 16.4 (Xenial). My solution to the problem was commenting out two lines in the script. diff /usr/sbin/koha-remove /usr/sbin/koha-remove_ori 71c71 < # GRANT USAGE ON \`koha_$name\`.* TO \`koha_$name\`@\`$mysql_hostname\`; --- > GRANT USAGE ON \`koha_$name\`.* TO \`koha_$name\`@\`$mysql_hostname\`; 73c73 < # DROP USER \`koha_$name\`@\`$mysql_hostname\`; --- > DROP USER \`koha_$name\`@\`$mysql_hostname\`; hhl@koha-VM-dev:~ > For a general solution the koha-remove script should be made more resilient and should not use deprecated mysql features. Since I am only very occasionally dealing with mysql and moreover I have no knowledge which user(s) have been used for koha instances in the past it is beyond my skills to define the proper revision of the script. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 20389] New: Indexing fields concatenated
by bugzilla-daemon＠bugs.koha-community.org 04 Nov '19

04 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20389 Bug ID: 20389 Summary: Indexing fields concatenated Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: claire.hernandez(a)biblibre.com I would like to be able to specify multiple subfields to index as a value in a field. The subfields must be concatenated. Example 1: Author in unimarc in an authority: 700 1 $a Bermès $b Emmanuelle I could record a fields in mappings: author: "700a. .700b" I would have in the field indexed: author: "Emmanuelle Bermès" Example 2: in mappings: author: "700b., .700a" would give: author "Bermès, Emmanuelle" With solr, we managed it with indexing plugins. If it is too early for this, we could manage it in mappings configuration maybe. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 23876] New: Holds queue section says it "shows all of the holds at your library" which is not true
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23876 Bug ID: 23876 Summary: Holds queue section says it "shows all of the holds at your library" which is not true Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org We have to change the Holds queue section as it says "This report will show you all of the holds at your library." I talked with Katrin and Nick on IRC and they told me it's more of a "holds to pull" report for large systems or consortia. As of writing this, there is no report that show all of the holds at your library. There is a demand for this (see bug #19749), but nothing has been done so far. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 22846] New: Remove warning in the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22846 Bug ID: 22846 Summary: Remove warning in the manual about needing StaticHoldsQueueWeight to use RandomizeHoldsQueueWeight Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- The paragraph in https://koha-community.org/manual/18.11/en/html/systempreferences.html#stat… saying Leaving StaticHoldsQueueWeight empty is contraindicated at this time. Doing so will cause the build_holds_queue script to ignore RandomizeHoldsQueueWeight, causing the script to request hold fulfillment not randomly, but by alphabetical order. is talking about (without mentioning it by number) bug 8562, which was fixed in bug 12803 comment 14. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 23556] New: MARC bibliographic framework test (admin/checkmark.pl) does not consider item-level_itype system preference
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23556 Bug ID: 23556 Summary: MARC bibliographic framework test (admin/checkmark.pl) does not consider item-level_itype system preference Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com MARC bibliographic framework test does not check item-level_itype system preference, so it reports an error on biblioitems.itemtype not mapped and not related to itemtype authorised values if itemtype is at item level -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 22304] New: Bugzilla blocked by UK mobile network EE
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22304 Bug ID: 22304 Summary: Bugzilla blocked by UK mobile network EE Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: Other OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: emma.perks(a)heartofengland.nhs.uk Target Milestone: --- Created attachment 84957 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=84957&action=ed… EE user screenshots - cannot connect to Bugzilla Hello, The bugs.koha-community.org website is blocked by mobile network EE in the UK. When trying to access it using 4G or mobile data provided by EE, the site is blocked due to the security certificate on Bugzilla. One person in the EE community thinks this is caused by EE not doing browser fallback. Several users have tried and all have the same problem independent of hardware. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 23834] New: Add default ESLint configuration
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23834 Bug ID: 23834 Summary: Add default ESLint configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW 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 Blocks: 23833 Default configuration proposed when the ESLint coding guideline was voted on: { "env": { "browser": true, "jquery": true }, "extends": "eslint:recommended", "rules": { "indent": [ "error", 4 ], "linebreak-style": [ "error", "unix" ], "semi": [ "error", "always" ] } } Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23833 [Bug 23833] [Omnibus] JavaScript should conform to coding guidelines recommended by ESLint -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 23841] New: Add a button to get from an item to it's biblio record
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '19

03 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23841 Bug ID: 23841 Summary: Add a button to get from an item to it's biblio record Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fraktik(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think it would be handy to have some way how to get from detailed list of items as is this: ../cgi-bin/koha/catalogue/moredetail.pl?biblionumber=61855&itemnumber=66778 to it's biblio "parent": ../cgi-bin/koha/catalogue/detail.pl?biblionumber=61855 TL&DR: Most of the time, librarians arrive to the item page trough it's biblio, but this is not a rule (for example many time we just click on barcode in Circulation module) and simple "back" in browser do not bring person much closer to desired record. I am open to suggestion about form how to do this, but only way I found (for staff without right to edit biblio) till today is to delete parameter "&itemnumber=66778" from URL - and that is not something, I want to teach my staff... Librarians, which are allowed to edit records, can push "Edit" rollout button and then "Edit Record", jump to the Editing, where just "Cancel" button bring them right where they need to be. Simple button with label "Record" (Or "Biblio") in one line with "New", "Edit", "Save", "Add to", "Print" and "Place hold" would be nice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14