Re: Questions

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

There is one thing I've just discovered. The already existing
procedures grant topic (or course) to a group (class), not to a
person. The question is - did we plan to deal with UMOs through groups
(classes) while including person into a class by the subscription?

2008/7/4 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
> Alexey Parshin wrote:
>>
>> Ok, I just refreshed my memory on the subject reading this archive.
>>
>> Here are the questions that are still not answered.
>>
>> It's more or less clear now that subscription order for a course
>> should create a set of ACL records upon order close. When the order is
>> closing - we grant every UMO in course to the person that owns the
>> order.
>> Now, this creates a couple of questions.
>>
>> 1) It seems to me that requires ACL records having start date and end
>> date. The current access_control_list table and related functions
>> don't support it.
>>
>
> Hmmm. True, we might want that. It should be optional though
> (storing NULL in end date field means ACL is indefinite).
> Study access length should be a setting in the course table.
>
>> 2) Creating ACL records to all the course' UMOs gives student STUDY
>> access. However, how do we check if all the course UMOs are passed?
>> Walking the UMO tree is expensive, and will create a problem if a UMO
>> was added to course since a student subscribed to it. Walking the
>> student's ACL grouping UMOs by TLT is also expensive :(
>>
>
> Well - that is exactly the reason we sign up to all objects in a course
> (and not only that - to specific versions thereof). Any changes to the
> course (non-minor edits at least) are not seen by a student after he
> signed up.
>
> We might want to add a procedure to update a signed up student to
> a new course version.
> However, it is optional, and will be a post-1.0 matter.
>
> And finally, to speed up walking UMO tree for checking, we can
> store course id in "study" ACLs, in addition to UMO id.
>
>



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