Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Super flexible class subscription implementation

So, until class_subscription_confirm is called, it will not become valid.
Now, class_subscription_confirm will be called only after payment.
What do you expect to happen in UI for non-payment classes?

Alexey Parshin wrote:
> 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 

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008