Quoting Johan Forngren <johan@forngren.com>:
You added some good points to the discussion, however...
On 12/29/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
On 12/28/06, Rob Barreca <rob@electronicinsight.com> wrote:
A bit off-topic and not super critical, but this will also need to spur a discussion of a more manageable access control page if we have something like 5 perms for each content type. Is there an issue/any ideas on how to simplify the access control page? Or, is a super long matrix format still the best way to go?
Let's think it through a bit:
Read, Create, Delete (RCD)
Update/edit should be added here
Duh. So we'll change it to Create, Read, Update, Delete (CRUD)
Self, Group, Others (SGO)
Others could be both members/visitors. I think we should separate them. We should also separate group and roles or merge them completely, see http://drupal.org/node/53772#comment-111016.
Why would member vs visitor be different for Other? I don't see how it can be different. The visitor is just a non-authenticated member. The visitor is always assigned the non-authenticated role and can never be assigned another role. The authenticated member is alwasy assigned the authenticated role and the role, if any, assigned to his profile. Group though is new to Drupal core as far as access control is concerned and AFAIK. Roles could be assigned to a Group as well and then the member assigned a Group. The ORed bits of all the Roles would determine what the user permissions are. The Group control could be used to allow an authenticated member to create a sub-site and only members of the sub-site group could visit that content. Perhaps multiple additional roles should be allowed to be selected in the user profile so that the ORed bits give a user greater privilege with each additional role?
Host, Module, Content (HMC)
What do you mean with "host"? The site in general?
Yes site in general.
Admin, Non-Admin (AN)
Earnie