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

[Bug 30392] New: Add a deleted_on column to deleteditems
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '23

17 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30392 Bug ID: 30392 Summary: Add a deleted_on column to deleteditems Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 23081 did an udpate on the data in deleteditems resulting in a lot of timestamps being reset, leaving libraries without the cataloguing log without any information about when the item was deleted. To avoid this in the future, it would be much better to have a separate column to store the deletion date of an item. The catalouging log is not always a good option in big libraries as we don't differentiate between item, bibliographic and authority record updates, so it creates a lot of data and it might also be deleted in some. The information about when an item was deleted is needed in some libraries to avoid having to document this on paper in an inventory book and as such should be saved in a save spot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 42

[Bug 30077] New: Add option for library dropdown in search function for staff interface
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '23

17 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30077 Bug ID: 30077 Summary: Add option for library dropdown in search function for staff interface Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The functionality of OpacAddMastheadLibraryPulldown would be helpful to have on the staff interface. Often staff need to limit their search a specific library, without having to go to the advanced search. This would be an excellent addition, and by default, should limit to the library you are logged in to, with the option via the dropdown to search all libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 26788] New: Circulation rule note field too small.
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '23

17 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26788 Bug ID: 26788 Summary: Circulation rule note field too small. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 The note field does not allow enough room for notes. Should be much bigger and allow for multiline entry, similar to circulation note in patron account. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 21762] New: ES: Is it possible to differentiate between any and anywhere?
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '23

17 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21762 Bug ID: 21762 Summary: ES: Is it possible to differentiate between any and anywhere? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl See also bug 8962 about differentiating any from anywhere in Zebra. Any would be the sum of all user defined indexes, and anywhere would really be all data. Is this possible in Elastic Search ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32510] New: "New list" option is not available when too many patron's lists
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32510 Bug ID: 32510 Summary: "New list" option is not available when too many patron's lists 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: marie-luce.laflamme(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 144753 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=144753&action=e… bottom of the drop-down menu is not showing "New list" It's impossible to add a patron to a new list when Koha has more than 30 patrons’ lists. This behaviour affects the "add patron to list" drop-down menu in the patron search page (Patrons module > patron search > add to patron list button ). Koha will show an endless drop-down menu without the "New list" option, so you can't create more lists. This unfortunate behaviour is causing issues in large school who love and use over 700 patrons' lists. Test plan 1. Go to Patron module 2. Search for patrons 3. Select few accounts 4. Click on "add to patron list", then choose "New list" If your Koha has a little number of patrons’ lists, add some more until you've reached a total of 30 lists. 5. When you've reached 30 lists, try to add a patron to a new list --> the "new list" option is no longer available after 30 lists -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 31994] New: Clicking the next button of a DataTable loading its data from the HTML does nothing
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31994 Bug ID: 31994 Summary: Clicking the next button of a DataTable loading its data from the HTML does nothing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: olivier.hubert(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When the next button of a DataTable with data straight from the HTML is clicked, nothing happens. Additionally, an error can be found in the console similar to: Uncaught TypeError: q is undefined Note that this problem does not occur when the data is sourced using Ajax. Steps to reproduce: 1. Open itemtypes.pl. 2. If there are fewer than 11 item types, create additional item types until there are more than 10, so that the next button can be used. 3. Click on the next button / link. 4. Notice that nothing happens. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 31640] New: Fuzzy translations of preferences can cause missing sections and inaccurate translations
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31640 Bug ID: 31640 Summary: Fuzzy translations of preferences can cause missing sections and inaccurate translations Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: kevin.carnes(a)ub.lu.se QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr We noticed that when installing the Swedish translations in 22.05, the translate program was using fuzzy translations for preferences. This resulted in many strange translations when viewing the preferences in Swedish. There were also some sections that were missing since multiple sections had the same translated name and there can only be one section for each name since they are hash keys. Our solution is to ignore fuzzy translations for preferences, since we prefer the original English, but it can be made an option if the fuzzy translations are helpful to others. The solution also adds warnings if a translation causes multiple sections to have the same name. When I run the warnings with fuzzy translations in 22.05.03, I get warnings in 65 languages (am-Ethi, ar-Arab, az-AZ, be-BY, bg-Cyrl, bn-IN, ca-ES, cs-CZ, cy-GB, da-DK, de-CH, el-GR, en-GB, en-NZ, eo, eu, fa-Arab, fr-CA, gl, he-Hebr, hi, hr-HR, hu-HU, hyw-Armn, id-ID, is-IS, ja-Jpan-JP, ka, ko-Kore-KP, ku-Arab, lo-Laoo, mi-NZ, mon, mr, ms-MY, nb-NO, ne-NE, nl-BE, nl-NL, nn-NO, oc, pbr, pl-PL, prs, pt-BR, pt-PT, ro-RO, ru-RU, sd-PK, sk-SK, sl-SI, sq-AL, sr-Cyrl, sv-SE, ta-LK, te, tet, th-TH, tl-PH, tr-TR, uk-UA, ur-Arab, vi-VN, zh-Hans-CN, zh-Hant-TW). If there are languages where multiple sections should have the save name, we can discuss using an array instead of a hash for the sections. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 25590] New: B_streetnumber is missing from opac-memberentry.pl
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25590 Bug ID: 25590 Summary: B_streetnumber is missing from opac-memberentry.pl 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: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If a patron adds an alternate address to their patron record in the OPAC, there is no option to enter a street number. This field is available in the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 18280] New: Item barcodes should be locked when record is created
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18280 Bug ID: 18280 Summary: Item barcodes should be locked when record is created Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When several cataloguers are cataloguing simultaneously and the autoBarcode system preference is set to generate the barcodes in 1, 2, 3 form, it is possible that the same item barcode will be assigned to two different items at the same time which prevents the record from being saved. Koha should lock the barcode in some way once it has been allocated, even if the item record is not yet saved. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 30277] New: Make fetching ILL data from the API more efficient
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30277 Bug ID: 30277 Summary: Make fetching ILL data from the API more efficient 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 Librarians are complaining that displaying the full table of ILL requests is taking a lot of time, even with moderate amounts of requests (on the order of 100-200). I think there are a couple of bottlenecks: 1. Embedding data We are embedding - metadata - patron - capabilities - library - status_alias - comments - requested_partners That's at least 6 additional queries times the number of requests in the table. Not sure what can be done here in general, though. 2. Capabilities/status graph For every request, the whole status graph is included with each request. When I look at the JSON data returned for one request in a sample database, it is about 540 lines of data. But about 400 of those make up the status graph, and since this system only has one active backend, those 400 lines are (as far as I can see) identical for all 200 requests. Could we send the status graph once per backend, and then have some reference/link from the request to the correct status graph? 3. Fetching requests selectively Today, data is fetched for all requests not hidden by ILLHiddenRequestStatuses before the table of requests is displayed. Bug 30200 proposes to add configurable tabs to the ILL requests table. Could it be possible to load the data for the tabs just-in-time, so that only the data for the first tab is loaded initially? Instead of loading everything just-in-case when the page is first shown. And then have the "All" tab to the right, so that "all" data is only loaded if the user asks for it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5