I need the Field collection to have a separate set of permissions than the parent Node.

This would be useful in my case where I need users to be able to create more Field collection records to a node, but not have ability to edit them. (Because of the nature of this module, in that content is not editable directly on the parent but on another page, I feel this is necessary. Otherwise a user would be locked out of adding records as soon as they move to the next step required to "add" records, if they have 'create', but no 'edit' permissions set on the parent node.)

Also -- and this is more obvious -- when the parent node is read only to the user, but the Field collection for that node isn’t, I'd still like the ability for users to have the "add" link available on it, depending on rather permissions allow it.


- A separate permission set for Field collections than the parent node, with additional "create", "edit", "view", ("inherit") permissions.

- An override/bypass of parent permissions, when child Field collection is still create/edit-able.

- A further suggestion would be to assign Field collection roles by grouping them into sets, rather than by setting them all individually, to not clutter the Permission interface with m fields.


glennpratt’s picture

It seems like permissions for fields shouldn't be specific to this module, though some work may be required to integrate.



ambrielnet’s picture

I see your point, and this is a great ideal and project, however, I do beg to differ.

And I'll tell you why.

This doesn't work with Drupal core features out the box with variable permissions applied to nodes, and it does not behave like "fields". It is contradictory, as again, you CANNOT add a new field collection record to a node that has "no edit" permission yet has "create" ability.

The node will lock and you cannot even get into the field collection item to add anything, like you can with all other fields. Had this been a widget, then yes, there would be no need at all for field collection to have it's own permission set that could bypass the parent, and this would have nothing to do with the project.

But it isn't the case.

Nothing requested was field specific, it was type specific. Since Field Collection has no widget, and launches you clear out to another page that acts like a node, and not a field. Since you have to SAVE the parent first, before entering the field collection record, it only directly applies that the field collection, being a separate entity, absolutely should behave separately as such since a field collection is never created on the parent's CREATE state, and you can only EDIT the parent to add one.

The first and primary issue is that the problem starts on the parent NODE level and how it deals with it's field collection "child" getting information on "create" events as expected by the end user. It appears that it is not compatible -- the communication link here is broken. The other fields do not have this issue, thus we cannot treat Field-collection like it's merely only a field, since it by no means acts like one.

Oceanman’s picture

Are permissions possible for just a specific field in a collection. Suppose I have a collection of fields

  • name
  • address
  • phone
  • email

I would like to allow the user to set the permission on the phone and email field to a selection of different roles like anonymous visitor or authenticated visitor.

RobW’s picture

+1 to Ambrielangel's description of the problem. This seems like another instance where a widget that copies the workflow of D6's multigroup (allowing field collection field editing on the node create/edit page) would be useful, although I understand there are currently problems with creating this.

chalee’s picture

+1 subscribing

jdufaur’s picture

+1 subscribe

jdufaur’s picture

+1 subscribe

vasike’s picture

maybe author (uid) for the field collection could the first step for this helpful feature.
imho i think every entity have an author, as the field collection it's an entity ...

Chris Pergantis’s picture

We really need the ability to allow an add on a field collection but must restrict edits and deletes.

@vaskie - we also need the author to be garnered - we had planned to use a computed field for that purpose but have not tested it yet.

khanz’s picture

I too have a use case, where i need users to create and edit field collection but are restricted to delete them.

Chris Pergantis’s picture

We went into the display fields of the node and established css classes that we used in a wrapping horizontal tab item tag. I am sure it could also be done with a div as well. In our situation we had a number of field collections in the node. This made it necessary for use sake to isolate the field collections with horizontal tabs. The edit and delete are now hidden - simple solution. The class we added was "ad-notes-restrict-edit-delete". The css entry was along the lines of ...

.ad-notes-restrict-edit-delete ul.field-collection-view-links {
display: none;

I hope that this helps!

Of course this is not permission based but it did get us past the client needs.

khanz’s picture

Version: 7.x-1.0-beta1 » 7.x-1.0-beta3

@ #11 it will certainly hide the link but it wont prevent someone aware of the "delete path" to delete a field collection item.

Chris Pergantis’s picture

I agree with the path still being available - thank goodness for non-techy users!

dtrees’s picture

Has anyone come up with a solution to this problem? I don't think hiding the edit and delete will work in my case.

dkisly’s picture

Issue summary: View changes

In case anyone is still struggling with this, here's one approach. It doesn't address all the scenarios described above and no guarantees on this - i've only tested in two sites (one v. vanilla), both with the field collection widget set to "hidden".

In the following, i needed to give certain roles ("editor") access that allows them to add, update and delete field collections attached to basic pages. However, that same role has no edit privileges on the parent node, so in the permissions grid, i left the applicable permissions un-checked (e.g. "Basic page: Edit any content").

The basic idea in the code below is to set a custom permission (the clumsily named "edit field collection not parent node") that is used in hook_node_access() to provide access to the field collection. On its own, it also provides access to edit the parent node. But, hook_menu_alter() + a custom callback effectively resets that permission to NODE_ACCESS_DENY (i.e., at "node/[x]/edit").

 * Implements hook_permission().
function MYMODULE_permission() {
  return array(
    'edit field collection not parent node' => array(
      'title' => t('edit the field collection but not the parent node'),
      'description' => t('Provides admin access to field collections items but not the parent content type'),

 * Implements hook_node_access()
function MYMODULE_node_access($node, $op, $account) {
  if ($node->type != 'page') {
  if(user_access('edit field collection not parent node') 
    && !user_access('administer content') 
    && $node->type == 'page' 
    & $op == 'update') {

 * Implements hook_menu_alter()
function MYMODULE_menu_alter(&$items) {
  $items['node/%node/edit']['access callback'] = '_MYMODULE_hide_edit_tab';
  $items['node/%node/edit']['access arguments'] = array(1);

 * Custom access callback to suppress edit options on basic page content type. Tweak node->type and other conditions as required.
function _MYMODULE_hide_edit_tab($node) {
  global $user;
  if(user_access('edit field collection not parent node') && !user_access('administer content') && $node->type == 'page') {
    return FALSE;
  return TRUE;
manarak’s picture

the edit permission needs to be fleshed out more.

in a field collection, edit can mean add, delete, modify.

I am facing a case now where any any authenticated user should be able to create and add items to the field, but only the node author should be able to delete and modify.

Jigar.addweb’s picture

Issue tags: +Field collection, +bypass
Shaylen’s picture

Any update ?