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

[Bug 19178] New: Remove outdated sms* scripts
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19178 Bug ID: 19178 Summary: Remove outdated sms* scripts 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Files in the sms directory are outdated and should be removed: - sms_listen.pl - sms_listen_windows_start.pl - sms.pl --------- >From the mailing list: Hi all, I’m just going through the Koha codebase and making sure everything compiles, and I stumbled upon sms/sms_listen_windows_start.pl: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=sms/sms_listen_wi… It looks like it’s a script for Windows, which the community doesn’t remotely support, plus the code doesn’t really make any sense. ./sms/sms_listen.pl also looks like garbage to me. So does ./sms/sms.pl. Everyone reckon it would be safe to remove both of these scripts from Koha? Looks like they’re about 7+ years old… David Cook -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 19029] New: Move the clone button and implement a security question on smart-rules.tt
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19029 Bug ID: 19029 Summary: Move the clone button and implement a security question on smart-rules.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 19027 When users create a circulation rule which they want to be applied to multiple library branches they will click "Standard rules to all libraries" (from bug 19027) However they may accidentally hit the 'clone' button, to clone the rule to a specific library. When the rule is being applied to all libraries with the 'standard' option then the only use case for clicking the 'clone' button would be to then adapt the rule in that specific library. This is not a common use case and users may accidentally hit the 'clone' button without understanding it fully. Therefore this bug report suggests that a security question be displayed to be ask the user if they are sure about cloning the rule to a specific library. Additionally the clone button should be moved to a slightly different placement on the page. Can we please have some feedback on this idea Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19027 [Bug 19027] Circulation rules: Better wording for standard rules for all libraries -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 18118] New: Unexpected behaviour with 'GoogleOpenIDConnect' and ' OpacPublic' syspref combination
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18118 Bug ID: 18118 Summary: Unexpected behaviour with 'GoogleOpenIDConnect' and 'OpacPublic' syspref combination Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org When 'OpacPublic' is set to NO, a successful login will load the main OPAC page (opac-main.pl), that's good, correct and expected The bug is that with 'OpacPublic' set to OFF and 'GoogleOpenIDConnect' set ON - a successful login redirects the user to their account page (opac-user.pl) not the main OPAC page, that's unexpected and bad -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 17214] New: Add item in LIST by Record number
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17214 Bug ID: 17214 Summary: Add item in LIST by Record number Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: gmcharlt(a)gmail.com Reporter: mishravk79(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Once the LIST is created in Koha you can add item in that by barcode but is there any option to add item by record number because if there is no barcode assigned to the item how it can be added to the list? For example in case of remotely available resources like e-book/e-journals where library may enter only bibliographic details. -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 17334] New: members-update.pl should show timestamp
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17334 Bug ID: 17334 Summary: members-update.pl should show timestamp 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the management of patron updates, it seems logical that the requests should show the timestamp of when the request was placed. Yes, you can look this up in a report, but this should be a basic feature of managing requests. Ideally, it should show on the same line as the patron name. Probably something like "Requested: 2016-09-05" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 17477] New: Duplicating a subfield yields an empty subfield tag
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17477 Bug ID: 17477 Summary: Duplicating a subfield yields an empty subfield tag Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 17152 made the subfield cloning function delete the contents of the cloned subfield. But it makes the subfield tag empty too, and this is causing troubles for people re-opening the records for edition. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 19165] New: When adding from a staged file order discounts are not passed into C4:: Acquisitions::populate_order_with_prices
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19165 Bug ID: 19165 Summary: When adding from a staged file order discounts are not passed into C4::Acquisitions::populate_order_with_prices Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: christophe.croullebois(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Discounts are not stored in $orderinfo before passing to populate prices -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 18282] New: OpenAPI operationId must be unique
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18282 Bug ID: 18282 Summary: OpenAPI operationId must be unique 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: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org operationId has the following documentation: "Unique string used to identify the operation. The id MUST be unique among all operations described in the API." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 18290] New: Fix t/db_dependent/Koha/Object.t, Mojo::JSON:: Bool is a JSON::PP::Boolean :)
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18290 Bug ID: 18290 Summary: Fix t/db_dependent/Koha/Object.t, Mojo::JSON::Bool is a JSON::PP::Boolean :) 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: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 19119] New: Remove t/db_dependent/api/v1/swagger/definitions.t
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '17

27 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19119 Bug ID: 19119 Summary: Remove t/db_dependent/api/v1/swagger/definitions.t Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org While it might have seemed a good idea to have such a test, I find it useless as-is, because there's no obvious reason why we would expose our model on the API spec while it is just user-facing and not a technical explanation on how we do things inside our codebase. A good example of this could be bug 18120, in which it is obvious that some attribute names are misleading or the attributes themselves need to be stripped out of the object for exposing on the API. There can be ways of doing this two operations (i.e. removing/adding attributes, and renaming) without handling it on the controller as those patches do. But in any case, there's no need for definitions.t. We could have a gentle 'warning' in the QA tools in case of a column being added to the DB structure and not to the corresponding endpoint, but it has to be a soft requirement IMO. -- You are receiving this mail because: You are watching all bug changes.

1 10