Re: Students, admins, teachers, and classes

["Alexey Parshin" <alexeyp@gmail.com>]

I disagree in one position. The group admin flag gives a person privilege to maintain the group, and we have two groups. Also, this doesn't allow to create a pure admin - the person that doesn't have a right to teach, study, or anything else.

The current implementation (in SVN) uses the following approach:
Every group has a type and optional reference to the class. Group types are stored in group_type table. Every class may have several groups with different types. Usually, three groups are created with the class creation: 
- Students
- Teachers
- Admins

When one tries to change anything in any group that belong to any class, we check if he belongs to the group of type 'Admins' in that class (not implemented yet). 

The course connection. It is more or less clear that course is created with the TLT, simultaneously. Then the TLT is connected to other topics and, eventually, published. I guess that only published course/TLT can be assigned to the class (that is besides the payment issue). Please confirm/decline.

2007/6/2, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

OK. Here is a thought. Let's think little more about group_admin flag (I
still think that
it makes more sense, then defining group with rights to _group_), and
for the rest - class
record should just have teacher_group_id field and student_group_id
field. This gives
us fullest referential integrity, I think.

Alexey Parshin wrote:
> I'm trying to implement the class and its relations to UMOs.
>
> It looks like the idea to have three fixed groups (students, admins,
> teachers) is the only one that works in most situations.
>
> The idea to have flags (is_admin,is_teacher) seemed attractive but: we
> still need to have several groups. The reasons: marking a person
> within a group allows us to define, for instance, his admins rights to
> control the group. But it doesn't change or define any of his rights
> over UMOs within the course. We can only have it on the group level.
>
> This means, that we still need several groups for every class. Now,
> the number of these groups can be fixed (that simplifies the code) or
> variable (I still need to understand - what sense does it make).
> In case of three-group schema, the helper functions may use the group
> type (to-be-added to the group_list), STUDENTS/ADMINS/TEACHERS (from
> the to-be-created group_type table), to return person's right within
> the class:
>
> class_is_student(class_id,person_id)
> class_is_admin(class_id,person_id)
> class_is_teacher(class_id,person_id)
>
> These functions may be used to validate some user actions..
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

-- 
Alexey Parshin,
http://www.sptk.net