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.

Requests:

- 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.

Comments

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

See:

http://api.drupal.org/api/drupal/modules--field--field.api.php/function/...

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.

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.

+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.

+1 subscribing

+1 subscribe

+1 subscribe

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 ...

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.

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

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.

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.

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

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