Deal with opt-in boundaries defensively user/jamesrf/defensive_opt_in
authorDan Scott <dscott@laurentian.ca>
Fri, 17 Aug 2012 20:07:19 +0000 (16:07 -0400)
committerJames Fournie <jfournie@sitka.bclibraries.ca>
Thu, 13 Dec 2012 22:10:35 +0000 (14:10 -0800)
commitbaabc526ba39f7498e5bf3a97f9c0fdfccd262d5
treee3188f5398d854bc04a7369a56492bc81d307090
parent6c71f0264e598fa73648de12f5ff51a678b6fc00
Deal with opt-in boundaries defensively

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.

Signed-off-by: Dan Scott <dscott@laurentian.ca>
Signed-off-by: James Fournie <jfournie@sitka.bclibraries.ca>
Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm