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

[Bug 21893] New: Batch Modify button in report with itemnumber only includes titles in first page of results
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21893 Bug ID: 21893 Summary: Batch Modify button in report with itemnumber only includes titles in first page of results Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 19233 added the ability to push report results into item batch modification when the report includes a column of itemnumbers. However, only items on the first page of item results will be pushed to batch modification -- if the report results include 1200 items and the report page is set to display 1000 rows per page, only the first 1000 items will be batch modified. Koha is clear that it's only modifying those 1000 items, but it still creates extra work, especially since the Rows Per Page dropdown on report results doesn't include an option for All. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 25393] New: Create separate No Automatic Renewal Before rule
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25393 Bug ID: 25393 Summary: Create separate No Automatic Renewal Before rule Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Koha currently applies the No Renewal Before value to both manual and automatic renewal. Libraries that use a mix of manual and automatic renewal often don't want the same behavior between them - they want manual renewal to be possible earlier in the checkout even if automatic renewal doesn't happen until closer to the due date. We could address this by maintaining separate No Renewal Before values. For what it's worth, we already acknowledge this possibility when leaving No Renewal Before blank. For a manual renewal, no value in No Renewal Before allows renewal immediately. For an automatic renewal, no value in No Renewal Before does not allow renewal until the due date. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 28980] New: Add temporary passwords which must be reset after first login
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '24

29 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Bug ID: 28980 Summary: Add temporary passwords which must be reset after first login 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if passwords could be marked as temporary, so that staff users could set temporary passwords for borrowers, and those borrowers would have to reset their password on their 1st successful login. This would prevent staff users from re-using the same simple password across a range of users and having those same simple passwords persist over time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 29046] New: Allow libraries to specify email order for "AutoEmailPrimaryAddress"
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '24

28 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29046 Bug ID: 29046 Summary: Allow libraries to specify email order for "AutoEmailPrimaryAddress" 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment, Koha::Patron->first_valid_email_address is hard-coded to go "email", "emailpro", and then "B_email". Libraries should be able to specify their own preference (at least since historically email was "Home" and emailpro was "Work" and many non-public library Koha databases would rather privilege emailpro over email). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 21638] New: Allow reporting of holds cancelled by cancel_expired_holds.pl and ExpireReservesMaxPickUpDelay
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '24

26 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21638 Bug ID: 21638 Summary: Allow reporting of holds cancelled by cancel_expired_holds.pl and ExpireReservesMaxPickUpDelay Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When ExpireReservesMaxPickUpDelay is set to Allow, waiting holds are automatically cancelled by cancel_expired_holds.pl. But, generally, libraries still need to physically remove those items from their hold shelf and check them in to guarantee there are not pending holds or transfers to be triggered. A report to identify these items is imperfect and cannot definitively distinguish a hold cancelled by the cron from a hold cancelled by an employee. Bug 14134 established behavior that displays holds which *will* be cancelled by the next run of the cron on the "holds over" tab in Holds Awaiting Pickup, but doesn't allow staff to see which holds have already been cancelled. It'd be great if the cron could email a list of cancelled holds. Additionally, reporting would be improved by the introduction of a new value in old_reserves.found for items cancelled by the cron (maybe E for expired). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26317] New: Misleading choices from reports error when runtime parameter is named incorrectly
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '24

26 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26317 Bug ID: 26317 Summary: Misleading choices from reports error when runtime parameter is named incorrectly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: - create a new report from SQL - enter "SELECT <<whatever|whatever>>" and try to save - Get an error "Errors found when processing parameters for report: whatever: The authorized value category (whatever) you selected does not exist." - Error provides two options, "Save Anyway" or "Edit SQL" - Click Edit SQL, get taken to an empty report "Edit SQL" wants to take you back to the previously saved version of your report. But if you've ended up at this error from a brand new report that's never been saved, then the "Edit SQL" button is going to take you to a blank report, trashing whatever you've just written. If we can't retain that SQL through the error on an unsaved report, then we should remove the Edit SQL button when working with a report that hasn't been saved yet. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 28404] New: Improve calendar tool management
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '24

26 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28404 Bug ID: 28404 Summary: Improve calendar tool management Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org 1. It would be great if libraries could delete holidays from the calendar tool. Because they can’t be deleted by our library we end up with lots of old holidays in the table and sometimes incorrect entries. 2. Holidays display in date ascending order which means the oldest ones are listed first. When you have a long list of old holidays this means you have to do a lot of scrolling to get to the current year. It would be very useful if the holidays could sort in year descending order and within each year the dates would sort in date ascending order. This would put the most current dates at the top of the table for quicker viewing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 21348] New: Add ability to export and import plugin data
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '24

26 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21348 Bug ID: 21348 Summary: Add ability to export and import plugin data Change sponsored?: --- Product: Koha Version: unspecified 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We could possibly add a way to download a specific plugin's data from plugin_data in some arbitrary file format, and also add a facility to re-insert that data back into the plugin_data table. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 21309] New: Add flag to change password
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '24

23 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21309 Bug ID: 21309 Summary: Add flag to change password Change sponsored?: --- Product: Koha Version: unspecified 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 We should add a flag to patron accounts that, if checked, would require the patron to sign in to their account and change their password. This option could incorporate the following functionality: * Allow patron to sign in with old password then prompt for a new password. * E-mail patron notifying them with the need to change. * When active, it would block checkouts and sip authentication until done. * Anytime a password is changed in the account, whether staff side or opac, the change would clear the flag in the patron account. * Date of change should be time stamped. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 26681] New: Clone the buttons for 'Add Item', 'Add & Duplicate' and 'Add Multiple Copies of this Item' to top of item form on additem.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Aug '24

23 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26681 Bug ID: 26681 Summary: Clone the buttons for 'Add Item', 'Add & Duplicate' and 'Add Multiple Copies of this Item' to top of item form on additem.pl Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Sometimes I only need to make a quick edit to an item record but then I have to scroll all the way down to the bottom of the form to click the add item/save button. It would be helpful if the 'Add Item', 'Add & Duplicate' and 'Add Multiple Copies of this Item' buttons that appear at the end of the form could also be included at the top of the form because it would save unnecessary scrolling and make cataloging more efficient. Our solution at the moment is to use this jQuery: $("#cat_additem.cat #addsingle").clone().insertAfter('#additema'); $("#cat_additem.cat #add_multiple_copies").clone().insertAfter('#addsingle'); $("#cat_additem.cat #f > fieldset.action").clone().insertAfter('#edititem'); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10