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

[Bug 38054] New: Select the item for single holdable item record with DisplayMultiItemHolds
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38054 Bug ID: 38054 Summary: Select the item for single holdable item record with DisplayMultiItemHolds Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: ephetteplace(a)cca.edu QA Contact: testopia(a)bugs.koha-community.org When DisplayMultiItemHolds is on and you attempt to place a hold on a record with a single holdable item in the OPAC, formerly the single item was a radio button and selected by default (makes sense, there are no other options). If you turn on DisplayMultiItemHolds and do the same, the item is selected via a checkbox input which is not selected by default. Steps to recreate: - Turn on DisplayMultiItemHolds - Find or create a bib record with a single holdable item - Go to the record in the OPAC and select "Place hold" Expected: - The only option in the items table is selected, because there is no other choice for users. Actual: - The single item is not selected so users must click the checkbox input. I can imagine two solutions: 1) auto-select the checkbox if there's only one item, 2) actually revert to the old behavior where it's a radio button input. The latter seems like it's probably needlessly more complicated to implement. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 15565] Place multiple item-level holds at once for the same record
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 Eric Phetteplace <ephetteplace(a)cca.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |38054 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38054 [Bug 38054] Select the item for single holdable item record with DisplayMultiItemHolds -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31748] New: Restore progress bar on record import
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31748 Bug ID: 31748 Summary: Restore progress bar on record import Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We've got the progress bar for staging back, we now want it for managing staged records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 19590] New: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19590 Bug ID: 19590 Summary: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi, I think I've found a documentation issue in the "Clean Patron Records" tool. Both the in-app + online doc [1] mention that: «patrons with outstanding fines or items checked out not saved» (the rest of the doc confirms that we are talking about removal) → wrong, see [2][3] «The anonymization will fail quietly if AnonymousPatron preference does not contain a valid value.» → wrong, according to the UI itself «The AnonymousPatron system preference is not defined. You can use this feature anyway but NULL will be used to update the checkout history.» Are these two findings correct? [1] https://koha-community.org/manual/17.05/html/03_tools.html#patrons-anonymiz… [2] excludes patrons with checked out item https://github.com/Koha-Community/Koha/blob/master/C4/Members.pm#L1040 [3] excludes patrons with unpaid fines https://github.com/Koha-Community/Koha/blob/master/tools/cleanborrowers.pl#… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 37508] SQL reports should not show patron password hash if queried
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37508 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38039] New: Arbitrary counts in search results (staff)
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38039 Bug ID: 38039 Summary: Arbitrary counts in search results (staff) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org When searching the catalog, each item in a record is listed with a number in parenthesis in the location column. Usually this number is (1). When I inspect the code, it is surrounded by a span with a class of "item_count". It appears that it is a count of items with the same location and call number. I would propose that it is pointless to show the count if it is 1. Most items are going to be a single copy. The count is only useful if it is higher than one. I would suggest not showing this number unless it is higher than 1. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38052] New: "Clear" link in the report search form is not styled correctly
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38052 Bug ID: 38052 Summary: "Clear" link in the report search form is not styled correctly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org http://localhost:8081/cgi-bin/koha/reports/guided_reports.pl?op=list&clear_… https://snipboard.io/LRmNqM.jpg But hard to tell how we actually want it styled, as we also have: http://localhost:8081/cgi-bin/koha/members/members-home.pl https://snipboard.io/rhHUkN.jpg and http://localhost:8081/cgi-bin/koha/admin/aqbudgets.pl?budget_period_id=1 https://snipboard.io/WkJQj1.jpg -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 14322] Add option to create a shareable link for item searches
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 --- Comment #51 from Jonathan Druart <jonathan.druart(a)gmail.com> --- We should discuss all this on bug 27467. You will find the exact same link there ;) spoiler: deepLink is not what we want. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14322] Add option to create a shareable link for item searches
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14322 --- Comment #50 from Brendan Lawlor <blawlor(a)clamsnet.org> --- (In reply to Jonathan Druart from comment #49) > This is so much changes to impact only one table. Additionally we cannot > filter after you have got the result and have the URL updated. > > We should absolutely promote a global solution like what bug 27467 is > suggesting, that will impact ALL tables in Koha. Thanks for the feedback. This is a valid point that it would be best to have a global solution to link to all tables in Koha. I am interested in learning about possible solutions to acheive this Most of the changes in this patch are to the template, in order to fill the form inputs from the url. I think those changes would still be necessary for the 'Edit search' button to work. It's similar to how the 'edit this search' link works from the advanced search results. It sends url parameters to search.pl and the form is populated. In Item search it's a little different because it's all one page, and the 'Edit search' button just shows the form that the user previously filled with javascript. With the datatables deep link solution #2 in bug 27467, I think we could add filtering and sort parameters to the shareable url that should be able to work for all datatables. Pedro shared this article about deeplinking earlier: https://datatables.net/blog/2017/deep-linking?order=[[3,%22asc%22]] -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37015] New: Expose external_id in the ERM packages form and views
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37015 Bug ID: 37015 Summary: Expose external_id in the ERM packages form and views Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com While the ERM module was in development we had made a case for an external ID field for packages. This was added to the database, but the field cannot be added, edited or viewed from the GUI. We would like to use this to store the national identifiers for packages. They would then be used to match bibliographic records to their packages. -- You are receiving this mail because: You are watching all bug changes.

1 8