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?
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 <firstname.lastname@example.org <mailto:email@example.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
Authoright © Total Knowledge: 2001-2008