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

[Bug 18715] New: Enhance Koha feature release change tool by making sysprefs searchable, and announce the new version in staff client with translatable news item
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '20

23 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18715 Bug ID: 18715 Summary: Enhance Koha feature release change tool by making sysprefs searchable, and announce the new version in staff client with translatable news item Change sponsored?: Sponsored Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) 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 Depends on: 18645 Take the bug 18645 new feature and add the following three enhancements: * Display the new sysprefs of the current version in a new tab in the About page for easy future access. * Make version number a search criterion for system preferences through adding a new column 'version' to the 'systempreference' table and including it in the search url * Announcing the new version on the staff client through creating a news item at the end of the installation process, this news item will appear for all libraries. This news item will contain standard text with the release number and links to new features and preferences. Library staff will be able to edit it adding some library specific information. The text will be translated to the language chosen at the start of the installation process. Thanks to Marc Veron for these ideas Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18645 [Bug 18645] Creation of Koha feature release change tool displayed after running Koha update -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 23677] New: Add route to get a bibliographic record
by bugzilla-daemon＠bugs.koha-community.org 20 Mar '20

20 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23677 Bug ID: 23677 Summary: Add route to get a bibliographic record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 20413] New: Remove the "template" system preference
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '20

19 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20413 Bug ID: 20413 Summary: Remove the "template" 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: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This was meant to allow us to have different templates on the staff interface, but this will probably never be used. Could we get rid of the system preference? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 20408] New: Remove the availability facet and filter
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '20

19 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20408 Bug ID: 20408 Summary: Remove the availability facet and filter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Both on staff interface and opac, the availability filter and facet aren't working. This has been an issue for some time. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11677 The feature should be removed until it is fixed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 20414] New: remove COinSinOPACResults system preference and make it always on
by bugzilla-daemon＠bugs.koha-community.org 19 Mar '20

19 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20414 Bug ID: 20414 Summary: remove COinSinOPACResults system preference and make it always on Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: gaetan.boisson(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org This system preference make the results page zotero friendly. It doesn't change anything in the look of the page and is very useful, i cannot see a good reason to leave the choice to the administrators, it should always be on. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 16763] New: Remove the use of "onclick" from record matching rules form
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '20

18 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16763 Bug ID: 16763 Summary: Remove the use of "onclick" from record matching rules form Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/admin/matching-rules.pl?op=edit_matching _rule&matcher_id=X 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, hector.hecaxmmx(a)gmail.com, jonathan.druart(a)bugs.koha-community.org, testopia(a)bugs.koha-community.org Depends on: 16762 Status: Needs Signoff Patch complexity: Small patch Attachment #52499 1 is obsolete: CC: hector.hecaxmmx(a)gmail.com Status: Signed Off Status: Failed QA CC: jonathan.druart(a)bugs.koha-community.org Status: ASSIGNED There are many uses of "onclick" in the record matching rules edit form. These should be removed in favor of defining events in JavaScript. --- Comment #1 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 52499 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52499&action=ed… Bug 16763 - Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. --- Comment #2 from Héctor Eduardo Castro Avalos <hector.hecaxmmx(a)gmail.com> --- Created attachment 53004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=53004&action=ed… [SIGNED-OFF]Bug 16763: Remove the use of "onclick" from record matching rules form This patch revises the record matching rules edit form to remove the use of "onclick" in favor of defining events in JavaScript. Also changed: Custom form validation JS is replaced by use of the built-in validation plugin; Font Awesome icons are added to 'add' and 'remove' links. To test, apply the patch and go to Administration -> Record matching rules. - When adding or editing a record matching rule, the description, match threshold, and record type should be required. - With both match points and match checks, the "add" and "remove" links should work correctly to show a new section with a blank form. "Add" and "remove" links should work correctly whether the form is in a saved state (i.e. the saved data has just been opened for editing), or whether the links have been added to the page as part of an "add" operation. - When adding a match point or a match check, data added in additional entries should be saved correctly. - After removing a match point or match check, the data should be saved correctly. Signed-off-by: Hector Castro <hector.hecaxmmx(a)gmail.com> Works as advertised --- Comment #3 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, if you add a rule without match point and then edit it again to add one, clicking on "Add match point" won't display the form. --- Comment #4 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Jonathan Druart from comment #3) > Owen, if you add a rule without match point and then edit it again to add > one, clicking on "Add match point" won't display the form. Is this what you're describing? 1. Click 'New record matching rule' 2. Fill in all the required fields at the top, but no match points or match checks. 3. Save the rule. 4. Edit the rule you just created. 5. Click the 'Add match point' link --> The Match point 2 form doesn't display? Step 5 works correctly for me, so I'm not sure I understand the problem. --- Comment #5 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Owen, So yes it is displayed, but at the bottom under the "match checks" block. Actually the "match checks" block is contained into the "match points" block when there is no match points. They are 2 different blocks when you add a new rule or edit a rule with match points. --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- Created attachment 54487 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54487&action=ed… Screenshot of step 5 as described in Comment 4 Here's what I see after step 5 as described in Comment 4. Is that what you're seeing? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16762 [Bug 16762] Record matching rules: Remove match check link removes too much -- You are receiving this mail because: You are watching all bug changes.

1 4

[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 18933] New: Unable to set SMS number in OPAC messaging preferences to empty
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '20

18 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18933 Bug ID: 18933 Summary: Unable to set SMS number in OPAC messaging preferences to empty Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This is inconsistent with the Staff Client side, where the SMS number can be set to empty. Also I think that since this is borrower information, it should be their choice whether they provide this info or not and should have the ability to remove it -- You are receiving this mail because: You are watching all bug changes.

1 19

[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