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

[Bug 24455] New: date formatting from JS
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '22

11 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24455 Bug ID: 24455 Summary: date formatting from JS Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: agustinmoyano(a)theke.io Reporter: agustinmoyano(a)theke.io QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com API calls in OPAC brings raw JSON. We need a way to format data into the configured date from JS. -- You are receiving this mail because: You are watching all bug changes.

1 80

[Bug 23222] New: Fix DISABLE/ENABLE plugin label in plugins home
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '22

11 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23222 Bug ID: 23222 Summary: Fix DISABLE/ENABLE plugin label in plugins home Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: agustinmoyano(a)theke.io QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Fix bug introduced in bug 21073 When you install a plugin, it shows as disables, even though it's enabled in database. Before 21073 that flag was called "enabled", after that bug it is called "is_enabled", but tt was never updated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 26498] New: Add option to set a default expire date for holds at reservation time
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '22

11 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26498 Bug ID: 26498 Summary: Add option to set a default expire date for holds at reservation time 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently, when placing a hold the default is to leave the expiry date empty. It would be useful to have the option to set a default delay via a system preference such that if the patron/staff placing the hold doesn't fill the expire date, we set a default instead of leaving the hold without an expiration date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 29369] New: Use Flatpickr in dateaccessioned cataloging plugin
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '22

10 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29369 Bug ID: 29369 Summary: Use Flatpickr in dateaccessioned cataloging plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: david(a)davidnind.com, testopia(a)bugs.koha-community.org Blocks: 29239 The cataloging plugin which affects date fields in cataloging (952$d "date acquired" in the default MARC21 framework) uses the old jQueryUI datepicker. It should be updated to use Flatpickr. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29239 [Bug 29239] [OMNIBUS] Replace jQueryUI's timepicker with flatpickr -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 26591] New: Add a choice to prevent the checkout or warn the user at the selfcheckout system if we use CheckPrevCheckout
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '22

08 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26591 Bug ID: 26591 Summary: Add a choice to prevent the checkout or warn the user at the selfcheckout system if we use CheckPrevCheckout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Since BZ19457, the checkout is allowed at the selfcheckout system if if we use the system preference CheckPrevCheckout. It can be useful for some libraries but not for the others. For example, in my libray, we want to prevent users who are using the selfcheckout system to checkout an item they have just check-in. They didn't really matter the warning and they can keep a book for all the time. For some title, there's a real pressure becaus they are recommanded by the teachers and we can't have one for all the students. The behaviour should be configurable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 28465] New: Staff Account Restrictions
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28465 Bug ID: 28465 Summary: Staff Account Restrictions 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: christofer.zorn(a)ajaxlibrary.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello All! One of our staff members had a mental lapse and deleted her own STAFF account the other day. Apparently Koha tried to stop her by preventing the deletion of either the account she was logged into, or by preventing her from deleting an account with a STAFF designation, but she was determined. She changed the account type from STAFF to COMPUSE, then the system didn’t stop her from deleting it. I'm proposing that if a staff member is not able to change another staff member's username, then they shouldn't be able to change the patron type of that account either. This would prevent a staff member from unintentionally (or otherwise) deleting a number of staff accounts. Thank you! Christofer -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29032] New: ILL route unusable (slow)
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29032 Bug ID: 29032 Summary: ILL route unusable (slow) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com With only 20 ill requests, for the same backend, the page takes lots of seconds to load. Steps to reproduce: 1. Add 23 requests with your favourite ILL backend 2. Hit the ILL requests page => FAIL: Notice it takes ages to load -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 24650] New: API returned timestamps are incompatible with existing helpers
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24650 Bug ID: 24650 Summary: API returned timestamps are incompatible with existing helpers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org API endpoints that return system maintained timestamps (specified as datetime in the DB schema and specified as 'date-time' in the endpoint definition) return the timestamps as a form of RFC3339 timestamps. For example, from the GET /patrons/{patron_id} response: "last_seen": "2020-02-13T08:47:29+00:00" This is good as it's in a standard form. However, all the existing handlers in koha-tmpl/intranet-tmpl/prog/en/includes/calendar.inc that are used to transform a received timestamp into the instance's defined format are expecting timestamps in the format: (see DateTime_from_syspref) [datestring] [hours:minutes] Thereby making it impossible to display a returned timestamp to the user in their chosen format. We either need to create additional helpers or modify the API returning of ISO formatted timestamps to something the helpers can cope with. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 24190] New: Add additional Acquisition logging
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24190 Bug ID: 24190 Summary: Add additional Acquisition logging Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org A start was made on adding logging for Acquisitions in bug 23971. This bug will extend this as detailed below (note, some of the information detailed here will be derived via reporting and not explicitly logged): 1. Order line cancellations Details including who made the cancellation and when the cancellation was made 2. Order line creations Details including who created the order line, when it was created, the fund, and amount 3. Invoice adjustment additions Details including who added the adjustment, when it was added, the fund, and amount 4. Invoice adjustment amendments Details including who amended the adjustment, when it was amended, the fund, and amount 5. Invoice adjustment deletions Details including who deleted the adjustment, when it was deleted, the fund, and amount 6. Order line receipts against an invoice Details including who received the order line, when it was received, the fund, and amount 7. Budget Adjustments This would show amounts added or removed from a budget (excluding spent), who, when, and amount (In Koha the actual amount is edited rather than typing in the amount to change) 8. Fund adjustments This is essentially a bank statement. It would show additions and subtractions to a fund (excluding spent), who, when, amount, previous total, new total 9. Order release date (1) This would show individual order lines from an EDI message, when they were sent, who sent it, fund, and amount 10. Order release date (2) This would show individual order lines from a basket, when it was closed, who closed it, fund, and amount -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 85

[Bug 24083] New: Koha should support "seen" vs "unseen" renewals
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24083 Bug ID: 24083 Summary: Koha should support "seen" vs "unseen" renewals 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.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When carrying out a renewal transaction Koha should check for both the maximum number of renewals allowed and also the number of unseen renewals. If it finds a value equal to or greater than the number of renewals already carried out against that loan, it prevents the renewal. The purpose of this is to prevent borrowers from continually renewing a book when they have, in fact, lost or misplaced it! When a renewal takes place via a method that doesn't require visible sight or possession of the item (e.g. OPAC, automatic renewal) then the number of unseen renewals for that item should be incremented. SIP2 renewals can be considered seen since they will require the physical item to be scanned. The number of allowed unseen renewals before a renewal is denied should be specifiable in the circulation rules. If a renewal is denied due to the unseen maximum having been reached, the flow should be the same as when a renewal limit has been reached, though with appropriate messages displayed to the user. It should be possible to override the denial in the same was as when a renewal limit is reached. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 186