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

[Bug 7508] Collapsable items on items tab
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '24

22 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7508 Brendan Lawlor <blawlor(a)clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #169102|0 |1 is obsolete| | --- Comment #7 from Brendan Lawlor <blawlor(a)clamsnet.org> --- Created attachment 170575 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170575&action=e… Bug 7508: Collapsable items on items tab Since we recently updated the patron entry form in the staff interface to have more visibly-collapsible sections I thought there might be interest in picking up this old bug. The patch implements collapsible sections on the item detail page, allowing the user to hide sections by clicking the item barcode header. The patch includes relocation of some JS code from the authority and MARC editors into the global JS file. This is the code that helps jump the user to a certain scroll point on the page. To test, apply the patch and clear your browser cache. - In the staff interface, locate a bibliographic record with items and view the detail page. - Click the "Items" tab in the sidebar. - On the item detail page, each section should have an icon indicating that they are expanded. Hovering your mouse over the section heading should highlight the clickable area. - Test that each section collapses correctly and that the next section is moved into view. - Go to Cataloging -> New record. Test that the links to specific tags under the main tab bar still work to jump you to the correct part of the page. - Go to Authorities -> New authority and perform the same test. Sponsored-by: Athens County Public Libraries Signed-off-by: Brendan Lawlor <blawlor(a)clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 7508] Collapsable items on items tab
by bugzilla-daemon＠bugs.koha-community.org 22 Aug '24

22 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7508 Brendan Lawlor <blawlor(a)clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37633] New: Show record diff in Batch Record Modification
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37633 Bug ID: 37633 Summary: Show record diff in Batch Record Modification Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: jvasche(a)roundrocktexas.gov, m.de.rooy(a)rijksmuseum.nl In the process of batch record modification, one is given a button to see the condensed MARC record as it will be after your edit. It would be more helpful to see a view that specifically highlights what will be changed, more like what we get in record merging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 37703] New: 'Override restriction temporarily' button is confusing when circulation block isn't a restriction
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37703 Bug ID: 37703 Summary: 'Override restriction temporarily' button is confusing when circulation block isn't a restriction Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff interface 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 To reduce confusion about the differences between blocks and restrictions, the 'Override restriction temporarily' button should be renamed in situations where the override is of a block, not a restriction. For example: -Set AllowFineOverride to "[Don't allow] staff to manually override and check out items to patrons who have more in fines than set in the noissuescharge system preference" -Add charges to a patron above the amount in noissuescharge, and make sure they have no restrictions -Using a staff account with force_checkout permission, visit that patron's page to check out an item -See that the button to override says 'Override restriction temporarily' Since blocks and true restrictions behave differently in Koha, this should be renamed to avoid confusion. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 32202] New: Remove kohalib.pl from recall cronjobs
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32202 Bug ID: 32202 Summary: Remove kohalib.pl from recall cronjobs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Depends on: 29734 >From misc/cronjobs/recalls/expire_recalls.pl and misc/cronjobs/recalls/overdue_recalls.pl: +BEGIN { + # find Koha's Perl modules + # test carefully before changing this + use FindBin; + eval { require "$FindBin::Bin/../kohalib.pl" }; +} As Jonathan pointed out on bug 19532 this should not longer be used, as kohalib.pl has been removed with bug 28617. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29734 [Bug 29734] [OMNIBUS] Recalls for Koha -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 31368] New: Koha::Recalls->add_recall should throw exceptions
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31368 Bug ID: 31368 Summary: Koha::Recalls->add_recall should throw exceptions Change sponsored?: --- Product: Koha Version: unspecified 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 It instead returns undef. We should change this and properly handle exception cases. One remarkable example is missing mandatory parameters. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 30292] New: Link recall to checkout
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30292 Bug ID: 30292 Summary: Link recall to checkout 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org When patron biblio-level recall is issued, and an item/checkout combination is chosen to proceed with the actual checkout, we should store the checkout_id. This way we would avoid guessing the right checkout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31369] New: Koha::Recalls->add_recall should validate there's a related checkout
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31369 Bug ID: 31369 Summary: Koha::Recalls->add_recall should validate there's a related checkout Change sponsored?: --- Product: Koha Version: unspecified 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 I haven't really tried, but the code cleary relies on an $recall->checkout returning a Koha::Checkout object... Which shouldn't be taken for granted. The way it is constructed is fragile and makes the controller need to perform all the checks, that really belong here. It should probably throw an exception as well. Right now the code can generate a recall object (store it on the DB) and then explode because of the lack of the checkout. This also points to the need of a transaction. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 16223] New: Automatically remove any borrower debarments after a payment
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16223 Bug ID: 16223 Summary: Automatically remove any borrower debarments after a payment 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: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries debar Borrowers at the end of the year for having unpaid fines, like in Bug 15157. Currently librarians have to manually remove this type of debarments after Borrower has paid his/her fines. Add a system preference to define debarments that should be automatically removed after a payment is made, and add functionality to actually remove the defined debarments from Borrower. Also let libraries to define the amount of outstanding fines after payment after which the debarment will be removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 152

[Bug 37698] New: Setting Manual patron restriction type to 'Lift after payment' removes all manual restrictions
by bugzilla-daemon＠bugs.koha-community.org 21 Aug '24

21 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37698 Bug ID: 37698 Summary: Setting Manual patron restriction type to 'Lift after payment' removes all manual restrictions Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 Bug 16223 - Automatically remove any borrower debarments after a payment allows libraries to automatically remove the MANUAL-type restriction placed by Bug 15157 - Cronjob to automatically restrict patrons with pending/unpaid charges using the debar_patrons_with_fines.pl cron. However, if a patron has a Manual restriction placed by that cron and a Manual restriction placed by staff for other reasons, and they pay their balance below the amount set in 'Fee limit' for the MANUAL restriction, all Manual-type restrictions are removed. To replicate: -In Administration > Patron restriction types, set 'Lift after payment?' to Yes and 'Fee limit' to $9.99 for the MANUAL restriction -Set the debar_patrons_with_fines.pl cron to place restrictions for patrons owing over $10 -Add charges of $10 or more to a patron's account -Run the cron to place the restriction - note the MANUAL restriction now showing on the patron's account -Place a separate MANUAL restriction on the same patron's account -Pay their fee so that the balance is at or below $9.99 -Note that both MANUAL restrictions have been removed Only the restriction placed by the cron should be removed if fees are paid below the amount in 'Fee limit'. (See also: Bug 37689 - Add ability to select restriction type to use with debar_patrons_with_fines.pl to allow libraries to use other restriction types.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5