Re: Students, admins, teachers, and classes

[Anatoly Volynets <av@total-knowledge.com>]

Alexey Parshin wrote:
> 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.
>

I think, that is right. Only published course can be taught.


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

-- 

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org