David Wheeler wrote:
> The first option is to have four user groups automatically created for
> every new site created. The four groups would be named for the four
> different permission levels. For example, a site called "Big Scoop"
> would automatically have the four groups "Big Scoop Readers," "Big
> Scoop Editors," "Big Scoop Creators," and "Big Scoop Denied" (though
> localized). The advantage to this approach is that users can then
> easily be added to the appropriate groups in the current User profile
> -- it keeps things fairly consistent on that front. The disadvantage is
> a sort of group pollution -- more than may be necessary may be created.
> However, I could put a widget into the Site profile so that site admins
> could select which of the four groups would be created. The groups
> would be "secret" groups, meaning that they couldn't be edited via the
> Group profile interface.
This comes pretty close to describing what Sara does
manually when she adds a new site. To explain a bit, the
organization that we work for consists of a large number of
autonomous departments and other entities. Each of them of
course wants to have control of their own site, so we train
them and give them a workflow. In order to maintain their
permissions we also create a group.
We don't create the various groups as you have listed them
above however, we just create the one. We were hoping to
be able to leverage Bricolage's ability to manage workflow,
but for some reason each entity is only willing to have one
person function as what they call a "web focal point".
In the future however I think that we *will* be using
workflow, and so I don't think that the multiple groups
would be such a bad thing.
> The second option is to automatically create a secret user
> group for every user in which the user is the only member.
> Then the user could be associated with sites in the user
> profile by the addition of a new "site association" widget
> that just listed the sites, along with a selection of the
> appropriate permission for that user.
> The advantage of this approach is that users could be
> associated with sites on a per-user basis. The
> disadvantage of this approach is that users could be
> associated with sites on a per-user basis. ;-) That is to
> say, this approach de-emphasizes the advantages of
> managing groups of users in favor of managing individual
> users.
> This is not really an optimal thing to do, although it
> does more closely reflect my original proposal for the
> multisite feature. A second problem is that it essentially
> makes it ungainly to allow the association of users with
> sites within the *site* profile.
hmmm. The second problem is the problem I think. I don't
see any disadvantage to the first, except that it involves
creating a group that one might not even use. I'm not sure
that it would even need to be secret.
Thinking about scale and performance, even with a few
thousand users the groups would be at the most a few
thousand, which is not enough to cause a performance
problem.
The most likely performance problems (once the db is tuned)
come either in the form of bottlenecks in the code
(thousands of queries where one should do), or from overly
large tables, in which the problem is if the db server can't
load the entire index into memory it will have to page
through it, and paging can be kindof slow.
A couple of thousand rows is *not* large. A couple of
hundred thousand is starting to get there. That for what
it's worth is the current situation with the jobs table, but
that I suppose should be saved for another discussion.
> Now that I think of it, there is a third option, as well. I could leave
> it more or less as-is -- no groups would automatically be created. The
> advantage to this approach is that everything remains consistent; the
> disadvantage is that managing sites and the users associated with sites
> is more work -- admins must create their own user groups to associate
> users with sites. And since permissions are already a bit confusing,
> this would likely make things too difficult.
I think Sara would want the first option. She's been asking
for something like it anyhow. Sara?
--
--
=================================================================
-- mark at geekhive dot net --
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general
> The first option is to have four user groups automatically created for
> every new site created. The four groups would be named for the four
> different permission levels. For example, a site called "Big Scoop"
> would automatically have the four groups "Big Scoop Readers," "Big
> Scoop Editors," "Big Scoop Creators," and "Big Scoop Denied" (though
> localized). The advantage to this approach is that users can then
> easily be added to the appropriate groups in the current User profile
> -- it keeps things fairly consistent on that front. The disadvantage is
> a sort of group pollution -- more than may be necessary may be created.
> However, I could put a widget into the Site profile so that site admins
> could select which of the four groups would be created. The groups
> would be "secret" groups, meaning that they couldn't be edited via the
> Group profile interface.
This comes pretty close to describing what Sara does
manually when she adds a new site. To explain a bit, the
organization that we work for consists of a large number of
autonomous departments and other entities. Each of them of
course wants to have control of their own site, so we train
them and give them a workflow. In order to maintain their
permissions we also create a group.
We don't create the various groups as you have listed them
above however, we just create the one. We were hoping to
be able to leverage Bricolage's ability to manage workflow,
but for some reason each entity is only willing to have one
person function as what they call a "web focal point".
In the future however I think that we *will* be using
workflow, and so I don't think that the multiple groups
would be such a bad thing.
> The second option is to automatically create a secret user
> group for every user in which the user is the only member.
> Then the user could be associated with sites in the user
> profile by the addition of a new "site association" widget
> that just listed the sites, along with a selection of the
> appropriate permission for that user.
> The advantage of this approach is that users could be
> associated with sites on a per-user basis. The
> disadvantage of this approach is that users could be
> associated with sites on a per-user basis. ;-) That is to
> say, this approach de-emphasizes the advantages of
> managing groups of users in favor of managing individual
> users.
> This is not really an optimal thing to do, although it
> does more closely reflect my original proposal for the
> multisite feature. A second problem is that it essentially
> makes it ungainly to allow the association of users with
> sites within the *site* profile.
hmmm. The second problem is the problem I think. I don't
see any disadvantage to the first, except that it involves
creating a group that one might not even use. I'm not sure
that it would even need to be secret.
Thinking about scale and performance, even with a few
thousand users the groups would be at the most a few
thousand, which is not enough to cause a performance
problem.
The most likely performance problems (once the db is tuned)
come either in the form of bottlenecks in the code
(thousands of queries where one should do), or from overly
large tables, in which the problem is if the db server can't
load the entire index into memory it will have to page
through it, and paging can be kindof slow.
A couple of thousand rows is *not* large. A couple of
hundred thousand is starting to get there. That for what
it's worth is the current situation with the jobs table, but
that I suppose should be saved for another discussion.
> Now that I think of it, there is a third option, as well. I could leave
> it more or less as-is -- no groups would automatically be created. The
> advantage to this approach is that everything remains consistent; the
> disadvantage is that managing sites and the users associated with sites
> is more work -- admins must create their own user groups to associate
> users with sites. And since permissions are already a bit confusing,
> this would likely make things too difficult.
I think Sara would want the first option. She's been asking
for something like it anyhow. Sara?
--
--
=================================================================
-- mark at geekhive dot net --
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general