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

[Bug 35516] New: OPAC search results incorrectly displays order when skipping lost items
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35516 Bug ID: 35516 Summary: OPAC search results incorrectly displays order when skipping lost items Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 159660 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=159660&action=e… Lost item is skipped in ordered list. To recreate: 1. Ensure the system preference hidelostitems is set to don't show. 2. Search the staff interface using search catalog with a term that returns several results. Select a bib record with an item and change the status to lost. (In my example, I choose an item in the 4th result). 3. Do a search in the OPAC for the same term. See that the results are ordered in the list 1, 2, 3, 5, 6. The system preference is doing its job and hiding the lost item. However, the results should be ordered 1, 2, 3, 4, 5, etc., and not indicate that an item was skipped or suppressed. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 33673] New: Global system preferences - change to just system preferences
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33673 Bug ID: 33673 Summary: Global system preferences - change to just system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Day-to-day, we normally just refer to "system preferences" rather than "global system preferences". I don't think there is any clear distinction between "Global system preferences" and "System preferences", or any need to have the "Global". This would mean changing Administration > Global system preferences to just "System preferences". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 31361] New: Button batch operations disappears when alias is used for itemnumber of biblionumber
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31361 Bug ID: 31361 Summary: Button batch operations disappears when alias is used for itemnumber of biblionumber Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: j.m.koopmans(a)saxion.nl QA Contact: testopia(a)bugs.koha-community.org Created attachment 139128 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139128&action=e… screenshot report result with batch modification button When running a SQL-report and using an alias for itemnumber or biblionumber in SELECT, the button for 'Batch operations with 20 visible records' disappears. Using an alias for other columns is no problem. Example SQL with button: SELECT items.itemnumber,items.barcode,items.notforloan as Status,biblio.title,items.ccode as Itemtype FROM items LEFT JOIN biblioitems on (items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN biblio on (biblioitems.biblionumber=biblio.biblionumber) WHERE items.homebranch=<<homebranch|branches>> AND items.itype=<<itype|itemtypes>> AND items.notforloan=<<notforloan>> ORDER BY items.itemnumber asc Changing it to 'SELECT items.itemnumber as Itemnr, etc.' removes the button and the ability for batch processing. The same thing occurs when using an alias for biblionumber in a report. Example SQL with button: SELECT CONCAT ('<a href=\"/cgi-bin/koha/catalogue/detail.pl?biblionumber=',biblio.biblionumber,'\" target=new>',biblio.title,' </a>') as Titel, items.biblionumber,biblio.datecreated as Datum FROM items LEFT JOIN biblioitems on (items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN biblio on (biblioitems.biblionumber=biblio.biblionumber) where date (datecreated) BETWEEN <<From date|date>> AND <<To date|date>> ORDER BY biblio.datecreated desc Changing 'items.biblionumber to items.biblionumber as Biblionr' removes the button. Also tested it in version 20.11 with the same results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 34075] New: Allow specifying default tab view for authorities
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34075 Bug ID: 34075 Summary: Allow specifying default tab view for authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently the authorities page defaults to the first tab in the record, generally 0XX Some libraries would like this to default to the 1XX, or other tabs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 34677] New: Update to MARC21 relator terms list
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34677 Bug ID: 34677 Summary: Update to MARC21 relator terms list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I received a technical update to the MARC21 format for August 2023 which included new relator terms. I noticed that the list in Koha hadn't been updated in a while, so I went through the technical notices and added them. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 35190] New: additional_fields table should allow null values for authorised_value_category
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35190 Bug ID: 35190 Summary: additional_fields table should allow null values for authorised_value_category Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 29390 When creating an Additional Field in the staff interface, the UI explicitly allows the Additional Field not to be linked to an authorized value. However, the database doesn't allow NULL values for authorised_value_category in the additional_fields table. Instead, an empty string is inserted into the database if the user chooses not to link an authorized value. This is not good practice, and does not allow a foreign key constraint to be properly implemented. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29390 [Bug 29390] Authorised values: Add a few missing foreign keys -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 34178] New: Add caching of ItemsAnyAvailableAndNotRestricted to IsAvailableForItemLevelRequest
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34178 Bug ID: 34178 Summary: Add caching of ItemsAnyAvailableAndNotRestricted to IsAvailableForItemLevelRequest Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There are several places in the code where we precalculate ItemsAnyAvailableAndNotRestricted to avoid looping on this routinee when calling IsAvailableForItemLevelRequest on a list of items form a biblio The value of ItemsAnyAvailableAndNotRestricted is only used when there is a circulation rule for 'onshelfholds' with a value of '2' (If all unavailable) Rather than calculate a value that may never be used, let's cache this value per request when we do calculate it - and reuse the cached value -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 35225] New: Improve AllowRenewalIfOtherItemsAvailable performance
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35225 Bug ID: 35225 Summary: Improve AllowRenewalIfOtherItemsAvailable performance Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If patron has lot of issues and record has lot of holds the performance of AllowRenewalIfOtherItemsAvailable is poor. Looping through possible holds and available items takes ages. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 35513] New: DataTable controls being retained throughout different acq baskets
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '23

06 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35513 Bug ID: 35513 Summary: DataTable controls being retained throughout different acq baskets Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1. Add 2 vendors, Vendor A and Vendor B 2. Create a basket with Vendor A that has more than 20 items in it. 3. Close basket, receive. 4. Note the URL on are at. Something like /cgi-bin/koha/acqui/basket.pl?basketno=3 5. Create another basket with Vendor B, this one should have less than 10 items. 6. Close basket, receive. URL /cgi-bin/koha/acqui/basket.pl?basketno=4 7. Now go back to the first basket and change go to the 2nd page ( pagination ). 8. Now open up the 2nd basket, It looks like there are no items but this is because it is trying to paginate to the 2nd page which doesn't exist in this case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 29291] New: Self Registration e-mail verification is not stored in notices
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '23

06 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29291 Bug ID: 29291 Summary: Self Registration e-mail verification is not stored in notices 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: 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 the self registration e-mail verification was stored in the notifications. Any password that might be in the message could be masked in storage. Or the message itself could be masked. We would at least have a record of the attempt. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13