full CRUD support

Looks good to me. Here's a unified version of the identical patch if anybody cares.

Drupal core does not enable a module to properly define read/view permission. this is handled by node_access(). when displaying a node listiong, hook_access() is not called so node module can't influence here. see core modules for an example hook_access implementation.

I'd like to resurrect this patch and get it applied. I need this capability and the patch seems to work perfectly. I see that moshe said drupal core does define view permission, but the hook_access documentation includes 'view' as one of its examples and it does seem to prevent an anonymous user from getting to the node.

It will prevent a viewing of the node on an individual page, yes, but has no effect on listings. Node listings strictly rely on the node_access table for access restriction. It is therefore dangerous to check for view permissions this way, because users will be under the impression their content is access-controlled when it is still accessible by other means.

Does there then need to be a patch to the core that would allow for full CRUD support, because I think it's necessary for quite a few situations? If so, KarenS or Ber, is it possible for you to submit such a patch? Perhaps JonBob or Moshe can give a few pointers as to how to make that happen? Just seems like the next logical step, I just thought I might as well as just say it :)

The whole topic of access control is going to get off-topic for cck, but I wanted to post a bit of info here for anyone else who is looking for the ability to control access to cck content since they may end up reading this thread. I am still getting all this figured out myself, so anyone who knows better, please correct me if I'm wrong.

Basically, the module can control everything but 'view' access, so we can set up control for edit, edit own, delete, etc. within the cck module itself (and I think we certainly should).

Completely controlling 'view' access requires one of the access control modules -- simple access, organic groups, taxonomy access, node privacy by role, etc.

I was trying to figure out which of them would most closely match what I wanted to do here -- control access based on the content type and user role, and it looks like node privacy by role is the best match for that purpose. You can enable it, then go to admin/settings/content types and select the cck content type to set up default access permissions for that type. You can then override the permissions on a node by node basis.

A *very* brief overview of the other modules, just to help point people in the right direction for more research into this issue, since I think there is nothing that cck can do itself to control 'view' permissions:

Simple access -- a very simple module that allows you to control access on a node by node basis. The default is to make everything public, you have to edit each node that you want to make private.

Taxonomy access -- links user role and taxonomy terms to control access. You have to apply the right taxonomy terms to your node and then access will follow the permissions settings for that term. If you don't set anything up, the default is to make content public, so it's public until you change it.

Organic groups -- allows you to create groups, then each node has an option whether or not to make it public. The default is to private unless you set it otherwise. Again, to set up any access other than the default you have to edit each node.

Node privacy by role is the only access control module I found that seems to have a means to set a default view access by the content type. It uses the default you set for that type when you create new content, but any content that already exists when you first enable the module defaults to being viewable by the public until you change it. This seems to be the module that most closely emulates what I was trying to do in this patch. I am trying this module out and it looks like there is no problem using it with cck content types (and of course there is no reason why cck content types would behave any differently than any other type).

For this issue, I think we need to wait until Drupal 4.7 ships. At the moment discussions on the developer list are focused on squashing critical bugs, and that can't be disrupted. After that we can open a general discussion on whether node modules should have "update" and "delete" permissions per content type. The core node types don't do this now, and since CCK is being designed as a core candidate we want to emulate the core approach as much as possible. If the community decides this should be done, then I will make the change.

Until then, node privacy by role not only allows for controlling view access, as Karen mentioned, but also update/delete. It is a fine solution for urgent needs, and scales well for other access schemes.

RUD support, then? :-)

I am very willing to add the "update" and "delete" permissions if the community decides to add such permissions to core. The development philosophy is to prepare this module for core inclusion, so I'm hesitant to add any features that are not related to the task at hand (administratively-defined content types) unless those features are also being added to core.

I've been looking at this for Flexinode and I think it would be a good idea in CCK. View restrictions for lists can be done through the db_rewrite_sql hook but I'm not entirely sure how to do this as I can't get my head round the documentation. Sometimes I find the access modules a bit of overkill for what I need and simply having a permission for view on CCK would be great.

I'll let you know if I eventually get my head round this.

Got something that seems to work. Haven't got diff installed so I'll just post the three functions:

/**
 * Implementation of hook_perm().
 */
function content_perm() {
  $perms = array('administer content types');
  foreach (content_types() as $name => $type) {
    $perms[] = 'create '. $name .' content';
    $perms[] = 'edit own '. $name .' content';
    $perms[] = 'edit any '. $name .' content';
    $perms[] = 'delete '. $name .' content';
    $perms[] = 'view '. $name .' content';
  }
  return $perms;
}

/**
 * Implementation of hook_access().
 */
function content_access($op, $node) {
  global $user;
  $type = is_string($node) ? $node : (is_array($node) ? $node['type'] : $node->type);

  if ($op == 'create') {
    return user_access('create '. $type .' content');
  }

  if ($op == 'view') {
    return user_access('view '. $type .' content');
  }

  if ($op == 'update') {
    if (user_access('edit own '. $type .' content') && ($user->uid == $node->uid)) {
      return TRUE;
    }
    elseif (user_access('edit all '. $type .' content')) {
      return TRUE;
    }
  }

  if ($op == 'delete') {
    if (user_access('delete '. $type .' content')) {
      return user_access('delete '. $type .' content');
    }
  }
}

/**
 * Implementation of hook_db_rewrite_sql
 */
