Super flexible class subscription implementation

["Alexey Parshin" <alexeyp@gmail.com>]

I've just finished basic testing of the new class subscription implementation.

Now, the subscription of a person for a class has two parameters: start_date and end_date, as discussed earlier.

The subscription rule implementation is totally changed. The process is now more complicated, but much more flexible.

The subscription rule is a record that defines title, description, and subscription method (a stored proc implementing subscription algorithm). The subscription rule record may optionally have subscription_parameter_template child records. Every parameter template record defines parameter name, parameter type (a reference to parameter_type table) and "required" field indicating if that parameter must be defined. Parameter type defines a type name and "input_type" that should contain interface-specific HTML/JS code needed to present and validate that type.

The subscription process goes through three stages:

1) The subscription is requested from the interface. The selected class is used to get subscription_rule method (subscription algorithm, stored proc name) and class subscription parameters (if any) form class_subscription_parameter. A subscription_order record is created with person id, and class id. The subscription parameters define amount, start_date and end_date. Order has 'opened' state.

2) The payment amount (or more), defined in subscription_order, should be paid through external system (outside of the database), and registered on user account with register_payment() stored procedure. This creates credit on user account in the database. The order_confirm() proc is called to celebrate this step switching order to confirmed state.

3) The class_subscription_confirm() is called to find the confirmed order, register payment from user account to class, and include user into the students group of class he is subscribing to. That automatically closes the order. 

The described scenario is used in subscription_rule_functions_test() (in file procs/subscription_rule.sql) to illustrate the whole process.

Here are some examples of the subscription rules (already implemented). 

1) The basic subscription rule 'Free subscription' contains no parameters and needs no record in subscription_parameter_template. The subscription algorithm is implemented as class_subscribe_free() function in file procs/06_subscription_rules.sql.
 2) The basic subscription rule 'Single payment subscription' contains one
parameter (Subscription Price) and needs one corresponding record in subscription_parameter_template. The
subscription algorithm is implemented as class_subscribe_single_payment()
function in file procs/06_subscription_rules.sql.
 
-- 
Alexey Parshin,
http://www.sptk.net