Even more flexibility in content management
two more possibilities:
"view TYPE content" - roles that are allowed to view the content type's nodes "administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type
I think this is a good idea. +1 from me. The problem now is that "access content" includes every type of content, regardless. This prevents sites who want to make a certain content type premium, or just for registered users only, while the other types are still accessible. (e.g. recruiters can view resumes, but other users cannot). You need to check everywhere "access content" is used, and change that. Perhaps some contrib modules need to change as well. Don't hold your breath on this getting in for 5.0 though. Looks perfect for 6.0.
On Thursday 28 December 2006 3:23 pm, Zohar Stolar wrote:
I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.
Such a change should be done through core, so actually my questions are: Is there any work on this direction / open issue?
Lots of separate patches that make permissions more fine-grained in various areas, but no mega-patch that I know of.
Are there already any conclusions?
More-fine-grained-permission patches keep getting accepted, so my conclusion is that it's an accepted direction to be moving.
Should I start writing a patch :-) ?
Yes! :-) I've previously stated that there are 7 CRUD permissions: Create, View, View Own, Edit, Edit Own, Delete, Delete Own. With dynamic types from node module, it should be quite feasible to provide that full set to all node-module-based nodes for D6. (Completely custom nodes are largely on their own currently, and I'm not sure how to change that other than leading by example.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 12/28/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Thursday 28 December 2006 3:23 pm, Zohar Stolar wrote:
Lots of separate patches that make permissions more fine-grained in various areas, but no mega-patch that I know of.
Should I start writing a patch :-) ?
Yes! :-)
I've previously stated that there are 7 CRUD permissions: Create, View, View Own, Edit, Edit Own, Delete, Delete Own. With dynamic types from node module, it should be quite feasible to provide that full set to all node-module-based nodes for D6. (Completely custom nodes are largely on their own currently, and I'm not sure how to change that other than leading by example.)
Be sure to check: http://drupal.org/search/node/crud+type%3Aproject_issue If someone is gonna start a new parch or continue to work on another; please let me now. I'm willing to spend an awful lots hours testing, reviewing and bugfixing it. Thanks -- // Johan Forngren /** * Email: johan@forngren.com * www: http://johan.forngren.com/ * Skype: forngren * MSN: johan@forngren.com * IRC: forngren @ freenode * Jabber/GTalk: forngren@gmail.com */
Hi Zohar, If you need need permissions that are more fine-grained than the ones available on the 'administer access control' page, your best bet would be to explore the node access system. Modules can implement the node access system in various ways, e.g. restrict access according to nodes according to taxonomy classification (taxonomy_access), or according to user groups (og). I'm not sure if there's a node access module in contrib to restrict access according to node type, but if there isn't, it shouldn't be too hard to develop. This would probably be the best approach to implementing more fine-grained access according to node type. Cheers, Jaza. On 12/29/06, Zohar Stolar <z.stolar@gmail.com> wrote:
(might arrive twice... excuse me if it does)
I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type. The idea (which has certainly been raised before) is to add, next to:
"create TYPE content", - adding new nodes of that content type "edit own TYPE content", - editing the contents of own nodes of that content type "edit TYPE content", - editing the contents of all nodes of that content type (whether or not the user has right to create nodes)
two more possibilities:
"view TYPE content" - roles that are allowed to view the content type's nodes "administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type
I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.
Such a change should be done through core, so actually my questions are: Is there any work on this direction / open issue? Are there already any conclusions? Should I start writing a patch :-) ?
Cheers, Zohar
"view TYPE content" - roles that are allowed to view the content type's nodes
'view' is already one of the options fed into hook_access(), so in that sense this set of permissions already exists--it's just not implemented (yet) in the core node types. If you wish to implement it for a custom node type, you can define perms 'view whatevers' and/or 'view own whatevers' in hook_perm(). Then: /** * Implementation of hook_access(). */ function whatever_access($op, $node) { global $user; if (user_access('administer whatevers')) { return TRUE; } if ($op == 'view') { return (user_access('view whatevers') || (user_access('view own whatevers') && ($user->uid == $node->uid))); } ,,, }
"administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type
This could be done in a contrib module for 5.0. Something like: function adminnodetype_perm() { $perms = array(); foreach (array_keys(node_get_types('names')) as $type) { $perms[] = "administer $type content"; } return $perms; } function adminnodetype_form_alter($form_id, &$form) { if (isset($form['type']) && $form['type']['#value'] .'_node_form' == $form_id && user_access( 'administer '. $form['type']['#value'] .' content')) { foreach (array('author', 'options') as $key) { $form[$key]['#access'] = TRUE; } } }
Nedjo Rogers wrote:
"view TYPE content" - roles that are allowed to view the content type's nodes
'view' is already one of the options fed into hook_access(), so in that sense this set of permissions already exists--it's just not implemented (yet) in the core node types. If you wish to implement it for a custom node type, you can define perms 'view whatevers' and/or 'view own whatevers' in hook_perm().
Then:
/** * Implementation of hook_access(). */ function whatever_access($op, $node) { global $user;
if (user_access('administer whatevers')) { return TRUE; }
if ($op == 'view') { return (user_access('view whatevers') || (user_access('view own whatevers') && ($user->uid == $node->uid))); } ,,, }
Note that this method doesn't work very well because it does not prevent this content from being listed -- that requires either 1) using the node_access table, or 2) implementing hook_db_rewrite_sql to ensure that inaccessible types are not listed.
A great idea. As a user active in our support forums, I would also love to see "view own TYPE content". For some of the other there are roundabout ways to achieve, using taxonomy access control, but for "view own" there is none. Requested use cases for private workspaces do exist, and the current ways are rather convoluted (1-user OG groups, 1-user user categories, unpublished nodes... and the like) On 12/28/06, Zohar Stolar <z.stolar@gmail.com> wrote:
(might arrive twice... excuse me if it does)
I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type. The idea (which has certainly been raised before) is to add, next to:
"create TYPE content", - adding new nodes of that content type "edit own TYPE content", - editing *the contents* of own nodes of that content type "edit TYPE content", - editing *the contents* of all nodes of that content type (whether or not the user has right to create nodes)
two more possibilities:
"view TYPE content" - roles that are allowed to view the content type's nodes "administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type
I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.
Such a change should be done through core, so actually my questions are: Is there any work on this direction / open issue? Are there already any conclusions? Should I start writing a patch :-) ?
Cheers, Zohar
-- Zohar Stolar | זהר סטולר לינווייט תשתיות תוכן קהילתיות
On 12/29/06, Cog Rusty <cog.rusty@gmail.com> wrote:
A great idea. As a user active in our support forums, I would also love to see "view own TYPE content". For some of the other there are roundabout ways to achieve, using taxonomy access control, but for "view own" there is none. Requested use cases for private workspaces do exist, and the current ways are rather convoluted (1-user OG groups, 1-user user categories, unpublished nodes... and the like)
I would also like very much to have "view own" and "admin own" capabilities in Drupal core. I had to implement somethning similar (a permission named "access own") in a Drupal 4.7 site I operated starting from September (http://tau06.sns.it/). I modified node_db_rewrite_sql, and then had to fix some pager.inc functions. In the end the "access own" permission granted correctly all view/edit/list accesses. I have the impression that the functionality could be implemented in a better way with a modification on the node_access table. Greetings, -- Alberto
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? Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Zohar Stolar wrote:
(might arrive twice... excuse me if it does)
I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type. The idea (which has certainly been raised before) is to add, next to: | "create TYPE content", |- adding new nodes of that content type |"edit own TYPE content",| - editing _the contents_ of own nodes of that content type |"edit TYPE content", |- editing _the contents_ of all nodes of that content type (whether or not the user has right to create nodes)
two more possibilities: | "view TYPE content" |- roles that are allowed to view the content type's nodes |"administer TYPE content" |- roles that are allowed to modify the publishing options on all nodes of that content type
I encounter more and more situations where I want to delegate the publishing options permission to a specific role, but only to one content type, otherwise I have to give the person control over the whole site's content.
Such a change should be done through core, so actually my questions are: Is there any work on this direction / open issue? Are there already any conclusions? Should I start writing a patch :-) ?
Cheers, Zohar
-- Zohar Stolar | זהר סטולר לינווייט תשתיות תוכן קהילתיות
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?
Until someone comes up with a brilliant replacement UI, I think that's it. Are there any similar models from other systems that we could copy? I don't know of any good ones off the top of my head. Greg
On 12/28/06, Greg Knaddison - GVS <Greg@growingventuresolutions.com> 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?
Until someone comes up with a brilliant replacement UI, I think that's it.
Are there any similar models from other systems that we could copy? I don't know of any good ones off the top of my head.
There is also the issue of when you have more than 5 or so roles, and the list goes to the right beyond the screen. Some alternatives were proposed some time back. One of them (was it by Konstantin K?) was to use css to highlight the column titles (role names) on the line that has the cursor on it. Another was to have collapsible. It is a tough usability one to tackle, specially scaling well for many roles and many modules and many permissions per module.
Agreed that collapsible fieldsets and css-hovering might be helpful. If I remember correctly there is an issue to add the role name to the checkbox title as well, and jQuery could be added in various ways too. It should also be noted that in 5.x one can go to admin/user/roles and edit permissions on a per-role basis. Although now that I look at it the "edit permissions" link isn't shown for anonymous and authenticated roles, which seems to be a bug. Another implication is that it might be helpful to edit permissions on a per-module basis (i.e. across all roles). Maybe we could add links to this in the status message when enabling a module (or modules). .ck Khalid B wrote:
On 12/28/06, *Greg Knaddison - GVS* <Greg@growingventuresolutions.com <mailto:Greg@growingventuresolutions.com>> wrote:
On 12/28/06, Rob Barreca <rob@electronicinsight.com <mailto: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?
Until someone comes up with a brilliant replacement UI, I think that's it.
Are there any similar models from other systems that we could copy? I don't know of any good ones off the top of my head.
There is also the issue of when you have more than 5 or so roles, and the list goes to the right beyond the screen.
Some alternatives were proposed some time back.
One of them (was it by Konstantin K?) was to use css to highlight the column titles (role names) on the line that has the cursor on it.
Another was to have collapsible.
It is a tough usability one to tackle, specially scaling well for many roles and many modules and many permissions per module.
It should also be noted that in 5.x one can go to admin/user/roles and edit permissions on a per-role basis.
thats in 4.7 (and earlier) too.
Another implication is that it might be helpful to edit permissions on a per-module basis (i.e. across all roles). Maybe we could add links to this in the status message when enabling a module (or modules).
you kind of have these links on admin/by-module
On Dec 28, 2006, at 5:42 PM, Chris Kennedy wrote:
It should also be noted that in 5.x one can go to admin/user/roles and edit permissions on a per-role basis. Although now that I look at it the "edit permissions" link isn't shown for anonymous and authenticated roles, which seems to be a bug.
ahh, that's where it went. ;) indeed, it's a bug that it's missing for anon + auth roles. :( i still like the 4.7.x version: the role names at the top of the "big grid" (4.7.x: admin/access, 5.x: admin/user/access) are also these links that bring you to the per-role edit view. i don't see what'd be so bad about restoring those, in addition to fixing the admin/user/roles page to add the edit perms links for anon and auth. cheers, -derek
On Dec 28, 2006, at 5:54 PM, Derek Wright wrote:
indeed, it's a bug that it's missing for anon + auth roles. :(
http://drupal.org/node/105698 cheers, -derek
On Dec 28, 2006, at 5:54 PM, Derek Wright wrote:
i don't see what'd be so bad about restoring those, in addition to fixing the admin/user/roles page to add the edit perms links for anon and auth.
On Dec 28, 2006, at 5:33 PM, Khalid B wrote:
There is also the issue of when you have more than 5 or so roles, and the list goes to the right beyond the screen.
it's a shame we lost the ability between 4.7.x and 5.x to click on a role name and get a page with *just* the column for that role. : ( that's a handy feature, and totally simplifies the problem of not being sure which role you're assigning perms to when you have a bunch of roles. i think we're going to miss it in 5.x sites. seems like a small step backwards in usability, not sure when/why this was removed... maybe it was seen as too much of a weird, advanced UI trick, and people didn't even realize it was there or something. *shrug* -derek
Some alternatives were proposed some time back.
One of them (was it by Konstantin K?) was to use css to highlight the column titles (role names) on the line that has the cursor on it.
Another was to have collapsible. You're right about lots of roles pushing it out. I think highlighting would be a nice/simple improvement for D6. Thanks.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Khalid B wrote:
On 12/28/06, *Greg Knaddison - GVS* <Greg@growingventuresolutions.com <mailto:Greg@growingventuresolutions.com>> wrote:
On 12/28/06, Rob Barreca <rob@electronicinsight.com <mailto: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?
Until someone comes up with a brilliant replacement UI, I think that's it.
Are there any similar models from other systems that we could copy? I don't know of any good ones off the top of my head.
There is also the issue of when you have more than 5 or so roles, and the list goes to the right beyond the screen.
Some alternatives were proposed some time back.
One of them (was it by Konstantin K?) was to use css to highlight the column titles (role names) on the line that has the cursor on it.
Another was to have collapsible.
It is a tough usability one to tackle, specially scaling well for many roles and many modules and many permissions per module.
Khalid B wrote:
On 12/28/06, *Greg Knaddison - GVS* <Greg@growingventuresolutions.com <mailto:Greg@growingventuresolutions.com>> wrote:
On 12/28/06, Rob Barreca <rob@electronicinsight.com <mailto: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?
This could be addressed by collapsible fieldsets (per content type), or by some mechanism that allows admins to assign perms for one CCK content type at a time
Until someone comes up with a brilliant replacement UI, I think that's it.
Are there any similar models from other systems that we could copy? I don't know of any good ones off the top of my head.
There is also the issue of when you have more than 5 or so roles, and the list goes to the right beyond the screen.
Some alternatives were proposed some time back.
One of them (was it by Konstantin K?) was to use css to highlight the column titles (role names) on the line that has the cursor on it.
Another was to have collapsible.
It is a tough usability one to tackle, specially scaling well for many roles and many modules and many permissions per module.
I suggest the following approaches -- 1. css, as suggested above 2. collapsible fieldsets 3. an "assign for these roles" picklist -- this could be a multi-select list, but it would allow an admin to focus on one (or two, or three) specific role(s). As others in this thread have suggested, losing the ability to filter down to an individual role feels like we have lost some usability. Cheers, Bill
On Dec 28, 2006, at 6:33 PM, Khalid B wrote:
On 12/28/06, Greg Knaddison - GVS <Greg@growingventuresolutions.com> wrote: Until someone comes up with a brilliant replacement UI, I think that's it.
It is a tough usability one to tackle, specially scaling well for many roles and many modules and many permissions per module.
Perhaps something more along the lines of the new admin area, where the permissions can be accessed in different ways. - by module, alpha (default) - by module, individually - by role - by task ^ content access controls ^ moderation access controls ^ administrative access controls What might be a nice contrib addition would be a simple by-user override for all permissions, so that single users can have unique permissions without having to create an entirely new global role for it. But that's a new topic.... Laura
Laura Scott wrote:
- by module, alpha (default) - by module, individually - by role - by task ^ content access controls ^ moderation access controls ^ administrative access controls
What might be a nice contrib addition would be a simple by-user override for all permissions, so that single users can have unique permissions without having to create an entirely new global role for it. But that's a new topic....
Drupal 5's upgraded node_access system can allow most of this stuff. node_access currently does not allow administrative access to nodes, however. This, perhaps, is something we can look at changing for 6.
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) Self, Group, Others (SGO) Host, Module, Content (HMC) Admin, Non-Admin (AN) Does this cover the access control groupings we need? I.E. Did I miss anything? * User with RCDA rights at Host controls all. * User with RCA rights at Host controls all but may not delete or disable. * User with RCDN rights at Host and RCDA rights at Module (each module is specified) would be able to read, change and delete all content, would not be able to admin (publish or promote) content unless that content was with the RCDA module list. This user also has the ability to modify the settings that control the Module. * ... So how do we apply this to the role we are creating? The view of the role form would need to change so that above groupings become a checkbox group and the form would have a module list box. The user creating the role would check the values wanted and then select the modules it applys to. The list of modules would include selection for <all> modules and would be the default. Earnie Boyd
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 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. Host, Module, Content (HMC) What do you mean with "host"? The site in general? Admin, Non-Admin (AN)
Does this cover the access control groupings we need? I.E. Did I miss anything?
* User with RCDA rights at Host controls all. * User with RCA rights at Host controls all but may not delete or disable. * User with RCDN rights at Host and RCDA rights at Module (each module is specified) would be able to read, change and delete all content, would not be able to admin (publish or promote) content unless that content was with the RCDA module list. This user also has the ability to modify the settings that control the Module. * ...
So how do we apply this to the role we are creating? The view of the role form would need to change so that above groupings become a checkbox group and the form would have a module list box. The user creating the role would check the values wanted and then select the modules it applys to. The list of modules would include selection for <all> modules and would be the default.
Earnie Boyd
-- // Johan Forngren /** * Email: johan@forngren.com * www: http://johan.forngren.com/ * Skype: forngren * MSN: johan@forngren.com * IRC: forngren @ freenode * Jabber/GTalk: forngren@gmail.com */
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
On Friday 29 December 2006 11:59 am, Earnie Boyd wrote:
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?
Er, you are aware that permissions are already ORed for any Role a user has, right? If Role A has permissions 1 and 2, and Role B has permissions 3, and 5, then a user that has both Role A and Role B checked will have permissions 1, 2, 3, and 5. That's been the case for as long as I've been around at least. I also don't know what you mean by Group. Vanilla Drupal has no concept of a Group; there's Role, but that's not Group. The only Group I know of is Organic Groups, which is another animal entirely. Let's keep our terminology straight. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 28 Dec 2006, at 22:23, Zohar Stolar wrote:
I was looking through Drupal.org to find if there is work towards granulating the permissions table a bit more, by adding a way to limit administer/access to nodes by type. The idea (which has certainly been raised before) is to add, next to:
"create TYPE content", - adding new nodes of that content type "edit own TYPE content", - editing the contents of own nodes of that content type "edit TYPE content", - editing the contents of all nodes of that content type (whether or not the user has right to create nodes)
two more possibilities:
"view TYPE content" - roles that are allowed to view the content type's nodes "administer TYPE content" - roles that are allowed to modify the publishing options on all nodes of that content type
It's strange that so many people shout 'yes'. I think this is the wrong approach to the problem. We need to differentiate between: (i) access to functionality (ii) access to content/nodes (i) can be managed using regular permissions, but (ii) can't be managed using permissions. For (ii), we need node-level permissions. Why? Because we need to fix (ii) at the SQL layer so that inaccessible content disappears from pages, blocks, pagers, etc. In fact, we should move 'edit TYPE content' and 'edit own TYPE content' from (i) to (ii). For many people these permissions don't make sense. They want to say something like 'edit content in category Traveling' and/or 'edit own content in category Traveling'. -- Dries Buytaert :: http://www.buytaert.net/
participants (18)
-
Alberto Lusiani -
Bill Fitzgerald -
Chris Kennedy -
Cog Rusty -
Derek Wright -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Greg Knaddison - GVS -
Jeremy Epstein -
Johan Forngren -
Khalid B -
Larry Garfield -
Laura Scott -
Moshe Weitzman -
Nedjo Rogers -
Rob Barreca -
Zohar Stolar