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

[Bug 31727] New: Orphan records in circulation_rules and false positives after attempt to fix values to be empty or zeroes instead of missing
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31727 Bug ID: 31727 Summary: Orphan records in circulation_rules and false positives after attempt to fix values to be empty or zeroes instead of missing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Blocks: 29012 On smart-rules.pl (Home > Administration > Circulation and fine rules): we have 5 tables: 1. Defining circulation and fine rules for all libraries (... for XXX branch, if branch selected) 2. Default checkout, hold and return policy (... for XXX branch, if branch selected) 3. Checkout, hold policy by patron category (... for XXX branch, if branch selected) 4. Lost item fee refund on return policy (... for XXX branch, if branch selected) 5. Holds policy by item type (... for XXX branch, if branch selected) and with dropdown, we can select rules for "Standard rules for all libraries" or switch to ANY of the available branches represented by the whole page. Attempt to fix missing values in Bug 29012 had the atomic update, which filled up the circulation_rules table with values if ANY combination of "branch+category+itemtype" was found in the circulation_rules table. This had false positives for items from above-mentioned table 2,3,4,5 when assumed that only key/value pairs from table 1 should be those which affect the decision to add or not" new empty or zeroed item. This made the problem: after this atomic update, we have the circulation_rules table randomly filled with orphan elements for "table 1" even if no rules in table 1 for that branch were present in real. Worse: those orphan items are never shown as rows of real rules for the operator so not visible. Bad: those orphan items, for example, "issuelength" of 0 when it has some BRANCH overlaps ANY rule without branches and discretely changes behavior when issuing items. EXAMPLE: - Open smart-rules.pl and choose in the first dropdown "Select a library : " some BRANCH_NAME so this page will reload into BRANCH_NAME-targeted mode for the whole page. - Edit the last (5th) table "Holds policy by item type for BRANCH_NAME" value holdallowed to be set into something, and save it. You will see / still have "table 1" empty. - make the atomic update from Bug 29012 to fill those "zeroes and empties" - check the smart-rules.pl page for BRANCH_NAME-targeted mode: there will be still no rules in the 1st, "Defining circulation and fine rules for XXX branch" table, - but now check the database in raw mode: you will see that there will be a record: BRANCH_NAME will have, for example, "issuelength" of 0 key/value pair. - OUCH! What to fix: Now we need to invent a new atomic update to be applied after this one (and this is very non-trivial because we somehow need to preserve other proper values), to fix the database from orphan values. This anyway can lead to very unpredictable results. Another thing to consider is that we should even if unsure what is orphans - is to reveal all hidden values, i.e. append and populate other values to make a "full row" appear for the operator in the interface, so at least human can SEE wrong with those rules and then decide/delete but make impossible to have "remnants" and orphans hidden. PROBLEM 2: unseen_renewals_allowed vs unseenrenewalsallowed (sic!) we have 'unseen_renewals_allowed' everywhere in the codebase, except in this atomic update we have 'unseenrenewalsallowed'. And now DB is polluted even more :). This also should be fixed - and more: we might now have unseen_renewals_allowed and unseenrenewalsallowed both in database. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29012 [Bug 29012] Some rules are not saved when left blank while editing a 'rule' line in smart-rules.pl -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 31499] New: Add libhttp-tiny-perl 0.076 dependency for ES7
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31499 Bug ID: 31499 Summary: Add libhttp-tiny-perl 0.076 dependency for ES7 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: blocker Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com this small patch allows ES7 to work on deb10 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 31455] New: Batch modification tool orders found items by itemnumber
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31455 Bug ID: 31455 Summary: Batch modification tool orders found items by itemnumber Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using the batch mod tools and entering in a set of barcodes the table of found items is ordered by itemnumber instead of by the order in which the barcodes were scanned. This is a problem for librarians who scan a batch of books and then get a table ordered completely different. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 30909] New: Regression, Permanent shelving location is always updated when editing location if both are mapped to MARC fields
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30909 Bug ID: 30909 Summary: Regression, Permanent shelving location is always updated when editing location if both are mapped to MARC fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, nick(a)bywatersolutions.com Depends on: 27526, 27837 This issue was corrected in bug 27837, but bug 27526 led to a regression of that fix. To recreate: 1 - Map permanent_location to a marc field 2 - Expose that field in the item editor 3 - Change the location of the item and retain the permanent location on saving 4 - note that permanent location has changed anyway Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27526 [Bug 27526] Remove Mod/AddItemFromMarc from additem.pl https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27837 [Bug 27837] Permanent location is reverted to location when location updated and permanent_location mapped to MARC field -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 26995] New: Drop column relationship from borrower tables
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26995 Bug ID: 26995 Summary: Drop column relationship from borrower tables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 14570 added a borrower_relationships table but it didn't remove the relationship column from the following tables: - deletedborrowers - borrowers - borrower_modifications It will need to be removed from many of the same places as "guarantorid" from Bug 14570 like: - C4/Auth_with_ldap - C4/SIP/ILS/Patron.pm - Possibly other places... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 6796] Overnight checkouts taking into account opening and closing hours
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6796 Hanna Dehlin <hanna.dehlin(a)hkr.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hanna.dehlin(a)hkr.se -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28543] New: Clicking on 'New record' will use default framework
by bugzilla-daemon＠bugs.koha-community.org 13 Oct '22

13 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28543 Bug ID: 28543 Summary: Clicking on 'New record' will use default framework Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In biblio records cataloguing, clicking on 'New from z39.50/SRU' will run action with default framework. Clicking on 'New record' sould do the same. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 15428] Different timeout preference for opac and intranet
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15428 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us --- Comment #6 from Rebecca Coert <rcoert(a)arlingtonva.us> --- I think having a timeout difference for Staff vs. Others would be extremely useful. Our public services staff each have their own login and cycle through service desks every hour. Being able to ensure their account is logged out after a set amount of time would be helpful. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28372] New: Use variables for 007 controlfield translations in MARC21slim2intranetResults.xsl
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28372 Bug ID: 28372 Summary: Use variables for 007 controlfield translations in MARC21slim2intranetResults.xsl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Slight performance improvement over fetching the same field every time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 14364] Allow automatically canceled expired waiting holds to fill the next hold
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14364 Rebecca Coert <rcoert(a)arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert(a)arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.

1 0