Re: UU Courses and classes

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

2007/5/14, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Alexey Parshin wrote:
> 2007/5/13, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com >>:
>
>     Alexey Parshin wrote:
>
>     As a somewhat related reminder - TLTs do not show up in any
>     UMO searches
>     for topics - in other words, it should be impossible to link to
>     TLT, as
>     if it were a subtopic.
>
>
> I beleive that's two different things. It's not too difficult to add a
> check in topic_to_topic_attach() proc, to avoid any possibility to use
> TLT as a subtopic.
Please do.

Done

>     At least that's the way I see it now, I may change my mind later :)
>     > During the course creation, ALL the authors of ALL the existing
>     > versions of this TLT are included into the ACL group 'COURSE ###
>     > ADMINS' with the new access right "COURSE MANAGEMENT".
>     Err.. There is always single author initially, so your statement
>     above
>     _may_ be changed like that:
>     "Adding an author to a course, automatically adds that user to 'COURSE
>     ### ADMINS' group.
>     However, if we go back to general UMO access, we'll see that there is
>     already a group that has
>     those rights: the group that has "EDIT" or "PUBLISH" or whatever we
>     called that access to
>     TLT - which automatically includes all relevant people (this slightly
>     changes original requirement
>     that all authors be allowed to set policies, since not all authors
>     will
>     necessarily have such access,
>     but if one thinks about this issue _after_ getting good night of sleep
>     rather then before, it is clearly
>     the right thing to do).

Need more discussion?
 

> I suspect that UMO ACL is different from course ACL in a way that
> course ACL describes rights over all the UMOs in the course. At least,
> I understood it this way.
It's not quite that. Different rights act differently in this respect.
All modification rights apply to course UMO only,
in other words, they act the same as for all other UMOs (i.e. if I
created a course and included your topic into
it, it doesn't mean I'm suddenly co-author of your topic and can edit
it). Studying rights are different.
Although, if we stick to the concept of granting "STUDY" right on
per-UMO basis, even that shouldn't be
different. What I mean, is that, of course, signing up for a course
gives one STUDY right over all objects in
the course automatically (what do we do with intersecting objects? i.e.
the ones we already studied through
different course?) Anyways, if we keep linking "STUDY" right to an UMO,
course sign-up procedure can
simply go and recursively grant STUDY right on all course UMOs.
>
>     > We would need to talk more about - what are the things people in
>     > COURSE ADMIN group may do.
>     Define class creation policy, in addition to all the things that
>     can be
>     done on normal topic.
>
>
> The simplest thing is just use TLT ACL, of course. Just consider my
> comments about course above. At this point, I need to know, if the
> course ACL is the same as TLT ACL.
>
>     >
>     > 3) When a course is created, the class creation mode is defined as
>     > (roughly) { Free; Minimum donation; Fixed payment; Periodic payment;
>     > Percentage payment }
>     I missed the moderation somehow in the original post... Also, on
>     your part,
>     I don't see the "credit giving" bits. I.E. whether author wants to
>     allow
>     to differentiate
>     between those who donated and those who didn't (or perhaps based
>     on amount).
>
>     > Item three requires a new entity, 'payment policy', as a separate
>     > table, listing  { Free; Minimum donation; Fixed payment; Periodic
>     > payment; Percentage payment } with their attributes,
>     > and another new entity, 'actual payment policy', referring 'payment
>     > policy' and providing a value for the payment (fixed or %).
>     >
>     > Actual payments should be computed instantly (for fixed payments) or
>     > periodically by running a stored proc twice a month.
>     Let's complicate that a bit. Payment period should be definable by
>     author,
>     in one day increments.
>
>

Not ready yet to start on the following:

> How do you see this? Pay $10 every 3rd day?
Yeap.
> I just don't think that kind of granularity is needed.
If UU course is a supplemental material for a two-day seminar run by
different teachers,
it may well make sense.
> It is possible, of course, but would require more complicated proc to
> run every day - to compute the payments. After all, most of financial
> institutions use only fortnightly and monthly periodic payments, IMHO.
We aren't a financial institution :)
>
> I can start developing course now.
Yeay!
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

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