September 2024 - Koha-bugs - lists.koha-community.org

[Bug 36594] New: Library hours display issues
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36594 Bug ID: 36594 Summary: Library hours display issues 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are some glitches on the libraries table: * If not defined, the string literal 'null' is displayed * If you set 9:00 as the opening hour, 09:00::00 is displayed The feature authors need to: * Find a good approach to undefined values here (do we need to display days when the library is not open?) * Use the formatting tools to display time correctly. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 58

[Bug 36083] New: Not able to create customizable areas to intranet home pages that are library specific
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36083 Bug ID: 36083 Summary: Not able to create customizable areas to intranet home pages that are library specific Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When testing the enhancement coming in 23.11, bug 6419, it appears that library-specific text does not display as it should with the HTML Customization tool. Process to test: 1. Tools> HTML Customizations 2. Choose to create an entry in StaffAcquisitionsHome 3. Assign it to a specific library 4. Add text and publication date. 5. Save 6. Go to the Acquisitions Home page - logged into that library, no text displays. This enhancement does work if creating an entry for 'all libraries'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 35100] New: Items assigned to StockRotation do not advance if a reserve is triggered before the initial transfer
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35100 Bug ID: 35100 Summary: Items assigned to StockRotation do not advance if a reserve is triggered before the initial transfer Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I have not recreated personally, but we have found evidence of this multiple times on a site using stock rotation Scenario: 1 - Item is added to stock rotation 2 - The cronjob creates a 'StockRotationAdvance' transfer 3 - The item is checked in, which initiates the transfer, however, a hold is triggered 4 - The hold is confirmed, which cancels the StockRotationAdvance 5 - The item is checked out and returned 6 - The stock rotation cronjob eventually calls Koha::StockRotationItem->needs_advancing which looks for all StockRotationAdvance transfers, ordered by date arrived 7 - The only one has a NULL date arrived 8 - The date arrived is put into dt_from_string, which returns today when given null 9 - The date object above then calls 'delta_days' from dt_from_string() 10 - The number of days from NOW to NOW is always 0 11 - The item does not advance until manually forced -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 94

[Bug 37493] New: Cypress videos and screenshots should be .gitignored
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37493 Bug ID: 37493 Summary: Cypress videos and screenshots should be .gitignored Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 36716] New: Need a better way of looping through smart-rules ( circ table ) columns
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36716 Bug ID: 36716 Summary: Need a better way of looping through smart-rules ( circ table ) columns Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a user clicks "Edit" ( .editrule ) we use JavaScript to loop through each of the columns in the table. This is done based on the column index like so: if ( i == 3 ) or } else if ( i == 5 || i == 6 || i == 26 || i == 27 || i == 28 || current_input_id === "holds_pickup_period" ) { This leads to problems like Bug 36708. We could probably give the columns names/classes so we don't have to rely on the index, which may vary between Koha versions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 34473] New: "Holds Waiting Over..." is not matching the ReservesMaxPickupDelay syspref
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34473 Bug ID: 34473 Summary: "Holds Waiting Over..." is not matching the ReservesMaxPickupDelay syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Holds are being marked as problematic even before they reach the number of days set in the ReservesMaxPickUpDelay syspref. Library Example: The ReservesMaxPickUpDelay syspref is set to mark holds as problematic at 10 days. Today is August 3rd and yet it is showing holds with expiration dates of August 1st and August 2nd in the Holds Waiting Over 10 days tab at /cgi-bin/koha/circ/waitingreserves.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37563] New: Refund modal in Point of Sale should include ending zeros
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37563 Bug ID: 37563 Summary: Refund modal in Point of Sale should include ending zeros Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com When issuing a refund from the transaction history page in the POS module the refund modal does not display ending zeros for amounts in the 'Amount paid' and 'Returned to patron' fields. Payments like 25.00 or 2.40 will display as 25 or 2.4 in the modal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 37615] New: Clean up the form for sending cardnumbers from a report to batch patron modification
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37615 Bug ID: 37615 Summary: Clean up the form for sending cardnumbers from a report to batch patron modification Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 37197 Followup to bug 37197, because I wrote the patch there based on reverting the changes from the wrong CSRF patch - https://git.koha-community.org/Koha-community/Koha/commit/8a20e0cb6a0efd6b9… changed it from a POST to cud-show into a GET of show, but then later on https://git.koha-community.org/Koha-community/Koha/commit/21fa3f64c31dad23e… tried to make that actually work by switching from a textarea to a (long) list of inputs, which isn't needed now that we've gone back to a POST. It should just be a textarea like the other POSTed lists of numbers. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37197 [Bug 37197] Batch patron modification from reports fails by using GET instead of POST -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 37366] New: Patron category "Password change in OPAC" setting only follows system preference
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37366 Bug ID: 37366 Summary: Patron category "Password change in OPAC" setting only follows system preference Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: heather(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In Administration > Patron categories, when setting the Password change in OPAC field, Koha will not save "Allowed" or "Not allowed" options, and will only keep "Follow the system preference OPACPasswordChange..." value. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 35539] New: Remove 'bulk' column from categories table
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '24

18 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35539 Bug ID: 35539 Summary: Remove 'bulk' column from categories table 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, jonathan.druart+koha(a)gmail.com, katrin.fischer(a)bsz-bw.de, kyle.m.hall(a)gmail.com, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, tomascohen(a)gmail.com Looking at the code (first commited 17 years ago) the "bulk" column in the 'categories' table appears to not be utilized anywhere in the code. Is anyone able to confirm? I suggest we remove this if that is the case. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47