Re: UU Courses and classes

["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 
teacher.
   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 
into
   that specific version for the duration of study)
- In some situations it may be desirable not to lock all students into 
specific
   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
http://www.total-knowledge.com