https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20844 --- Comment #99 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198372 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198372&action=edit Bug 20844: (follow-up) Send notice on revert, use cancel reason on cancel The previous LOST_WAITING_HOLD notice was sent at the moment an item was marked lost, before staff had decided whether to revert or cancel the hold. The wording also incorrectly claimed "Your hold awaiting pickup is no longer available" even when the underlying hold was in transit and no waiting notification had ever been sent. Rework the patron messaging so that: * When a hold is cancelled because its allocated item is lost, the newly added LostItemHoldCancellationReason system preference (an authorised value from the HOLD_CANCELLATION category) is applied as the cancellation reason. This drives the existing HOLD_CANCELLATION notice, which libraries can already customise per reason. Leaving the preference empty cancels without a reason and sends no notice. * When a *waiting* hold is reverted (because the allocated item was marked lost), the new HOLD_LOST_REVERTED notice is enqueued, gated by SendLostHoldNotices. The wording explains the hold is still active and another copy will be allocated. * When an *in-transit* hold is reverted, no notice is sent — the patron has not been told the hold is awaiting pickup yet. The LOST_WAITING_HOLD notice is removed (deleted on upgrade and dropped from sample_notices.yml). The lost-item dialog wording on the items tab and add-item screen now refers to "waiting or in transit" holds and a generic "Revert hold" button so both states read sensibly. Test plan: 1) Apply patches, run database update, restart memcached and plack 2) Confirm the HOLD_LOST_REVERTED notice exists under Tools -> Notices and slips and that LOST_WAITING_HOLD is gone 3) Create an authorised value (e.g. LOSTITEM) under HOLD_CANCELLATION 4) Set system preferences: RevertLostBibLevelHolds: Revert SendLostHoldNotices: Send LostItemHoldCancellationReason: LOSTITEM 5) Place a biblio-level hold, check in to set it Waiting, then mark the allocated item lost. Confirm the hold is reverted and the HOLD_LOST_REVERTED notice was enqueued for the patron. 6) Repeat with a transferred (in-transit) biblio-level hold. Confirm the hold is reverted and NO notice was enqueued. 7) Place an item-level hold, set it Waiting, mark the item lost. On the dialog choose "Revert hold". Confirm HOLD_LOST_REVERTED was enqueued. 8) Repeat with an item-level transferred hold and "Revert hold". Confirm NO notice was enqueued. 9) Place an item-level hold, set it Waiting, mark the item lost, choose "Cancel hold". Confirm the hold is cancelled and the HOLD_CANCELLATION notice was enqueued (with the reason set to the authorised value LOSTITEM). 10) Clear LostItemHoldCancellationReason and repeat step 9. Confirm the hold is cancelled and NO HOLD_CANCELLATION notice is sent. 11) Confirm tests still pass: prove t/db_dependent/Reserves.t -- You are receiving this mail because: You are watching all bug changes.