Home Projects Jobs Clientele Contact


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

Re: UU Courses and classes

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

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 

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Authoright © Total Knowledge: 2001-2008