function content_db_rewrite_sql($query, $primary_table, $primary_field, $args) {
  global $user;
  switch ($primary_field) {
    case 'nid':
      if ($user->uid != 1) {
        $return = array();
        $where = array("n.type <> ''");
        foreach (content_types() as $name => $type) {
          if (!user_access('view '. $name .' content')) {
            $where[] = "n.type <> '$name'";
          }
        }                
        $return['where'] = join(' AND ', $where);
        return $return;
      }
      break;
  }
}

The first two are per the original patch.

The db_rewrite_sql hook allows the sql to be modified with extra clauses to prevent unviewable entries showing up in lists. This is needed as hook_access is not called during a list for performance and other reasons.

Let me know if any problems show up and if this is of any use to anyone.

Hi Bèr,

Just downloaded diff and here it is in patch form. I've tested this patch with simple_access and so far there are no conflicts, everything works as expected.

I've updated the patch so that a user isn't blocked from viewing their own content. Some issues need looking at such as the view permissions for the module override permissions given by other access modules.

I continue the discussion from http://drupal.org/node/62340#comment-109810 to http://drupal.org/node/62340#comment-111006

#49 submitted by Dries on June 27, 2006 - 07:36

How can we do Ber's CRUD in a way that does not conflict with node-level permissions?

By patching them too ;)

#50 submitted by Crell on June 27, 2006 - 08:07

As I've said before, I'd actually go a step farther and point out that RUD has two versions: Own node and any node. So a full breakdown would in fact have 7 permissions: Create, View Own, View, Edit Own, Edit, Delete Own, Delete.

As for how to not conflict with node-level permissions, I'm not sure I understand. The logical way to do a complete breakdown would be as permissions on nodes via hook_access(). Instead of the current de facto standard of "create foo", "administer foo", "view foo", we'd have 8 permissions per type: administer (all perms) and the 7 above. That's node-level permissions right there, per node type.

#55 submitted by Bèr Kessels on June 27, 2006 - 13:01
If we limit it to CUD2 we dont conflict with any node level permissions. But most of all, we will make the patch VERY simple.
The only part in that patch I pointed to that is hard to do, is the 'R' part. This is because of Drupals architecture, that does not really "respect" view permissions.

IMO CUD2 (Create, Update own, Update all, Delete own, Delete all) is already a huge step forward. We can bend over the R part in a later, different patch. Or even a contrib module.

Sounds like a great idea to me, but I think that we should implement this sooner or later.

#56 submitted by webchick on June 27, 2006 - 13:27

forngren: Could you explain how a "role" would differ from a "group"? From what I know of Unix (and Windows) permissions, I would call Drupal's roles "groups" in those contexts.

Here's an example scenario:

I'm the admin of a small site for a soccer team.
It has two groups called coaches and players.

• Coaches
• Can create pages without approval
• Can read all pages
• Can set page view permissions to prevent anonymous/auth. users and palyers to view them
• Can edit own pages
• Can edit other coaches and players pages
• Can delete own pages
• Can't delete other (coaches) pages
• Players
• Can create pages, but needs approval from an admin/editor
• Can view certain pages
• Can set view permissions
• Can only edit own pages
• Can only delete own pages

There are four kinds of roles:

• Anonymous user Can view some content
• Auth. user Can view some content and post comments
• Editor Can CRUD all pages, but can't acces system settings
• Admins Can do EVERYTHING

Not the best example, but I hope that you got the idea

#57 submitted by webchick on June 27, 2006 - 13:29

On the subject of C(R)UD2, I'm fine with doing this if we can do so in such a way that modules implementing more fine-grained permissions (at the node-level, or taxonomy-level (OG, taxonomy_access, node_privacy_byrole, etc.)) can override the system defaults. I assume that's already being thought of though. :)

#59 submitted by moshe weitzman on June 27, 2006 - 14:13

we can't do the R in CRUD without slowing down drupal for node listings. The 'view' operation of hook_access() is not checked for a reason. That would be very slow and difficult for the pager. Really, I think thats a separate issue and shouldn't cloud this patch.

How often is node listenings used? There must be a way to not slow down pages that much

Puh, I'm exhausted :p

//Johan F

Carefull:

This patch is NOT compatible with Views at the moment: it throws 'Unknown table 'n'' warnings for each view displayed, see here and screenshot attached.

kiteatlas is right. See http://drupal.org/node/82513 for a patch to the patch :-)

I added 'edit $name content' permission to match permissions used in 5.0 core. I didn't address the view permissions, and all permissions are handled in core starting in 5.0, so I don't know if this patch still is needed. You can re-open if there is still interest in doing something with view permissions.

I'm sorry to reopen this. But I'm a bit of a newbie. I know how to use patches and have muddled through all the comments on this and the views patch.

Where does all this stand? Sorry, but what's the best combination of patches to give "edit all" permissions for specific node types - while not breaking views. module?

Thanks for the help.

I still don't understand why a patch like this hasn't been committed to content.module as a permanent fix. I've read the arguments for using node access, but it just seems simpler to add the access privilege to content.module. Again, I'm a newbie - so there's probably sound logic for the decision that just goes over my head.

Cheers,
Sean

It has been committed, it's just called 'edit' instead of 'edit all' for compatibility with the ways things work now in 5.0. So you should have 'edit own' and 'edit' (which is the same as edit all).