Add "View any %nodetype% content" and "View own %nodetype% content" permissions

the node access system exists in order that we can get a fast *listing* of nodes without consulting the permission system for each.

I've been hacking drupal myself with that purpose on some ocassion, it would be a dream have it on drupal6 :-)

Since creating node types and using new field types open so many possibilities (as some groups which search on CRM and BI solutions) its important empower drupal permissions assignment. So many different things may be created as nodes that relaying only on 'node access' permission is short for a serious use of the most thrilling drupal 5 (and hopefully now 6) features.

Having the possibility to decide which node types see what role independently of the rest is the basis for serious enterprise use of Drupal IMHO

For those who are watching this thread, there is a bug report that is related to this request: http://drupal.org/node/131950

The documentation in the node module states that a module can grant or deny access, but it actually checks "access content" before the module is called and won't give the module that opportunity if "access content" is granted. IMHO, any time the code does something different from the documentation, it's a bug. This patch puts the view check before the "access content" check, which is the proper order for the check.

This requested change goes much of the way to resolving that problem, but only for content types that are defined in Admin or by CCK. It doesn't help (yet) with module-defined content types.

In my modules, I use a permission for "access content-type," rather than "view..." but would be happy to change that if this becomes an official part of Drupal, which I believe it should.

For those who have yet to realize that this problem needs to fixed officially, let me point out that I have answered several questions in the forums dealing with the apparently increasing desire for sites whose access is "protect by default." That is everything should be denied unless specifically granted. Without fixing the bug AND allowing an extension like this proposed one, any access control module is going to have problems implementing "protect by default." With this type of change, those things that are to be universally allowed can be given a special content type for which "view" is granted, yet "access content" can be turned off for those roles who are not allowed to see it.

I like the idea...

The patch needs a lot more work though. You need to tie this permission system with the node listing queries too.

Now that the permissions for edit, create and delete are granular to each node type, we should think about getting this working for View. I understand there is already a node grant system available for this, but it's absolutely useless without an addition contributed module. The "Access content" permission is absolutely useless.

This patch shall be hated by everyone! MUAHAHAH!

• Removes "access content"
• Adds a "View %nodetype content" permission for each node type
• Adds a "View own %nodetype content"
• Replaces /node select query with the Drupal 7 database API to use the granular node type viewing

Why do we put role specific permissions inside of each block's configuration page and node specific permissions on the user permissions page?

I propose moving node type specific permissions off of the user permissions page and on to their respective node type configuration page. There is already a precedent of node type specific comment permissions appearing in this very location. We should pick one or the other.

I'm not sure about "access taxonomy" for the taxonomy/term/xxx page. That's really a content access page, not a term access page. The access check should be on each node that is selected.

I agree with #8, we need a complete by-content-type permission table incluiding views, edit, delete and edit own. We got it (for viewing purposes) on blocks, on views and on many contributed modules (as panels). It's application on nodes is a logical extension of it.

The create, edit and delete permissions were added to the access permissions page, so I don't see a reason to change where they're set at the moment. Besides, that seems like it should belong to a different issue. The point of this issue is to add the View permission alongside the new granular create/edit/delete permissions. We don't want to make a patch that does two different things and kills kittens. All we want to do here is add the View permission, please don't stray out of context.

Hi Rob. I fully agree with you in #11, but I also agree with the fact that the permission assignation could be reconsidered. Althought permission assignation has a central place, on that case, we could consider that many modules today provide lots of permissions (ubercart, storm,...). On some sites I maintain that list has become simply h-u-g-e. Moving the permission on node types from the usual permissions page to a more CCK location, IMHO is not a change, could be an evolution. Something that was good on old-drupal-4-days maybe it is not today.

All in all, I also vote for, at least, having on the permissions page the possibility to assign view permissions to every content type :-)

Agreed with #11, sorry: http://drupal.org/node/338958

Regardless, I completely agree with having full CRUD permissions for each node type. Seems almost like an overlook.

On some sites I maintain that list has become simply h-u-g-e

The list even on simple sites is large. Perhaps it's time to add collapsible fieldsets?

Of course this is a code need work. I understand the need for this feature, but we have to implement that properly.

First off, the node access system has not been completely ported to the new database API yet. See #299176: Replace db_rewrite_sql() with hook_query_alter(). for context.

Then, there is a design decision that need to be made here. At this time, the node access system works on a "OR" basis: you have the right to do an operation if *any* of the access control modules installed granted you that right.

Here, I suppose we want something that works on an "AND" basis: you will have access to a content if you have the "view %nodetype content" permission AND that an access control module (if any installed) granted you the permission.

That means the best place for this is probably directly into node_query_alter() (as implemented by #299176: Replace db_rewrite_sql() with hook_query_alter().), as a supplementary condition over the standard node access control.

NancyDru's proposal of collapsible fieldsets for the permissions grid looks to me another very good idea, although it's not related with the issue jlinares started.

Also Damien's proposal about changing from an "OR" basis to "AND" also makes sense to me.

Seems like a good idea - a lightweight role/content type based thing would be good - and one which just alters the node queries seperate from node_access() itself - Damien's approach to using hook_query_alter() and having an extra AND if one of those modules is installed makes sense to me as well.

Subscribing.

@#10: I agree with #8, we need a complete by-content-type permission table incluiding views, edit, delete and edit own

I'm slowly working on a contrib module to present those in a grid, content type by action.
This involves a fair bit of mucking about with regexps to grab them, and would rely on contrib modules that supply content types sticking to the same permissions format as core.

Marked #201100: CRUD Implementation of Node Permissions as a duplicate. Has some good discussion over there if you want to back-read.

Follow up to #19:
See http://drupal.org/node/429840 and http://drupal.org/project/node_permissions_grid

This would have been plain awesome to do. A simple, lightweight, user permissions-driven enhancement to the existing node_access() system makes probably sense for many sites out there. Bummer.

One thought that occurs to me: we should also add an overriding 'View all content types' permission; otherwise adding new content types will be a recurring permissions gotcha for site admins.

Is anyone aware of a contrib module that lets you create node types each with their own "view" permission? The usage stats would indicate the potential demand for the feature this issue is about, and I could do with such a module also!. Had a thorough look at http://drupal.org/node/206666 but couldn't find anything.

I'm not aware of one, but could easily add it to the Util module. The problem is that it would be separated from the other node permissions. Perhaps a better implementation of this request would be for a hook_node_perms() so that other modules could extend node permissions and yet have them in the same group. I've done this in a couple contribs (see Web Links) so that add-on modules could all be grouped together.

Just closed #282404: Add view [TYPE] content permission as a duplicate, since this one is older and has a (really old) patch (and apparently #218038: Separate view permissions for each node type was one, too). Still would love to see this happen!

The discussion in that issue pointed to http://drupal.org/sandbox/webchick/1074988 which has an example implementation that doesn't bring with it the baggage of the node_access system. Needs updating for EFQ, but could be a starting point.

Wow, Angie, it works well! I'd still like to have the permissions lumped in with all the other node perms.

(Merging "node system" and "node.module" components for 8.x; disregard.)

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Moshe was right in 2007, this can be implemented in contrib. Doing it in core would mean having to handle it in all listings, views etc. generically.