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

[Bug 17253] New: Koha::AuthorisedValues - Remove GetKohaAuthorisedValues
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '16

15 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17253 Bug ID: 17253 Summary: Koha::AuthorisedValues - Remove GetKohaAuthorisedValues Change sponsored?: --- Product: Koha Version: master 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 24

[Bug 17294] New: reserves_stats.pl is not plack safe
by bugzilla-daemon＠bugs.koha-community.org 15 Dec '16

15 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17294 Bug ID: 17294 Summary: reserves_stats.pl is not plack safe Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal 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 Blocks: 7172 Variable "$ccodes" is not available at /home/koha/src/reports/reserves_stats.pl line 337. Variable "$locations" is not available at /home/koha/src/reports/reserves_stats.pl line 338. Variable "$itemtypes" is not available at /home/koha/src/reports/reserves_stats.pl line 339. Variable "$Bsort1" is not available at /home/koha/src/reports/reserves_stats.pl line 344. Variable "$Bsort2" is not available at /home/koha/src/reports/reserves_stats.pl line 350. Variable "@patron_categories" is not available at /home/koha/src/reports/reserves_stats.pl line 356. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7172 [Bug 7172] Omnibus for Plack variable scoping problems -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 16815] New: API routes to list, create, update, delete holds need permissions
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16815 Bug ID: 16815 Summary: API routes to list, create, update, delete holds need permissions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The REST api for holds CRUD should require hold permissions! I think it needs reserveforothers and it's subpermissions implemented. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 17419] New: Fix more confusion between smsalertnumber and mobile
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17419 Bug ID: 17419 Summary: Fix more confusion between smsalertnumber and mobile Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com members/moremember.pl will set mobile number as smsalertnumber in template if smsalertnumber is not defined. This will cause incorrect display for SMS number in patron's Details-tab. This confusion between smsalertnumber and mobile is already fixed in Bug 14683, but members/moremember.pl was not fixed yet. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 17392] New: opac/svc/overdrive_proxy is not plack safe
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17392 Bug ID: 17392 Summary: opac/svc/overdrive_proxy is not plack safe Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When running under plack the parameters in the url passed to overdrive are separated by semi-colons as opposed to ampersands example, dumping $query->query_string from /opac/svc/overdrive_proxy under plack we have: 'q=howard%20wigglebottom;limit=1;offset=0' If the page is excluded from plack we get: 'q=howard%20wigglebottom&limit=1&offset=0' You can test in a rest client, the first will return spurious results, searches in opac will report one number of hits, clicking the link for results will return none or a different number of hits from overdrive Tried removing the qw(-oldstyle-urls) from the script but it had no effect, though without that when excluded from plack things also don't work This is verified under master and 3.22 under plack -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 16444] New: C4::Tags is not plack safe
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16444 Bug ID: 16444 Summary: C4::Tags is not plack safe Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal 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 Depends on: 7172 C4::Tags use a package variable to cache the pref TagsExternalDictionary, it's not needed and not safe. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7172 [Bug 7172] Omnibus for Plack variable scoping problems -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 17484] New: Searching with date range limit (lower and upper) does not work
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17484 Bug ID: 17484 Summary: Searching with date range limit (lower and upper) does not work Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P2 Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org When you do a search through advanced search with a publication date range limit (like 2002-2006 by example) according the example given in the legend, you get no results even if there must be ones. It's ok for one-bound limits like -2002 or 2006-, but for two bounds limits you must wrap the hypen with spaces to get results, which is not consistent with the legend. Whitout spaces the query sent to zebra is done by opac-search.pl script like this : kw,wrdl,rtrn=MY_SEARCH and yr,st-numeric,ge=2002 and yr,st-numeric,le=2006 Seems that Zebra does not understand that syntax. With spaces, it is turned out like this : kw,wrdl,rtrn=MY_SEARCH and yr,st-numeric=2002 - 2006 and it works. It also works without spaces if you run a ccl query directly from the opac : ccl=kw,wrdl,rtrn=archipel and yr,st-numeric=2002-2006 May be it's a question of zebra config or zebra version, not completely sure of this (cf bug 12897), I propose this patch nevertheless as an eventuel solution. Test plan : 1) do a search from advanced search with some results 2) redo the same putting a date limit with two bounds separated by an hypen without spaces : you get no results 3) apply the patch 4) redo stage 2 : you get the expected results -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 15803] New: Koha::AuthorisedValues - Remove GetAuthorisedValueCategories
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15803 Bug ID: 15803 Summary: Koha::AuthorisedValues - Remove GetAuthorisedValueCategories Change sponsored?: --- Product: Koha Version: master 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 Depends on: 15801 Blocks: 15799 The subroutine C4::Koha::GetAuthorisedValueCategories just retrieves all the authorised value categories. We already have a method in the Koha::AuthorisedValues module to do this job, let's use it! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15799 [Bug 15799] Move authorised values related code into Koha::AuthorisedValues - part 2 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15801 [Bug 15801] Move the framework related code to Koha::BiblioFramework[s] - part 2 -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 17420] New: record export fails when itemtype on biblio
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17420 Bug ID: 17420 Summary: record export fails when itemtype on biblio Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In Tools, Export data, you can export with a filter on item type. When item type is on biblio record, you get the error : export.pl: DBIx::Class::ResultSet::next(): Unknown column 'biblioitems.itemtype' in 'where clause' at /home/koha/src/Koha/Objects.pm line 150 Looks like its because this code use to be a SQL Select and is now a DBIx call : export.pl: DBIx::Class::ResultSet::next(): Unknown column 'biblioitems.itemtype' in 'where clause' at /home/koha/src/Koha/Objects.pm line 150 -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 17086] New: Reword borrowers to patrons in Swagger tags for holds
by bugzilla-daemon＠bugs.koha-community.org 14 Dec '16

14 Dec '16

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17086 Bug ID: 17086 Summary: Reword borrowers to patrons in Swagger tags for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Some routes for holds have tags called "borrowers". We should use "patrons" instead in order not to have both (endpoints for patrons already add "patrons"). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13