Re: UU: Access management

["Alexey Parshin" <alexeyp@gmail.com>]

2009/1/6 Ilya A. Volynets-Evenbakh <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

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;

 

> This would be just a combination of group_find_for_object() and
> person_{add_to,remove_from}_group().
>
> The umo_register_editor() will not be needed at all if we add
> functions described above.

Cool. I think it should be removed completely.

>
> Class (as well as UMO) creation isn't limited anyhow at the moment.
> Currently, anyone can create a class or a UMO. If you can describe
> such limitations - we can add 'em.

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.

-- 
Alexey Parshin,
http://www.sptk.net