[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UU Courses and classes
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?
I do not think we will bind "class" groups to specific version, although
there might be implementation advantages to that.
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.
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.
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