Home Projects Jobs Clientele Contact


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

Re: UU Courses and classes

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,
    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
    > - 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?

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
    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

Authoright © Total Knowledge: 2001-2008