Bug 23434 - Hold confirmation dialog problem if HoldsAutoFill is enabled
Summary: Hold confirmation dialog problem if HoldsAutoFill is enabled
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
: 23209 (view as bug list)
Depends on: 23399
Blocks: 23433
  Show dependency treegraph
 
Reported: 2019-08-06 13:30 UTC by Owen Leonard
Modified: 2021-12-13 21:09 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
19.11.00


Attachments
Checking a hold for another library with HoldsAutoFill enabled (25.82 KB, image/png)
2019-08-06 13:30 UTC, Owen Leonard
Details
Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled (24.80 KB, patch)
2019-08-06 14:08 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled (24.85 KB, patch)
2019-08-08 12:00 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled (24.85 KB, patch)
2019-08-08 15:11 UTC, Martin Renvoize
Details | Diff | Splinter Review
Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled (24.92 KB, patch)
2019-08-08 16:03 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2019-08-06 13:30:11 UTC
Created attachment 92025 [details]
Checking a hold for another library with HoldsAutoFill enabled

If the HoldsAutoFill system preference is enabled, the hold confirmation dialogs on the check-in page are badly constructed, resulting in duplicate information and inconsistent displays. See attached screenshot
Comment 1 Owen Leonard 2019-08-06 14:08:27 UTC Comment hidden (obsolete)
Comment 2 Lisette Scheer 2019-08-06 20:32:10 UTC
*** Bug 23209 has been marked as a duplicate of this bug. ***
Comment 3 Martin Renvoize 2019-08-08 12:00:40 UTC Comment hidden (obsolete)
Comment 4 Martin Renvoize 2019-08-08 12:01:10 UTC
Fixes the exposed issue.. Signing off.. thanks Owen
Comment 5 Katrin Fischer 2019-08-08 15:07:54 UTC
Patch doesn't apply for me :(

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled
error: sha1 information is lacking or useless (koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt).
error: could not build fake ancestor
Patch failed at 0001 Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Patch left in /tmp/Bug-23434-Hold-confirmation-dialog-problem-if-Hold-wUIahn.patch
Comment 6 Martin Renvoize 2019-08-08 15:11:42 UTC Comment hidden (obsolete)
Comment 7 Martin Renvoize 2019-08-08 15:15:33 UTC
hmm.. try now?
Comment 8 Katrin Fischer 2019-08-08 16:03:43 UTC
Created attachment 92093 [details] [review]
Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled

This patch corrects a problem with hold confirmation dialogs on the
checkin page when the HoldsAutoFill system preference is enabled and the
item being checked in has a hold at another library.

The confirmation dialog is converted to a modal to match other
confirmation information.

As part of this process two whole sections of the template have been
removed because they were redundant.

To test, apply the patch and test the following circumstances both with
HoldsAutoFill enabled AND disabled:

 - A hold for a patron at your library
 - A hold for a patron not at your library
   - With HoldsAutoFill ON, both the "OK" and "Print slip and confirm"
     buttons should dismiss the modal without reloading the page.
 - A hold which is already marked 'Waiting'
 - An item which needs to be transferred
 - An item which has already been transferred

In all cases the confirmation modal should appear with correct
information.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 9 Martin Renvoize 2019-08-12 13:38:19 UTC
Nice work!

Pushed to master for 19.11.00
Comment 10 Fridolin Somers 2019-08-29 08:24:38 UTC
Depends on Bug 23399 not in 19.05.x