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

[Bug 29859] New: Favor iterators over as_list
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29859 Bug ID: 29859 Summary: Favor iterators over as_list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29844 On bug 29844 we decided to remove wantarray from Koha::Objects->search. Reviewing the difference occurrences I found some unnecessary uses of ->as_list, where iterators should be used instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29844 [Bug 29844] Remove uses of wantarray in Koha::Objects -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 27618] New: Don't show dropdown if PatronSelfRegistrationLibraryList only has one library
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '25

06 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27618 Bug ID: 27618 Summary: Don't show dropdown if PatronSelfRegistrationLibraryList only has one library Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Depends on: 16274 If PatronSelfRegistrationLibraryList only has one library code in it, that one library is still shown as a dropdown with one choice. It would be better if the code was in a "hidden" form input and the "Home library" was just shown as text, or not shown at all. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16274 [Bug 16274] Make the selfregistration branchcode selection configurable -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 21482] New: Create a "landing page" for ILL
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21482 Bug ID: 21482 Summary: Create a "landing page" for ILL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Currently, when you go to the ILL module, the first iew is of all ILL requests. This can be a lot of data, and take several seconds to load, and I doubt a lot of people will want the full list. So maybe we could have some sort of intermediate page with links to selections of request, based on their status, type etc. At it's simplest this could just be a page that displays the contents of a syspref, and that syspref could then be filled with HTML and links to filtered views of ILL requests. If the syspref is empty, the intermediate page could redirect to the full view, as it is today. A more advanced version would have a GUI to configure the links, order them, give them names etc. Thougts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 28781] New: Elasticsearch facets may be inaccurate
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '25

05 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28781 Bug ID: 28781 Summary: Elasticsearch facets may be inaccurate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com To recreate: 1 - Set system preferences: SearchEngine: Elasticsearch FacetMaxCount: 20 displayFacetCount: Show 2 - Using koha testing docker default data search for '*' 3 - Note the author facets like Beckett, Samuel (5) Aristophanes (3) De Niese, Danielle (3) Euripides (3) Aristotle (2) 4 - Set FacetMaxCount:400 5 - Repeat search 6 - Note facets like: Beckett, Samuel (5) Stevens, W. Richard (5) Plato (4) Aristophanes (3) De Niese, Danielle (3) 7 - Some top terms are missing when FacetMaxCount is passed to ES as 'size' >From the docs: The size parameter can be set to define how many term buckets should be returned out of the overall terms list. By default, the node coordinating the search process will request each shard to provide its own top size term buckets and once all shards respond, it will reduce the results to the final list that will then be returned to the client. This means that if the number of unique terms is greater than size, the returned list is slightly off and not accurate (it could be that the term counts are slightly off and it could even be that a term that should have been in the top size buckets was not returned). https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregat… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22320] New: Make ILL comments visible to all staff
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22320 Bug ID: 22320 Summary: Make ILL comments visible to all staff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- The ILL module has several kinds of comments that are only visible to staff who have access to the ILL module. This is a problem because any librarian can get the question "how is my ILL coming along" from a patron at the front desk. We should make some or all of the comments, and probably also the status, of ILL requests visible to all staff in the normal detail view, so they can answer questions about ILL loans that have not arrived at the library yet. It might be a good idea to have sysprefs to let libraries choose which comments should be visible to "other" staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 27049] New: It would be helpful to have a bulk waive of debts tool
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27049 Bug ID: 27049 Summary: It would be helpful to have a bulk waive of debts tool 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz With extended periods of libraries being closed and the recent complexities introduced into the accounts system for properly tracking accountline writeoffs, it would be helpful to have a command line too allowing administrators to writeoff accounts in bulk using the proper routines within Koha to properly record the action. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 22435] New: account_offset types should be codes not descriptions
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22435 Bug ID: 22435 Summary: account_offset types should be codes not descriptions Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, account_offset.types are all descriptive strings.. they should really be 'codes' to distinguish them from user-facing data and discourage developers from adding more untranslatable strings at the database level. I also don't think the current strings make a great deal of sense as they're often not describing an 'offset' action but the account action itself which is already better defined within the accountline.accounttype fields. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 282

[Bug 31095] New: Koha::Patron::Debarment should be updated to follow current Koha:: style
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31095 Bug ID: 31095 Summary: Koha::Patron::Debarment should be updated to follow current Koha:: style Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The Koha::Patron::Debarment module is written in the C4 style when it should really be a Koha::Object based class now. We should update it to the modern practices to enable simple addition of API's and more standard use codebase wide. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 151

[Bug 31197] New: Enabling Authority checks for all library staff but restrict the ability to edit Authority files to system admin
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '25

04 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31197 Bug ID: 31197 Summary: Enabling Authority checks for all library staff but restrict the ability to edit Authority files to system admin 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: susan.merner(a)nhs.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The ability to check whether an Authority such as a subject heading is in the authority file should be available to all staff BUT the option to edit authority files should be restricted to selected staff with system admin permissions. The Authority files affected would be Subject Headings (650), Series (490) and Corporate Authors. We want to ensure staff keep to the authorised lists and do not introduce or amend entries within Authorities. Is there a way to give cataloguers permission to have the "Link authorities automatically" button, but not edit, create or delete the authorities? If we could have a 'check authorities' button with no additional permissions, it would be really helpful! Or a way to flag unauthorised headings upon saving. We all need to be able to check if the subject headings (650 field) being pulled through by z39.50 are included in the authority file on Koha. At present, this is not possible, and there is no way to check z39.50 against the authority file. This raises an issue with cataloguers adding in unauthorised headings -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 28141] New: Accessibility: OPAC Advanced Search fields aren't labelled
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '25

03 Mar '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28141 Bug ID: 28141 Summary: Accessibility: OPAC Advanced Search fields aren't labelled 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: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org The OPAC advanced search page has unlabelled search fields making them inaccessible to users of screen readers. This is a complicated page to get right and I'm not entirely sure how best to fix this. Here are some of the issues with the page currently: Example issue 1: When using NVDA to access the search form fields out of context, it is hard to tell which index (keyword, author, title etc.) you are searching. This is an issue when searching multiple fields at once. "Enter search terms; edit; has auto complete" It would be better if the search form field was linked to the index combo box. We could use aria-labelledby but there may be better ways to do this. Example Issue 2: The label for "search-field_0" is blank. Example Issue 3: The search terms are linked by 'and' but this isn't entirely clear out of context using a screen reader: " ;combo box; collapsed; Subject" "and;combo box; collapsed; Title" "and;combo box; collapsed; Publisher Location" "Location and availability:; combo box; collapsed; All Libraries" "Sort by:; combo box; collapsed; Relevance" "Language; combo box; collapsed; No Limit" Example Issue 4: The remove field buttons aren't programmatically linked to the field they are removing -- You are receiving this mail because: You are watching all bug changes.

1 6