Alexey Parshin wrote:
> Well, in what I suggested, this situation is possible:
> 1) Student creates a class. This means he becomes an admin and a teacher.
> His right to teach is propagated on the whole course.
Looks a bit artificial. I don't like such things. If someone wants to be
a student only and happens to be an admin this situation must not force
him to take on teaching functions even formally. The reason like "this
app just works this way" doesn't sound for the end user.
> 2) He registers himself as a student.
> 3) He allows other student to register, or they just register for the new
> 4) He finds a real teacher and registers him as a teacher and an
> admin. The
> new teacher gets the teach right for the course.
> 5) If necessary, real teacher can exclude the original group creator from
> teachers and admins. At least, any admin can do it.
> 2007/5/22, Anatoly Volynets <firstname.lastname@example.org>:
>> Sounds reasonable. I think a student can be an admin too, but am not
>> sure. Situation: some guy wants to study a class, wants it with a
>> teacher, but there is no teacher as for now. The guy finds one and asks
>> to take over. The teacher says: gather people and I will teach you (the
>> reasons can be different, money, for example).
>> Alexey Parshin wrote:
>> > Here is a fresh view of the class requirements. Please, correct me if
>> > wrong.
>> > 1) Class may include few groups. The following groups come into my
>> > overheated mind (defines the permission type):
>> > - Students (STUDY)
>> > - Group Administrators (GROUP ADMINISTRATION)
>> > - Class Teachers (TEACH)
>> > It is possible that teachers may be administrators, too.
>> > 2) When class is created, Group Administrators and Class Teachers
>> > the class creator.
>> > 3) TEACH permission is propagated through the whole tree of UMOs in
>> > course.
>> Anatoly Volynets, Co-Founder
Anatoly Volynets, Co-Founder
Authoright © Total Knowledge: 2001-2008