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

[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 30970] New: holdst columns don't match actual columns
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '22

10 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30970 Bug ID: 30970 Summary: holdst columns don't match actual columns Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The columns selected to hide by default in 'Table settings' for holdst aren't lining up with the actual columns hidden. For example: -In holdst, select columns home_library and current_location to be hidden by default -In the 'Holds waiting' table, see that Patron and Home library are hidden by default. Current location is showing by default. -To hide current_location and home_library by default, I need to select shelving_location and current_location in 'Table settings' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 30917] New: Improve course reserves breadcrumbs
by bugzilla-daemon＠bugs.koha-community.org 10 Nov '22

10 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30917 Bug ID: 30917 Summary: Improve course reserves breadcrumbs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I think it would be useful to add a link in the breadcrumbs to the course view from the "add items" pages: Home > Course reserves > [Course name] > Add reserves -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 30880] New: Expand OPACResultsUnavailableGroupingBy to have a 'branch only' option
by bugzilla-daemon＠bugs.koha-community.org 09 Nov '22

09 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30880 Bug ID: 30880 Summary: Expand OPACResultsUnavailableGroupingBy to have a 'branch only' option 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently you can group unavailable items in OPAC search results by substatus or branch. However the 'branch' option is misleading, because it still groups unavailable items by substatus as well as branch. Some libraries do not need this amount of information about their unavailable items on the search results. OPACResultsUnavailableGroupingBy should have the following options: - 'branch and substatus' (current 'branch' behaviour) - 'substatus only' (current 'substatus' behaviour) - 'branch only' (new behaviour) For example: Currently, with 'substatus' enabled for OPACResultsUnavailableGroupingBy the results look like: Not available: Checked out (1). Lost (1). With 'branch' enabled for OPACResultsUnavailableGroupingBy the results look like: Not available: Fairview: Checked out (1). Fairview: Lost (1). As you can see, different substatuses within the same branch are split out. There should be an option to make the search results look like: Not available: Fairview (2). -- You are receiving this mail because: You are watching all bug changes.

1 14

[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