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

[Bug 16892] New: Add automatic patron registration via OAuth2 login
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '20

01 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16892 Bug ID: 16892 Summary: Add automatic patron registration via OAuth2 login Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: mtompset(a)hotmail.com Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org If a patron's email address is authenticated by Google, and is not registered as a primary email address, automatically register the patron to allow login access. -- You are receiving this mail because: You are watching all bug changes.

1 79

[Bug 17016] New: Button to clear all fields in budget planning
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '20

01 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17016 Bug ID: 17016 Summary: Button to clear all fields in budget planning Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently there is an auto-fill button, but if you want to undo this, now all fields are filled. There should be a clear option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 16764] New: Update printers administration page
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '20

31 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16764 Bug ID: 16764 Summary: Update printers administration page Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/admin/printers.pl OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I hear some libraries do use it, so why not bring the printers administration page up to date? I have a patch to add DataTables, Font awesome icons, and plugin-validated forms. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 18364] New: LOCK and UNLOCK are not transaction-safe
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '20

30 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18364 Bug ID: 18364 Summary: LOCK and UNLOCK are not transaction-safe Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major 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 >From the MySQL doc: "LOCK TABLES is not transaction-safe and implicitly commits any active transaction before attempting to lock the tables." -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 17915] New: warning in Stage MARC records for import when matching rule with offset
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '20

27 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17915 Bug ID: 17915 Summary: warning in Stage MARC records for import when matching rule with offset 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 When using Stage MARC records for import with a matching rule where an offset is defined, the input string may be empty or shorter than the offset. This generated a warning : stage-marc-import.pl: substr outside of string at /home/koha/src/C4/Matcher.pm line 822. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 17221] New: orphan comma in shelf browser
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '20

18 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17221 Bug ID: 17221 Summary: orphan comma in shelf browser Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org Created attachment 54997 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54997&action=ed… screenshot of bug Example screenshot attached, here's the bib record in our catalog: https://library.cca.edu/cgi-bin/koha/opac-detail.pl?biblionumber=21729&shel… Basically, since starting_homebranch is null in the template file, nothing is printed out, but the next IF condition wrongly assumes that the first must have been true and prints out a comma before it's text string. Steps to recreate: - in settings, set ShelfBrowserUsesHomeBranch to "Don't Use" - set ShelfBrowserUsesLocation to "Use" - visit an item, click the "Browse shelf" link in the Holdings' tab's Call Number column - note the extraneous comma in the <h5> tag that appears Patch coming shortly, it appears that simply adding an additional condition around the comma itself should resolve this problem. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 18230] New: Generate Koha::Patron:: Modification verification_token in ->new
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '20

17 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18230 Bug ID: 18230 Summary: Generate Koha::Patron::Modification verification_token in ->new 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: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Currently verification_token is generated outside of the class. Move this logic into Koha::Patron::Modification->new. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 17424] New: REST API: Preference to control access to own objects without permission
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '20

17 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17424 Bug ID: 17424 Summary: REST API: Preference to control access to own objects without permission 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 Introduce a preference to enable/disable access to own objects for patron's without required permissions. Bug 14868 added "allow-owner" parameter that allows owner of the object to perform operations on themselves even if they do not have required permissions to otherwise do so (e.g. get own patron data or renew your own checkouts even if you don't have borrowers/circulating permissions). This means patrons can perform basic OPAC operations via REST API. However, there should be an option to disable this functionality; as Katrin pointed out in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895#c43 , > I can imagine both happening: > - libraries wanting to shut down any OPAC account functionality, but still > be able to renew in staff, so the circulation conditions are set up this > way. In this case, there should be a way to lock the API (opacuserlogin > might be a way) > - libraries shutting down the OPAC, because they use something else like an > external discovery layer. In this case they'd still want to use the API, but > might turn off the OPAC as far as possible. I propose a system preference for enabling/disabling access to own objects in REST API. This way libraries can disable opacuserlogin and any OPAC API functionality with the new preference. In the second case, libraries can disable opacuserlogin but still allow OPAC functionality via REST API. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 17479] New: REST API: Save information on owner access
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '20

17 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17479 Bug ID: 17479 Summary: REST API: Save information on owner access 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 There are two ways of accessing a resource via REST API; either: - you have the required permission - you do not have the permission but you are owner of the object, e.g. you want to GET your own patron information In many cases we want to perform additional operations if the user is accessing his own object. Usually this additional operation is checking a system preference. Example: Patron wants to update his own patron information via REST API. We have to check OPACPatronDetails system preference for this. If it is on, we should forward the changes for approval from a librarian. Currently, in controller, we can check this opac-like access by checking that the user does not have permissions and that the patron he is accessing is himself. This would require another haspermission() call. Instead, we could set a flag into $c->stash in Koha/REST/V1.pm in the case of ownership access. After this, in controller, we only need to check $c->stash for this flag. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 16147] New: OpacItemLocation and not for circulation Item types
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '20

15 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16147 Bug ID: 16147 Summary: OpacItemLocation and not for circulation Item types Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ed.veal(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If you set the OpacItemLocation to anything other than "Call number only" the call number is repeated on the Location line for all items with item types that don't circulate. <xsl:if test="items:itemcallnumber != '' and items:itemcallnumber and $OPACItemLocation='callnum'"> [<span class="LabelCallNumber">Call number: </span><xsl:value-of select="items:itemcallnumber"/>]</xsl:if> <xsl:if test="items:itemcallnumber != '' and items:itemcallnumber"> [<span class="LabelCallNumber">Call number: </span><xsl:value-of select="items:itemcallnumber"/>]</xsl:if> Ed -- You are receiving this mail because: You are watching all bug changes.

1 6