Web Client: Opt-in Action Triggers, set as Registration Default will prevent Patron Registration screen from loading

Bug #1695029 reported by Michele Morgan on 2017-06-01
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Master
High
Unassigned

Bug Description

Evergreen 2.12

When any opt-in action trigger is set to be a registration default, (i.e. the opt-in trigger is checked by default at registration time) the web client new registration page will not load.

To reproduce, make the stock opt-in action trigger "Email Checkout Receipt" opted in by default when a new patron is registered:

-Go to Administration -> Server Administration -> User Setting Types
-Double click to edit the setting 'circ.send_email_checkout_receipts'
-Enter 'True' (without the quotes) in the Registration Default field and Save

Login to the web client and go to Circulation -> Register Patron. The progress bar displays, but the page never loads.

In the xul client, setting Registration Default for the user setting type to True puts a check in the trigger's checkbox on the patron registration page, opting in the patron by default unless it's unchecked prior to saving.

Cesar V (cesardv) wrote :
Changed in evergreen:
assignee: nobody → Cesar V (cesardv)
tags: added: pullrequest
Cesar V (cesardv) on 2017-07-14
Changed in evergreen:
assignee: Cesar V (cesardv) → nobody
Cesar V (cesardv) on 2017-07-17
Changed in evergreen:
status: New → Confirmed
status: Confirmed → Fix Committed
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Changed in evergreen:
status: Fix Committed → Confirmed
assignee: Mike Rylander (mrylander) → nobody
Changed in evergreen:
assignee: nobody → Josh Stompro (u-launchpad-stompro-org)

Signoff branch - user/stompro/lp1695029_webstaff_patron_reg_screen_signoff
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1695029_webstaff_patron_reg_screen_signoff

I had no problem loading the patron registration screen after applying this patch and following the test plan. Tested on a 7/18/2017 version of master.

Josh

Changed in evergreen:
assignee: Josh Stompro (u-launchpad-stompro-org) → nobody
tags: added: signedoff
Rogan Hamby (rogan-hamby) wrote :

Tested and worked as expected, sign off here: user/rogan/lp1695029_patronreg_signoff

Bill Erickson (berick) on 2017-07-21
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Follow-up branch pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1695029-patron-reg-opt-in-defaults

1. I merged Rogan's and Josh's sign-offs to one commit. (Rogan's branch doesn't have them, presumably a thinko).

2. The feature described in this bug is not really a supported feature. It just happens to work.
 Putting /any/ value as the default ("true", "false", "What's the frequency Kenneth?") results in the checkbox being checked in the XUL editor. I get the gist, though, so I pushed a second commit to my branch that inspects the default value of boolean user settings for a true-looking thing and treats it accordingly. It also avoids attempts to Boolean-ize non-boolean (e.g. 'string') settings.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: removed: signedoff
Changed in evergreen:
milestone: none → 3.0-alpha

Bill, thanks for seeing and fixing that problem. I just tested your patch and can confirm that any value starting with 't' now causes the checkbox to be set, and any other value causes it to be unset. The form still loads like it should also.

Signoff Branch: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1695029-patron-reg-opt-in-defaults-signoff2

Josh

tags: added: signedoff
Galen Charlton (gmc) on 2017-07-24
Changed in evergreen:
milestone: 3.0-alpha → 2.12.4
no longer affects: evergreen/2.12
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
Changed in evergreen:
milestone: 2.12.4 → 2.12.5
Jason Stephenson (jstephenson) wrote :

I tested this branch on a rel_2_12_4 VM where the initial problem did not show, i.e. patron registration worked. After installing this branch, patron registration still worked.

On our training server with rel_2_12_3, otherwise practically the same code as the above, patron registration does not load and the progress bar spins. That behavior continues after loading this branch on training, so we have likely stumbled on another bug. I will do a little more investigation to see if I can determine the cause.

Jason Stephenson (jstephenson) wrote :

Turns out, I've stumbled across bug 1702756.

Changed in evergreen:
milestone: 2.12.5 → 2.12.6
Galen Charlton (gmc) on 2017-08-30
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :

Looks good to me, pushed to master. Thanks!

One note when testing, and probably worthy of a different bug, when I went to set the Registration Default, the dialog changed the Datatype to String instead of keeping it Boolean. It looks like the drop-down is actually sticky within any given page load of the User Settings Type page.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Jason Etheridge (phasefx) → nobody
no longer affects: evergreen
Jason Etheridge (phasefx) wrote :

also, I seem to have broken the milestone/series target thingy :)

Jason Etheridge (phasefx) wrote :

pushed to rel_2_12

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers