Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UU: Access management

Alexey Parshin wrote:
> 2009/1/6 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <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 :)
> -- 
> Alexey Parshin,
> http://www.sptk.net

Authoright © Total Knowledge: 2001-2008