[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UU Courses and classes
Doesn't have to be. What do you think is easier/more efficient to implement?
Alexey Parshin wrote:
Now, the next question. I think we may have many regular groups for
any UMO, but only one admin group. Is it correct?
2007/5/15, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>>:
I think I finally understood what you asked :)
Every UMO _will_ have an admin group.
Alexey Parshin wrote:
> We are back to the same question. What is correct:
>
> 1) We have a single admin group for a TLT
>
> or
>
> 2) Every UMO may have admin group
>
> ?
>
> 2007/5/15, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>
> <mailto:ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>>>:
>
> Hmm.. There are two different things here. One is Group Admin -
> i.e. the
> person
> that can manage group itself, and another one is UMO admin -
it is
> permission
> to change certain UMO properties (i.e. grant permissions to
UMO to
> certain groups,
> or set auto-granting rules). Initially I thought the second
one, in
> regards to course
> would be equivalent to "Edit/Publish" permissions, but you
are right,
> this is stupid.
> Let's create a new permission for that, and make it
separate. In that
> case course
> admin and course editor do not have to be related.
>
> So, to summarize:
> at UMO creation time following groups are automatically created,
> and creator
> is made member of:
> - UMO admins
> - UMO editors
>
> At UMO linking time, if parent UMO author is also child UMO
admin,
> he is offered a possibility to auto-add all parent UMO
admins to child
> UMO admin group
> and all parent UMO editors to child UMO editors (these are two
> separate
> options).
>
> Alexey Parshin wrote:
> > I think we have to add 'ADMIN' permission type. I then can
add the
> > procs to manage admin to group relationships. It may be useful
> for any
> > group.
> >
> > 2007/5/15, Ilya A. Volynets-Evenbakh <
ilya@total-knowledge.com <mailto:ilya@total-knowledge.com>
> <mailto:ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>>
> > <mailto:ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>
> <mailto:ilya@total-knowledge.com
<mailto:ilya@total-knowledge.com>>>>:
> >
> > Alexey Parshin wrote:
> > > This 'COURSE ADMINS' group - is the only question. I
> understood that
> > > it should include all the authors of any UMO within TLT
> tree. Is
> > that
> > > true?
> > No. That is the slight change from requirements I meant.
> > - Course admin group is created when the course is
created.
> > - Course admin group contains the course creator initially
> > - Course creator can add other people to the course admin
> > group later, and then they'll be able to work on the
> course,
> > and become actual co-authors.
> > - Any of admins can remove other admins
> >
> > As a bit of extra functionality, when an object one owns
> (has admin
> > rights to)
> > is added to the course, the person adding it should be
able
> to say
> > "add
> > all course
> > admins to this object", so that when multiple people
work on
> a course,
> > they can
> > all work on each-other's objects.
> >
> >
> > Does it mean that we gonna have admin group on the level
of UMO, not
> > just TLT?
> >
> > I think we need Anatoly to look over this, and tell us if
> this makes
> > sense from
> > user perspective.
> >
> > --
> > Ilya A. Volynets-Evenbakh
> > Total Knowledge. CTO
> > http://www.total-knowledge.com
> >
> >
> >
> >
> > --
> > Alexey Parshin,
> > http://www.sptk.net
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com <http://www.total-knowledge.com>
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com
--
Alexey Parshin,
http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com