CCK field permissions don't allow "create" or "submit"

'Edit' is basically the same as 'Submit'. 'Create' doesn't mean anything here, the node is either already created or it isn't, and if it is, it already has fields. We're just deciding if the user can edit them. You still have the usual ways of giving users permission to created or edit nodes.

'Delete' also makes no sense -- the fields cannot be deleted from the node, they can only be edited.

Please don't mind my ranting, but can't we set up a permissions setup like:

create_field_x = Allows users to set the fields when the node is being created
edit_field_x = Allows users to edit once node has been created
view_field_x = self-explanatory. Allows users to view the field.

My use case for this would be to trust the users to add fields to content but wanting to limit errors in the fields down the road if users decide they wanted to change them.

I am not a programmer, so I am unsure if this is even feasible, but if this can't be coded, how would an admin be able to limit access to fields in this way? Could it be done with theming? And is that the most secure way to handle this? To the best of my knowledge, wouldn't this require a custom node-x.tpl.php file to "hide" the fields after node creation?

Thanks

A use-case for this is that you might want to allow users to assign an initial value to a field, but not allow them to change it later.

For instance, I'm using a content profile setup, where a user's profile can be a node. I'd like to be able to easily have users enter a birthdate when they first create the node, but not change it later (we don't want people pretending to be 47 one day, then pretending to be 16, then 47 again when it suits them).

There are a lot of cases where it would be lovely to have users be able to set the initial value of a field when they create a piece of content, but not later.

By the way, a use-case for a delete permission should be obvious, especially in the case of fields that allow multiple values.

What if you want a user to be able to add new items, but not delete existing ones in a field with multiple values?

The delete permission would be kind of moot. The reason being is that with the edit permission in place, deleting a field would be 'emptying' it.

I hope KarenS can help shine some light on this again.

This is probably not going to happen, our code is in wide use working the way it does now. There is nothing to prevent anyone from creating their own alternative Content Permissions module that behaves in different ways, but it will most likely not make it into the core package.

I see this hasn't been posted on in a long time. CCK field permissions for 5.x separated out permissions for 'create' 'edit' and 'view'. the create and edit were especially useful because you could allow a user to initially fill in a field and then not edit it later. seems like this is an incredibly useful feature on a field by field basis (at least for me). frustrating only because it seems like a half step backwards that it was in D5 and not in D6. other than writing my own hooks, is there any update on this? any chance of it getting in the features queue?

I needed this as well, for the same reason: allow people to fill in the initial value at node creation, but no changes after the node has been created.

Can someone try this code, if it's working I'll make a module for it.

<?php
// $Id: content_permissions.module,v 1.5.2.6 2009/07/18 00:40:21 markuspetrux Exp $

/**
 *  Implementation of hook_perm().
 */
function content_permissions_perm() {
  $perms = array();
  foreach (content_fields() as $field) {
    $perms[] = 'create '. $field['field_name'];
    $perms[] = 'edit '. $field['field_name'];
    $perms[] = 'view '. $field['field_name'];
  }
  return $perms;
}

/**
 * Implementation of hook_field_access().
 *
 * @see content_access().
 */
function content_permissions_field_access($op, $field, $account, $node = NULL) {

  if ($op === 'edit' && isset($node) && !isset($node->nid)) {
    $op = 'create';
  }

  switch ($op) {
    case 'view':
    case 'create':
    case 'edit':
      return user_access($op .' '. $field['field_name'], $account);
  }
  return TRUE;
}

Attiks: This code works perfectly on my site. Thank you for taking the time to write this!

Since this esssentially replaces and vastly improves the module, I think this should be included in the next patch. If the maintainer does not wish to include it, it warrants its own module.

Any movement on this as a patch or free standing module?

I am in need of this functionality.

Thanks

That module snippet works just fine. It's a pity this won't be considered to be added to core? If that has changed, I am willing to submit a patch.

Creationg a d.o. module is a bit too much.

Attached is a module for the non-technical who just wants to add it and install it. It's pretty much a copy of the original content_permissions and #8