Re: UU Courses and classes

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

After reviewing the current implementation of the subscription and the current security schema for groups, I think we need some changes. I also think that my prior approach with implementing the class_subscription_rule as a table (with a fixed set of columns, of course) was a mistake.

Now, first thing first. Current security allows to define an access to any UMO for the group, along with the expiration date for the group membership. I believe we need to replace an expiration date with to dates: start date and end date. This allows to define a period when a person can study a UMO.

Second, the current class_subscription_rule lists several possible parameters of the subscription rule. Even that they are pretty popular, we should probably expect more. This means we should have an ability to create such parameters as we need them. The class_subscription_rule table should not declare a particular class subscription rule details, but rather the subscription method as a stored proc and a list of possible parameters (in a separate table, one row per parameter). Every class must provide values for these parameters obtained from the interface, one record per parameter (parameter name id, parameter value). A subscription procedure would read the class required parameters, and estimate payment value.

This (if implemented properly) allows to define any type of payment at all. If we need another payment method - we just need another stored proc and defined list of parameters..

2007/6/15, Anatoly Volynets <av@total-knowledge.com>:

We need to check all the rules against the idea of openness. At the open
server anyone can make a copy of a course and teach it. Thus, if we want
to arm the author with a control tool it can be only some kind of
approval, meaning that there can be not-approved teachers as well. This
may be only matter of ethics and corresponding marks on class titles
provided by UU/authors.

Ilya A. Volynets-Evenbakh wrote:
> Alexey Parshin wrote:
>
>> 2007/4/13, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
>> <mailto:ilya@total-knowledge.com >>:
>>
>>
>>     10. Following class creation rules are available:
>>         - Fully open, accept donations: anyone can create class, if
>>     donation of minimum is given to author, teacher has an option to
>>     show a stamp on his course. Not giving a donation will show up on
>>     course as well.
>>         - Fully open, don't care about money: anyone can create class,
>>     no donation absence marker will be shown.
>>         - Payment required, perpetual: Fixed payment is made, and
>>     class exists indefinitely
>>         - Payment required, periodic: Flat rate payments for defined
>>     period of time.
>>         - Payment required, percentage: Percentage of teacher's income
>>     from this class
>>
>>
>> 1) Currently, a course is created with the TLT. So, who is creating
>> the course? An author?
>>
> Yeap. Or rather, the user who created a course (it can be anyone)
> becomes an author.
>
>> 2) If the course is created - who has to pay for that course and when?
>>   I can think of the rules of including into the teachers group: we
>> need 'enroll as teacher screen'.
>>
> Mmm.. No, payment is set up when class is created. Now, you raise a
> valid question (or even two):
> There can be more then one teacher for the class, so
> 1. Who pays for its creation/continuous existence?
> 2. When students pay their sign-up fees, how do they get distributed
> between teachers?
> I have some ideas, but I'd like to hear others suggestions first.
>
>>   I can also think of the rules of including to students group: that's
>> enroll as 'student' screen.
>>
> Yes on this one.
>
>> 3) Who is actually registering students/teachers/admins?
>>   It may be a scenario that includes an application by the person,
>> that is confirmed by an admin (for teachers) or by a teacher (for
>> students).
>>   Or, it may be that anyone just enrolls if the payment is verified.
>>
> First course admins:
> 1. Original course creator is an initial admin
> 2. Any admin can add any other UU user as an admin
> 3. Any admin can remove any other admin
> 4. An "application" to become admin is done outside of the system.
>
> Now class admins and teachers:
> 1. Anyone who passes rules for class creation for given course can
> create a class and become class admin
> and teacher.
> 2. Any class admin can add other UU user as class admin
> 3. Any class admin can add other UU user as a teacher
> 4. Any class admin can remove any other class admin
> 5. Any class admin can remove any teacher
> 6. An application to become class admin or class teacher is done outside
> of the system
>
> Students:
> 1. Anyone who passes class sign-up rules  becomes a student
>
>
>> 4) How we are going to verify the payment? I suspect that payments
>> should be processed by some online system. Do we have such system in mind?
>>
> Yes. It's real-time credit card processing. Details outside of the list,
> if you really want them now.
>
>> 5) We need some structure to store the payment information. At the
>> very least, it should include references to {person, object of
>> payment}, date, amount, payment method, confirmation?
>>
> Yes. We might, however, store it in separate database, for security
> reasons. I'm open
> to suggestions on this one.
>
>> The actual methods of subscription (defined by Ilya above) can be
>> implemented as stored procs. I just need to understand - what is the
>> input information.
>>
> Of course they will be stored procedures. It's up to you to figure out
> what you need as input.
> (Put it other way - I don't understand your question, can you rephrase
> it? ;-)
>
>> --
>> Alexey Parshin,
>> http://www.sptk.net
>>
>
>

--

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org

-- 
Alexey Parshin,
http://www.sptk.net