[Koha-bugs] [Bug 20844] Reset a hold when it is missing after allocation

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Aug 11 23:12:17 CEST 2023


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844

Emily Lamancusa <emily.lamancusa at montgomerycountymd.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Failed QA                   |Patch doesn't apply

--- Comment #63 from Emily Lamancusa <emily.lamancusa at montgomerycountymd.gov> ---
I'd love to see this move forward soon! It needs a minor rebase and fixes for
the two issues I noticed the last time I tested, but then I think I'll be able
to sign off on it.

I was able to fix the first issue locally by making the following change in
circulation.pref:

- 690    yes: Revert
- 691    no: "Don't revert"

+ 690    1: Revert
+ 691    0: "Don't revert"

The issue was that the code in most places checked the syspref as follows:
if ( C4::Context->preference('RevertLostBibLevelHolds') )
which evaluates to true for both "yes" and "no". (The default was put into the
database as 0, so the odd behavior only occurs after the pref has been
changed.)

--------

For the second issue - do moredetail.tt and additem.tt have access to the
syspref value in any way? It's not clear to me whether either of the template
files is taking the value of the syspref into account when determining whether
to display the confirmation alert for handling a lost item-level hold. However,
all of the .pl files in the patches perform the actual handling of lost
item-level holds inside of a conditional that checks the syspref. I assume the
templates should be checking that data somehow as well, so as to display the
alert only if the syspref is set to "revert"?

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list