Alexey Parshin wrote:
> 2007/5/11, Ilya A. Volynets-Evenbakh <firstname.lastname@example.org
> <mailto:email@example.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
> 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
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
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
> > - 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
> > 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
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