field permissions do not work with field collection

Well, you probably haven't gotten the quick fix. You may want to post in http://groups.drupal.org/jobs and/or the http://drupal.org/paid-services forum and link to this issue if you still need one. This module's issue queue could be described as voluminous.

Knowledges33ker, were you able to find someone to sponsor the fix?

Can you provide more detail on how to reproduce this bug?

Karl, I'll provide a live example of a feature I'm trying to finish: http://temp.collectiboard.com/node/175 (look for "Price History")

My site is a pinboard for collectibles, and Price History provides collectors with a crowdsourced database of the price history of each collectible item so that they can estimate the current value and help them figure out how much they should be paying (similar to Zillow's "Zestimate" feature). Done via Field Collection & Field Permissions, it's supposed to let any registered member submit, edit & delete their own price information.

Steps to reproduce the bug (or more of an explanation of what exactly the problem is):

1) admin/reports/fields/permissions -> No matter what permissions I set to all fields related to Field Collection (this includes all fields that are "field_collection_item" under "Entity Type" & the one field that is "Field collection" under "Field Type"), only the author of the node can submit price information. The permission settings just don't work like they should.

2) admin/people/permissions -> If I check "Authenticated User" for "Administer field collections" under "Field Collection", then any registered member can submit, edit & delete all price history information. Not that I'm supposed to be checking this field to begin with, but I'm just letting you know that this is one of the redundant tests I performed just to see what happens.

If any maintainer wants to play around with my test site, email me at jay AT jayl DOT ee and I will gladly provide user 1 access (I already gave access to Bill Bostick, who's helping me solve another problem).

Related #1954124: Fields part of field collection are ownerless

What is the progress on this? Any chance field permission module will ever play with field collections?

Still not working

Can confirm that a user can edit the fields even when they don't have edit permissions for the node the field collection is part of.

I have the same issue...
i set a permission to a field that is contained in a field collection and it doesn't work!
can you please fix this??

It's not a bug in field collections, it's because the field permissions module assumes that whatever entity it is operating on will have an owner identified by its UID. Field collections do not have UID's or owners. Entity's are not guaranteed to have either, so it's really not a sound assumption.

Anyways, the real work on this problem is being done in #1954124: Fields part of field collection are ownerless. I almost want to close this one as a duplicate, but they are technically not the same issue.

Yeah just hit this snafu today.
field_collections does not work with field_permissions.
Fortunately, patches exist to fix it.

https://www.drupal.org/node/1954124#comment-10626332
+
https://www.drupal.org/node/1284016#comment-8433843

Hopefully the field_collections and field_permissions maintainers are on board with the patches.

This issue fixed in dev version of "field permissions" module. So, all what we need - to patch Field collection.
Patch attached and tested on live project.

Works for me and see no problem in the code and logic. If you have some concerns let's update the stats again.

This seems to be the right idea but it will have to handle nested field collections too.

patch #12 and current dev version of field_permissions solved it for me.

thank you.

This seems to be the right approach. Regarding #15, can you explain how it needs to handle nested field collections, maybe that could be a follow-up as it seems to be just something you could expand on this?

recursion will be part of the solution :-)

Thanks for the comments.

mariacha1 has decided to provide the support for this in field permission. The latest dev version of field permission includes this hook implementation and it should work without any further changes to field collection.

http://cgit.drupalcode.org/field_permissions/commit/?id=7823ec0

I made a followup to support nested field collections in the field permission issue queue.

I try all dev version field permission and field collection it doesn't work
i think in when fc use function entity_access must add $account
and in function field_collection_item_access it have to change field permission if not in form edit it will call op = update and type = node

return $entity_access && field_access($op, $field, $item->hostEntityType(), $item->hostEntity(), $account);

I have tried to get field collection and field permission working together but haven't had success with the latest dev versions of the modules.

My case:

The field collection field is embedded in my content type 'profile' and has the 'public' permissions. The field collection contains several fields and I try to grant access for fields A-F to user role 'premium'. User role 'standard' should be able to access fields A-C. Therefore, I assign fields A-C the 'public' permission and fields D-F the custom permission and grant access only for the 'premium' role. Other than expected, a 'premium' user doesn't see fields D-F, only A-C.

Can somebody help me here, please? I read throught the issues and thought that this bug was fixed. I also tried to apply the patch from #13 but it doesn't work either (maybe I applied the patch not correctly because it seems not be fit for the current dev version).

Any help is much apprechiated, thanks.

The two screencasts show my permissions settings. The 'Public' permission is used for the embedded field collection item and the custom permission is used for the 'premium' fields.
Maybe one aspect that I forgot to mention: My problem is that the premium fields don't appear on the node edit form, although the 'premium role' has permission to create own value.