Opt-in boundaries break opting in if no boundaries are set?

Bug #1038267 reported by Dan Scott
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
2.2
Fix Released
Undecided
Unassigned
2.3
Fix Released
Undecided
Unassigned

Bug Description

* Evergreen 2.3.0-beta1

So back in bug #510959, the new "patron opt-in boundary" feature was being kicked around and although the code hadn't been tested with opt-in actually turned on, it was determined that it should be pushed into master (eventually seeing the light of day in 2.2.0). This may be a good cautionary tale about why we want to test things before pushing them into master, as when we upgraded from 2.1 to 2.3, our opt-in stopped working.

user/dbs/defensive_opt_in in working addresses the base problem, per the comments from the bug:

If a site had not set an 'org.patron_opt_default' OU setting, then it seemed that a DEFAULT value was getting dumped into the "create opt-in" INSERT statement for the org_unit argument, and that (as there is a non-NULL constraint on the column and no default value for the column) resulted in the patron not getting opted in.

One way for sites to deal with this is to set an opt-in boundary at the consortial level, along the lines of:

    INSERT INTO actor.org_unit_setting (org_unit, name, value)
      VALUES (1, 'org.patron_opt_default', 2);

Alternatively, in the absense of any such setting, opt-in should continue to work as it had before the new feature was added; this change keeps the old behaviour active in that case.

(Note that in our case, we added the OU setting and also applied the patch in the branch; the patch will help keep things working for other sites as they were before the addition of the feature).

Once again, that's user/dbs/defensive_opt_in in working and it should be applied all the way back to rel_2_2.

Ben Shum (bshum)
Changed in evergreen:
milestone: 2.3.0-beta2 → 2.3.0-rc1
Changed in evergreen:
milestone: 2.3.0-rc1 → 2.3.0
Changed in evergreen:
milestone: 2.3.0 → 2.3.1
Changed in evergreen:
milestone: 2.3.1 → 2.4.0-alpha
Changed in evergreen:
status: New → Triaged
Revision history for this message
James Fournie (jfournie) wrote :

Hi there, we'd been running this patch for years on production and didn't encounter this issue as we always have had consortial level settings. I removed all our settings but left opt-in turned on and tested an opt-in and got a xulrunner error, in applying this patch the error went away, so I have signed off on it and pushed to user/jamesrf/defensive_opt_in

Ben Shum (bshum)
tags: added: signedoff
Revision history for this message
Ben Shum (bshum) wrote :

Thanks Dan and James! Picked to master, rel_2_3 and rel_2_2.

Changed in evergreen:
status: Triaged → Fix Committed
Ben Shum (bshum)
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.