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

[Bug 17740] New: Add the Koha::Patron->get_holds method
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '17

08 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17740 Bug ID: 17740 Summary: Add the Koha::Patron->get_holds method Change sponsored?: --- Product: Koha Version: unspecified 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 13

[Bug 18321] New: One more checkouts possible than allowed by rules
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '17

02 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18321 Bug ID: 18321 Summary: One more checkouts possible than allowed by rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It is possible to have one more checkouts than allowed by rules. To recreate: - Delete all rules in 'Circulation rules and fines'. - Set a Default limit by patron category, e.g. Student 2 current checkouts , 2 on-site-chekouts. - Checkout to a student until the limit is reached (in this case: 2) - Try a 3rd checkout; it is possible (should not) - Try a 4th checkout: No longer possible. Message says: "Too many checked out. 3 checked out, only 2 are allowed." Expected: Message should trigger with 3rd checkout, saying: "Too many checked out. 2 checked out, only 2 are allowed." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 16746] New: Can not find duplicated authorities cataloguing a new one
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '17

01 Nov '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16746 Bug ID: 16746 Summary: Can not find duplicated authorities cataloguing a new one 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: juan.sieira(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Can not find duplicated authorities cataloguing a new one, due to the new version of SimpleSearch -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 17380] New: Cannot edit authorities with authtypecode = default
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '17

30 Oct '17

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17380 Bug ID: 17380 Summary: Cannot edit authorities with authtypecode = default Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: joachim.ganseman(a)ehb.be QA Contact: testopia(a)bugs.koha-community.org Created attachment 55947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=55947&action=ed… Example: after trying to merge PERSO_NAME and TOPIC_TERM "Rossini", the PERSO_NAME record is now authtypecoded as "default" and cannot be edited anymore Editing authorities whose authtypecode is not set to a common value is not possible in Koha 16.05 . This occurs e.g. after trying to (accidentally) merge a PERSO_NAME and TOPIC_TERM authority into one. The resulting authority will have its authtypecode set to "default". Upon trying to correct such an authority, it turns out to be impossible to edit the said authority. An error very similar to 'Can't call method "authtypecode" on an undefined value' appears instead of the editor. This occurs even when there are no authority frameworks defined (i.e. all in the default frameworks), in Koha 16.05 on Debian. -- You are receiving this mail because: You are watching all bug changes.

1 56

[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 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