Re: UU Courses and classes

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

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

Alexey Parshin wrote:
> I need to understand several things.
>
> When we are talking about a class - it refers to a course. Since the
> definition of course has changed, we need to re-define it.
> 1) Is course a TLT?
Don't we have a separate table, that points to TLT?

Nope. Currently, TLT is just a boolean field in topic_list. I can create a view that acts as such table, though.

I do not think we will bind "class" groups to specific version, although
there might be implementation advantages to that.

In that case, we can use topic_list_base table record, pointing to a TLT.

>
> The 'author' entity is connected to UMO. When we are creating a class
> - we need to use author(s).
Answer to that is:
> 8. Authors define rules on who can create courses.
In other words, authors have rights to set those rules. What we need is
set of tables (or just
fields?) to define those rules.
> 2) What authors of what UMOs?
course.

We don't have 'course' UMO. I've removed three tables related to 'course' entity since you redefined the approach. We need to define the requirements for course, or use that TLT-view.

>
> The class has teachers and students.
> 3) How do you see the security implementation? Is it another ACL table?
No, not ACL table - I think we moved ACL's to point to groups, didn't we?
Now we just define group membership rules.

Our ACLs currently define the rights of group members on UMOs. What I'm asking is - we need the ACL to maintain the group itself. Since a group may be granted an access to multiple UMOs, an author(s) of particular UMO shouldn't maintain the group. However, if we always have just one UMO granted to a group - then authors of the TLT may maintain it.

I guess, to clarify that situation, we need a scenario - what happens when we create a group and connect it to an existing TLT. Does that group get access to all the topics within TLT? what about connected UMOs?

>
> I doubt that, but:
> 4) Is class a UMO?
You doubts are confirmed ;-)

>
> 2007/4/13, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com >>:
>
>     Guys,
>
>     Get ready for ultimate fun: spec change.
>     I talked about courses, authors, teachers, students,
>     payments, etc. with the boss today, and here are the results.
>
>     1. Student does not sign up to course. He signs up to class.
>     2. Any number of classes can be created for course.
>     3. Class admins define rules on who can sign up
>     4. Whoever created class is a teacher for that class.
>     5. Whoever created class is "class admin" by default
>     6. Class admins can add more teachers and more admins to it
>     7. Class admins can remove other class admins and teachers.
>     8. Authors define rules on who can create courses.
>     9. Each course has "default class" created for it, with author set
>         to class admin and teacher by default.
>     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
>     11. Following class sign-up rules are available:
>         - Fully open, free: anyone can sign up, donation options same
>     as above
>         - Fully open, payment required: anyone paying fixed sum can
>     sign up
>         - Limited group, free: teacher signs up students himself
>         - Limited group, payed: teacher signs up students himself,
>     students
>     must pay
>               (Normally this wouldn't make much sense: teacher can get
>     payment
>               through external means, but we can provide a way, just
>     to make
>     it easier)
>         - Moderated sign-up, free: anyone can put in a request to sign-up.
>     Teachers
>                decide who is accepted.
>         - Moderated, payment requires: Same as above, but in order to
>     put in
>     a request,
>                 Student has to pay fixed sum.
>     11. Concepts of open and closed server were revisited. In terms of
>     payment
>     they will be equivalent ( i.e. same author-teacher and teacher-student
>     relationship
>     possibilities). Difference will be that closed server will not
>     have any
>     sort of
>     cross-linking or copying possibilities. I.E. one can only create
>     courses
>     from their
>     own objects.
>
>     I think it sums things up. Now I need corresponding changes for db
>     schema and
>     for model diagrams.
>     Oh, and any comments/suggestions on the above :)
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

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