Deal with opt-in boundaries defensively user/dbs/defensive_opt_in
authorDan Scott <dscott@laurentian.ca>
Fri, 17 Aug 2012 20:07:19 +0000 (16:07 -0400)
committerDan Scott <dscott@laurentian.ca>
Fri, 17 Aug 2012 20:07:19 +0000 (16:07 -0400)
commit7baa68e9811c08055a9874345395c1674e3587ab
tree8f2b409a8e239985b8e6d1fcb1c39ac1599562f2
parent7f7f88959224ed7941017a37adc45a19a98290d6
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>
Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm