Hi All,
I'm currently hard at work on the multi-site feature technical
specification. I've been trying to figure out how to simplify site
permissions to the extent that they're well-integrated with the current
permissions system, and I've hit upon a pretty decent solution.
However, there's one bit that has to work rather differently from the
current system, and I can see two different approaches to solving the
problem. I'd like to solicit opinions as to which folks would prefer.
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.
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.
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.
Anyway, I'm currently leaning toward the first option, but I wanted
some of you to think on how you might use the new multi-site feature,
and let me know, if possible, which approach makes the most sense to
you -- or if you can fathom another approach I haven't thought of!
For those who are wondering why I'm thinking about this at all: now
that Mark and I have done a great deal of work to speed up the whole
group and permission thing (still in progress, but will be finalized
for 1.6), I think it best to try to prevent duplication of effort (not
to mention expanding complexity) by keeping the permissions system
unified. This will also make it easier to redesign the permissions
system later on, should the need strike.
Thanks in advance for your feedback,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
-------------------------------------------------------
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
I'm currently hard at work on the multi-site feature technical
specification. I've been trying to figure out how to simplify site
permissions to the extent that they're well-integrated with the current
permissions system, and I've hit upon a pretty decent solution.
However, there's one bit that has to work rather differently from the
current system, and I can see two different approaches to solving the
problem. I'd like to solicit opinions as to which folks would prefer.
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.
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.
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.
Anyway, I'm currently leaning toward the first option, but I wanted
some of you to think on how you might use the new multi-site feature,
and let me know, if possible, which approach makes the most sense to
you -- or if you can fathom another approach I haven't thought of!
For those who are wondering why I'm thinking about this at all: now
that Mark and I have done a great deal of work to speed up the whole
group and permission thing (still in progress, but will be finalized
for 1.6), I think it best to try to prevent duplication of effort (not
to mention expanding complexity) by keeping the permissions system
unified. This will also make it easier to redesign the permissions
system later on, should the need strike.
Thanks in advance for your feedback,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
-------------------------------------------------------
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