2009/1/6 Ilya A. Volynets-Evenbakh
> <mailto:ilya@total-knowledge.com>>
>
> Alexey Parshin wrote:
> > We already have person_add_to_group() and person_remove_from_group()
> > functions operating with group id.
> > I can add the versions of these functions taking umo id and
> group type
> > instead.
> "In addition", not "instead", I guess, but anyways - please do :)
> I think they should be limited to "EDITOR" and "ADMIN" group types
> though - class-related
> groups (TEACHER, STUDENT, CLASS ADMIN, etc.) won't work here, as there
> may be
> more then one class for a single course.
>
> I wouldn't worry about having more than one group of some type. I'd
> simply throw an error if there are more than one group matching.
> Also, current implementation creates the following default groups for
> every new class:
>
> * STUDENTS
> * TEACHERS
> * ADMINS
>
What is "class" from database perspective right now?
>
> BTW, what do I use to get listing of classes for a given course?
>
> Currently, there is no function for this. The course is based on TLT,
> and that TLT has a list of classes connected to it. I can add as:
>
> function study_course_list_classes(study_course_id int) returns setof
> course_class;
Yes, we'll need that one. Also study_course_get_default_course, I think.
>
> We have to go back to archives, and figure out if we allow single
> class
> to study more then one subject...
>
> If the answer is "yes", then creation of class is free-for-all,
> but sign-up
> has to be controllable.
>
> I'd leave it to you.
I'll get back to you on that one :)