[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UU Courses and classes
Alexey Parshin wrote:
> 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.
Sounds reasonable.
>
> 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.
Sounds reasonable as well. Perhaps we should also consider possibility
of optional parameters with default values.
>
> 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
> <mailto: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>
> >> <mailto: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 <http://total-knowledge.com>
> culturedialogue.org <http://culturedialogue.org>
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com