Re: Students, admins, teachers, and classes

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