Re: UU Courses and classes

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

2007/6/6, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

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

If any class admin can add other user to the class - does it mean that payment is optional?
We have to think seriously on what admin can do with users if it involves money.
Some examples:
a) Admin includes a student into a class. The class enrollment price should/can be written off the student account, or it doesn't make sense. If the class enrollment price is zero, then it isn't an issue.
b) Admin removes a student from the class. The enroll or tuition money should/can be refunded to the student unless this is a disciplinary action.

This suggests that we may need 'user account' support. It may be implemented as some extension of person_list table plus charges_history and payment_history or something similar.
 It may make sense to allow a user select several things he wants to subscribe on (like a basket in online stores), then collect a single payment, and subscribe on the order things upon confirmation.

Students:
1. Anyone who passes class sign-up rules  becomes a student

The idea of application is only applicable for the case, when someone may review that application and accept or decline it. The reasons may differ.. Like the class is too full, or someone has bad reputation, etc.. 

> 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.

If you're going to call a subscription stored proc with the _confirmed_ payment amount - then I don't need details. I only think that we need to do it through several steps:
a) The subscription is tested and reserved in the stored proc. The place in class is assigned but marked as 'unconfirmed' or just expired. The id in group and payment amount are returned
b) The payment is processed (outside of my scope). If payment is unsuccessful the record created in a) is removed and the process interrupted.
c) The subscription confirmation proc is called with the amount. The student is confirmed and his place in class is marked as 'confirmed' or expiration date is set properly.

> 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 payment referrential integrity is really important. I'd prefer to keep all the payments in the same database, but limit the access to these data to db owner, special accountant role and special stored procs. Nobody but db owner and accountant would have select permissions on these data, and stored procs would be allow per-user access.

> 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? ;-)

If we use the three-stage subscription schema suggested above, then I (more or less) know what should be done and how.

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