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

[Bug 33326] New: When adding an item to a basket from a purchase suggestion SUGGEST_FORMAT is lost
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33326 Bug ID: 33326 Summary: When adding an item to a basket from a purchase suggestion SUGGEST_FORMAT is lost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org I know we can't copy over the item type since they won't necessarily match, but it would be very helpful if there was a "suggestion requested format" or similar. Even better if it could check and if the value matches the item code if it could match them. Lisette -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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

[Bug 13614] Replace usage of YUI on basket groups page
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13614 --- Comment #14 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Jonathan Druart from comment #13) > Did we forget to remove koha-tmpl/intranet-tmpl/prog/js/basketgroup.js? We did, but fixed now. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23021] New: Quick Spine Label Creator doesn't use regex splitting rule
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23021 Bug ID: 23021 Summary: Quick Spine Label Creator doesn't use regex splitting rule Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- I'm working with a library that enters their LCC call numbers in the format "PN6728 .B36" rather than "PN 6728 .B36." This means that the default LCC splitting rule doesn't insert a line break between PN and 6728. So I wrote a regex splitting rule that does that fine. However, the regex splitting is only applied when using the full label creator. When printing via the quick spine label creator it appears to still be splitting based on the default LCC splitting rule. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 28395] New: allow patron enrollment period to be set in days for patron categories
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28395 Bug ID: 28395 Summary: allow patron enrollment period to be set in days for patron categories 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Admin > Patron categories Some libraries would find it useful to be able to set the enrollment period in days instead of months. Currently you can only set it in months. It would be handy if we could set it in days or months. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 27642] New: Add notes to receipts
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27642 Bug ID: 27642 Summary: Add notes to receipts Change sponsored?: --- Product: Koha Version: master 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 Would love it if there were a way to add notes to the bottom of checkout receipts - Maybe a piece of information a patron wants that we could manually fill out - maybe called "Receipt Notes". It would also be cool if down the road, if a patron has a book checked out, and they wanted to have a list of books in the series, that there would be some kind of button or link next to the book we could click that would add that list to these notes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 30265] New: Hide 'Log into your account' in OPAC authentication page
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30265 Bug ID: 30265 Summary: Hide 'Log into your account' in OPAC authentication page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 131536 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=131536&action=e… Screenshot showing double auth form If not logged in, in OPAC header there is link 'Log into your account'. Using it shows a popup with authentication form. In authentication page /cgi-bin/koha/opac-user.pl this double authentication form feels not ergonomic. It may lead to misunderstanding. We can simply hide this link in this special page. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 31231] New: Link authorities automatically does not always work
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31231 Bug ID: 31231 Summary: Link authorities automatically does not always work Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: hc(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 11299 introduced the "Link authorities automatically" function. When the button is used for fields with only the main heading or the main heading and one subheading, it works. However, I've noticed a few instances of it not picking up already existing authority records. When this happens, it generates a new authority record. Then, if the same authority is used in a new bibliographic record the "Link authorities automatically" button will link to the newly created, duplicate authority. Example: In a new bibliographic record, the 650 fields are filled out as follows: 650$a - Biology 650$x - Research 650$y - 1960 There is already an authority record with this content in the 150 field: 150$a - Biology 150$x - Research 150$y - 1960 When the "Link authorities automatically" is clicked, the original authority is not picked up, but a duplicate authority is created. On a new bibliographic record, the same information is added to the 650 fields and the "Link authorities automatically" is clicked and the duplicate authority is linked, not the original one. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 31298] New: Framework defaults don't work when adding records to basket from external source
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '23

16 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31298 Bug ID: 31298 Summary: Framework defaults don't work when adding records to basket from external source Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In 21.11.05, it appears that framework defaults aren't working properly when adding records to a basket from an external source. To test: 1) Set the following framework/942$c defaults: ACQ/NEW, Default/BOOK, SR/MAG 2) Set UseACQFrameworkForBiblioRecords to "Use the framework 'ACQ' for bibliographic records fields" 3) Create a basket, and add to it 'From an external source' 4) Select the SR framework prior to searching via z39.50 5) Bring in your record, and view the bib - note that 942$c is blank 6) Repeat steps 3-5 with Default and ACQ frameworks selected - the result is the same. The same thing happens when steps 3-6 are repeated with UseACQFrameworkForBiblioRecords set to "Don't use". At least as recently as 20.05, selecting a specific framework in step 4 above would override the ACQ framework when UseACQFrameworkForBiblioRecords was set to "use". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8