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

[Bug 27705] New: Unfold facet groups
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27705 Bug ID: 27705 Summary: Unfold facet groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org A great option could be to have an option to unfold the group facet "ITEMTYPECAT". If I use the example given in the manual : it's great to filter on "Movies" items, but I don't have a Blu-ray player, I would be happy to unfold the "Movies" category to only select the "DVD" item type ! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27722] New: Eliminate 'All' as an option from display location in OPAC and Koha news
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27722 Bug ID: 27722 Summary: Eliminate 'All' as an option from display location in OPAC and Koha news Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When the Koha News tool was just for OPAC News and 'librarian interface' all was a good option. Now that we have 10+ content areas options 'All' is just confusing. It should be eliminated as an option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27721] New: Circulation Workflow (Statuses)
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '23

23 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27721 Bug ID: 27721 Summary: Circulation Workflow (Statuses) Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if there were some kind of centralized workflow for processing items that would allow libraries to handle items the way they need to at each branch. Right now we have rules, and then we have statuses. There are some workflows for statuses peppered throughout the preferences, but nothing centralized, and far too limiting. I think some of these settings could be centralized through a common workflow interface, similar to (or maybe combined with) UpdateItemLocationOnCheckin, and be given some better flexibility. Please understand that I am just throwing this out there for a discussion. Some of these ideas might be redundant and might even be too complex a change for Koha. But, for the sake of discussion and brainstorming, what if we could define common triggers and actions, and allow libraries to combine these with common elements? Basically, it would be great to have a framework in which we could define what elements would trigger what kind of actions, and in what order. Here is where I am coming from. We have a library that would like to create a status for lost items that are in collections. Easy enough. We would like to make sure that when the item status is changed from long overdue to lost and in collections that the fee is not removed. We would also like it if an item with this status were checked in at some or all libraries, it would pause the check in with a message stating that it is in collections, are you sure you want to check this item in? Maybe we just simply need more status preferences? But, it seems we have a few peppered through the settings as it is, and it would be great if we had these in a central framework where we could see them all and prioritize them and have more options as to how they work. Does this status charge? Does it refund? Should it be confirmed? Should it block? Should it reroute? Should it notify a staff member? Should it go to a staff member for processing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 28486] New: MARCItemFieldsToOrder values lost when using Add Order button
by bugzilla-daemon＠bugs.koha-community.org 21 Jan '23

21 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28486 Bug ID: 28486 Summary: MARCItemFieldsToOrder values lost when using Add Order button Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When populating a basket via a staged MARC file and checking for duplicates, if a duplicate is found then one is expected to use the "Add Order" button on that title to manage that title individually and decide whether to use the existing bib or create a new one. Either choice pushes one to neworderempty.pl (rather than addorderiso2709.pl). Values from MARCItemFieldsToOrder are not applied on neworderempty.pl, which complicates the workflow and requires the user to manually enter those values. To recreate: 1 - export a bib from your collection 2 - edit that bib to add some item values formatted in accordance with your MARCItemFieldsToOrder syspref 3 - create a basket in Acq set to create items at ordering 4 - add to your basket from a new file, select your exported and edited bib 5 - on addorderiso2709.pl, confirm your MARCItemFieldsToOrder values show up 6 - click Add Order 7 - select wither Use Existing Record or Create New Record 8 - confirm that you end up on neworderempty.pl without your MARCItemFieldsToOrder values -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31954] New: Patron search has no h1 heading
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31954 Bug ID: 31954 Summary: Patron search has no h1 heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For accessibility every page should have an h1 level heading and have a clear hierarchical structure of headings. Patron search only has 2 h3 headings. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 32480] New: Specify module and action of action_logs entries to purge
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32480 Bug ID: 32480 Summary: Specify module and action of action_logs entries to purge Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz It would be helpful if libraries had the following action_logs purging behaviour: - Be able to specify the module and action of action_logs entries they would like to purge. Use case: Libraries with a patron import overwriting patron records several times a day will likely want to truncate member 'create' entries from the action_logs tables, whilst retaining other patron action_logs entries. - Be able to specify a different number of days for purging different modules. Use case: The library with the patron import may want to purge member 'create' action logs older than 30 days, but purge all other logs older than 365 days. We think this could be accomplished by adding a separate script for purging action_logs: ./purge_logs.pl --module MEMBERS --action CREATE --days 30 ./purge_logs.pl --module all --action all --days 365 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 23979] New: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23979 Bug ID: 23979 Summary: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 21311 removes the "This account has been locked!" message from the OPAC when a patron account has been locked because someone has attempted to log into that account with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. This means that a patron may not know that their account has been locked if someone other than themselves has attempted to hack their account. Bug 21312 adds an "Account is locked" message on the patron's "Details" tab when a patron has locked their account by logging in with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. Most public library staff access a patron's account through the "Check out" tool which takes them directly to the "Check out" tab on the patron's account rather than the "Details" tab. The "Check out" tool is, after all, the default action of the header_search input box on the Koha home page. Having the "Account is locked" message only on the "Details" tab means that when a patron comes into the library and says "I don't understand why I can't get into my account" when staff look up the patron's account through "Check out", as they normally do, they have to take the extra step of switching to the "Details" tab to find out that the "Account is locked." The "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab. George -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 22854] New: Add separate column for administrative locked patron
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22854 Bug ID: 22854 Summary: Add separate column for administrative locked patron 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- See bug 21336. This is now arranged by using the same column login_attempts. login_attempts > pref_value means locked login_attempts < 0 means admin lock Do we need one or even two new columns? [1] locked: regular lock (resulting from entering wrong password), boolean replacing the check attempts > pref. Note that changing the pref might lock or unlock users now. Do we want that? [2] admin_locked: administrative lock, resulting from e.g. removing GDPR consent, boolean -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32134] New: Show the bundle size when checked out
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32134 Bug ID: 32134 Summary: Show the bundle size when checked out Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 28854 When checking out a bundle, it can be useful to know the number of items in this bundle, so that librarians can quickly check if items are missing. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28854 [Bug 28854] Add ability to create bundles of items for circulation -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 32422] New: Hardcoded paths in _common.scss precent using external node_modules
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32422 Bug ID: 32422 Summary: Hardcoded paths in _common.scss precent using external node_modules 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 Whenever you try to build the OPAC view, this happens: root@kohadevbox:koha(master)$ kshell kohadev-koha@kohadevbox:/kohadevbox/koha$ yarn build --view opac yarn run v1.22.19 $ gulp build --view opac [18:27:38] Using gulpfile /kohadevbox/koha/gulpfile.js [18:27:38] Starting 'build'... Error in plugin 'sass' Message: koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss Error: File to import not found or unreadable: ../../../../../node_modules/bootstrap/scss/functions. on line 37 of koha-tmpl/opac-tmpl/bootstrap/css/src/_common.scss from line 1 of koha-tmpl/opac-tmpl/bootstrap/css/src/opac.scss >> @import "../../../../../node_modules/bootstrap/scss/functions"; ^ [18:27:38] Finished 'build' after 36 ms Done in 1.39s. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17