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

[Bug 25376] New: Use LANG authorised values for language facet
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '21

15 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25376 Bug ID: 25376 Summary: Use LANG authorised values for language facet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Instead of relying on language_descriptions table, on which users have no control, use LANG authorised values It will give more control to users which will be able to add new languages or change descriptions (for instance to translate them in their own language) -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 15883] New: Upgrade jQuery from v1.7.2 in the staff client
by bugzilla-daemon＠bugs.koha-community.org 15 Oct '21

15 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15883 Bug ID: 15883 Summary: Upgrade jQuery from v1.7.2 in the staff client 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 14546 In order to upgrade Bootstrap in the staff client we first need to upgrade jQuery. After discussing it some in IRC (http://irc.koha-community.org/koha/2016-02-22#i_1791968) this is the plan I'm working on right now: An initial patch will start by adding the basis for upgrades: 1. Add a new version of doc-head-close.inc which includes new version of jQuery and jQueryUI. That include file will be named doc-head-close-jquery.1.12.0.inc to reflect the version of jQuery it uses. 2. Add the 1.12.0 version of jQuery, naming the file jquery-1.12.0.min.js 3. Add the latest version of jQueryUI, 1.11.4, naming the files jquery-ui-1.11.4.js and jquery-ui-1.11.4.min.css. Subsequent patches can take a page-by-page approach to the upgrade, dropping in the new include file and making any upgrades necessary to Javascript on that page. As compatibility issues are discovered, affected JS files can be re-created with updated file names to reflect the jQuery version, as in "basket-jquery-1.12.0.js" Disadvantages to this method: 1. It's possible some patches will have to touch both doc-head-close.inc and doc-head-close-jquery.1.12.0.inc. However that file changes fairly seldom. 2. git history getting lost between files. Can it be done so that the new include file keeps the history of doc-head-close.inc and doc-head-close.inc is created as if it is the new file? Eventually it could be removed. I would like to hear opinions and suggestions about this. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14546 [Bug 14546] Make staff client use Bootstrap -- You are receiving this mail because: You are watching all bug changes.

1 51

[Bug 24958] New: Remember last selected tab in SQL reports
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '21

14 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24958 Bug ID: 24958 Summary: Remember last selected tab in SQL reports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Reports Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I think it would be useful for the saved reports page to remember which tab the user last suggested. I propose to set a cookie to store the information. -- You are receiving this mail because: You are watching all bug changes.

1 42

[Bug 25070] New: Include files to display address and contact must be refactored
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '21

14 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25070 Bug ID: 25070 Summary: Include files to display address and contact must be refactored 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(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org There are 5 includes files per value of AddressFormat (us, de, fr). The code is duplicated for each language, the only thing that changes is the order. A refactoring is needed to avoid further regressions. -- You are receiving this mail because: You are watching all bug changes.

1 77

[Bug 24567] New: CCL syntax does not allow for multiple indexes to be searched at once
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24567 Bug ID: 24567 Summary: CCL syntax does not allow for multiple indexes to be searched at once 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 A search like: ti:glory and au:clinton should return results with glory in the title and clinton in the author, this works in Zebra but does not work in ES currently -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 23583] New: Make the BarcodeSeparators be a YAML syspref
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23583 Bug ID: 23583 Summary: Make the BarcodeSeparators be a YAML syspref 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 21932] New: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21932 Bug ID: 21932 Summary: reservetype and reserveexpiration needed for holds (reserves and old_reserves tables) Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 I see an inherent flaw in the reserves table and process. If a hold is waiting, and someone changes the status from waiting back to a priority level, the waiting status is removed, but the expiration remains. Also, if the hold was a first available hold, it is now changed to an item level hold for the item it was on hold for. I would suggest that a new field be created for the holds table, such as reservetype, and is marked as 'ANY' or 'SPECIFIC'. I would suggest that a new field be created for the reservation expiration called reserveexpiration, separate from the waiting expiration, as to maintain a reservation cutoff date if the status is changed back to a priority level. This would make the expirationdate exclusive to waiting items. I would suggest that when priority level is changed from waiting to a priority level, the reservetype is checked, and if it is marked as ANY, the item number be removed. If it is SPECIFIC, the item number is kept. I would suggest that the expirationdate be cleared if changed from a waiting status to a priority level. I would suggest that all pages that show the "Expiration date" as the reservationexpiration, if exists, or superseded by expirationdate, if exists. No need to have a separate cell for both. I would suggest that when a hold is triggered and marked as waiting, the expiration date is calculated, or limited to the reservationexpiration, whichever is shorter. No sense in holding it longer than the patron was willing to wait for it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22690] New: Merging problem with records with many items (ElasticSearch)
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22690 Bug ID: 22690 Summary: Merging problem with records with many items (ElasticSearch) 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: vitorfernandes87(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- When merging records with many items, Koha reindexes the origin record and the destination record for each item moving (check MoveItemFromBiblio in C4::Items). If the record being eliminated has 1000 items, Koha will make 2000 reindexes. Because of this behaviour, the merging is too slow. Test plan: - Create 2 records (one with 1000 items for example) - Add the records to one list and start the merging process of those records. - Choose the record with many items as the one to be eliminated. - Start the merging - After a while the web server should give you a timeout error (the merging process continues) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 253

[Bug 23035] New: Intranet search is slow if thousands of items are in the biblios shown in the search results
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '21

13 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23035 Bug ID: 23035 Summary: Intranet search is slow if thousands of items are in the biblios shown in the search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: joonas.kylmala(a)helsinki.fi Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If you search on intranet for biblios that have in total thousands of items then then the search result will load very very slowly. The slowing down is linear with the amount of items in the bibs. I already tracked this down to a GetAuthorisedValueDesc() call in C4/XSLT.pm. I will start working on a patch for this. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 24197] New: Custom destination for failed overdue notices
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24197 Bug ID: 24197 Summary: Custom destination for failed overdue notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Notices Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently failed overdue notices are sent to the branch email , or when that is not set to the KohaAdminEmailAddress syspref. Several of our clients have requested a seperate email address for failed overdue notices to be sent to. This email address will be defined in the: RedirectAddressForFailedOverdueNotices syspref. -- You are receiving this mail because: You are watching all bug changes.

1 40