We have inconsistent use of patron-title.inc in returns.tt. Sometimes it is used and sometimes it isn't. Where it was added it seems to have reversed the display of patron surname and first name: Previously last, first; now first last. All uses of patron-title.inc in this situation should be consistent.
Created attachment 92032 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled
Owen, I can no longer cleanly apply this patch to master. If you can rebase it, I will attempt to sign off
Created attachment 100277 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled - An item which has been marked with a LOST status in the 'ClaimReturnedLostValue' system preference.
I guess returns.tt is a moving target, sadly this again doesn't apply cleanly. :(
Created attachment 100916 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled - An item which has been marked with a LOST status in the 'ClaimReturnedLostValue' system preference. - An item which was checked out to a manually-restricted patron and checked in with a back-dated checkin date. See test plan on Bug 24776.
These all display the name as (surname, firstname) except when I turn on HoldsAutoFill. It then displays (firstname, surname). Not sure if that matters but wanted to point that out before signing off.
Yes, I get the same. When HoldsAutoFill is enabled, the 'hold-found1' modal isn't launched. Instead, it's 'dialog alert hold-auto-filled' - and this patch doesn't seem to update that part of returns.tt Once that's done, it'll work perfectly. :)
Created attachment 104028 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled - An item which has been marked with a LOST status in the 'ClaimReturnedLostValue' system preference. - An item which was checked out to a manually-restricted patron and checked in with a back-dated checkin date. See test plan on Bug 24776.
Thanks to all who tested. I corrected two more sections of the template with the standard configuration of the include. (In reply to Sally from comment #7) > When HoldsAutoFill is enabled, the 'hold-found1' modal isn't launched. I think this is the correct behavior, because HoldsAutoFill is supposed to minimally interrupt the workflow.
(In reply to Owen Leonard from comment #9) > Thanks to all who tested. I corrected two more sections of the template with > the standard configuration of the include. > > (In reply to Sally from comment #7) > > > When HoldsAutoFill is enabled, the 'hold-found1' modal isn't launched. > > I think this is the correct behavior, because HoldsAutoFill is supposed to > minimally interrupt the workflow. It's the right behaviour, I agree - I was just trying to explain what I noticed when the patch didn't work so it would be (hopefully!) easier to identify and fix. :)
Created attachment 104105 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled - An item which has been marked with a LOST status in the 'ClaimReturnedLostValue' system preference. - An item which was checked out to a manually-restricted patron and checked in with a back-dated checkin date. See test plan on Bug 24776. Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Works great, thanks Owen.
Created attachment 104114 [details] [review] Bug 23433: Make consistent use of patron-title.inc in hold confirmation dialogs Use of patron-title.inc on the checkin page is inconsistent, resulting in patron names being displayed differently under different circumstances. This patch makes it more consistent. To test, apply the patch and check in items with the following statuses: - On hold for a patron at your library - On hold for a patron not at your library - On hold and already marked 'Waiting' - On hold while HoldsAutoFill preference is enabled - An item which has been marked with a LOST status in the 'ClaimReturnedLostValue' system preference. - An item which was checked out to a manually-restricted patron and checked in with a back-dated checkin date. See test plan on Bug 24776. Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Thx Owen and Sally!
Created attachment 104251 [details] [review] Bug 23433: (RM follow-up) One last consistency improvement Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Nice work everyone! Pushed to master for 20.05
doesn't apply cleanly to 19.11.x please rebase if needed.