Home Projects Jobs Clientele Contact


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

Re: UU Courses and classes

After the latest discussion, here is my understanding of course:

1) A course is a separate entity that refers to TLT. It doesn't point to a specific version of TLT, but to TLT base.

2) A course is created AFTER the corresponding TLT is created. During the course creation, ALL the authors of ALL the existing versions of this TLT are included into the ACL group 'COURSE ### ADMINS' with the new access right "COURSE MANAGEMENT". We would need to talk more about - what are the things people in COURSE ADMIN group may do.

3) When a course is created, the class creation mode is defined as (roughly) { Free; Minimum donation; Fixed payment; Periodic payment; Percentage payment }

Item three requires a new entity, 'payment policy', as a separate table, listing  { Free; Minimum donation; Fixed payment; Periodic payment; Percentage payment } with their attributes,
and another new entity, 'actual payment policy', referring 'payment policy' and providing a value for the payment (fixed or %).

Actual payments should be computed instantly (for fixed payments) or periodically by running a stored proc twice a month.

2007/5/12, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Alexey Parshin wrote:
> 2007/5/11, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto: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.
OK. TBH, at this point I do not care all that much what is internally
defined as a "course", as long as our original arrangement and understanding
is preserved.
>     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.
Yes, but, like I said, I still do not know what functionally makes most
sense -
binding to a version or to an UMO base. Let's try to think a bit:
- List of people who can define access rules is defined by list of authors
    (is this right approach, or should we make a separate access group type
    instead, that will be pre-filled with authors automatically, but
which can
    be later modified? Anatoly?) Either way, this list applies to whole UMO,
    not to the specific version.
- In some situations it may be desirable that whole study group refers to
    same version of a course - i.e. if it's real-world class, led by a
    This means we may want at least an ability to force specific version
    whenever someone signs up to a course through a group.
    (N.B. as specified previously, signing up for a course locks student
    that specific version for the duration of study)
- In some situations it may be desirable not to lock all students into
    version, i.e. when it is "default" group.

I guess the final answer is that we want to bind classes to whole UMO,
but give group admins an ability to limit range of versions of a course
that students will link to.
>     >
>     > 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.
OK. I don't care all that much about implementation details of this at
this point.
>     > 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?
OK. I see what you mean. Part of the answer is already mentioned above.
Let's try to go into detail.
- Group that gets STUDY access to a course, automatically gets STUDY
access to all
UMOs that are part of this course.
- There should be a separate group, that has ADMIN access to a course
(I guess this is new
     access type). These are people (initially object authors), who have
an ability to set
    "course creation rules" on a course (hmm... we do not need, I think,
this rules functionality
    for any other UMO type, or do we? Maybe we do, just different sets
of rules)
    These rights apply to a course UMO only.
- "Class" groups have "group admins" - I don't think we want to create
separate groups for
    that - instead set a flag on membership. "Course Admin" group
members are automatically
    admins on their own group - i.e. any course admin can add/remove
other admins (this seems
    to make sense, but it isn't strictly speaking a requirement).

Hmm.. Did I miss anything else, in terms of functionality that makes sense?
Analyze this to bits - I'm sleepy now, so probably it has lots of holes :)

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008