Fields part of field collection are ownerless

@joostpluijmers thank you so much for this. I'm not entirely sure if this is the proper solution neither, but I do know it worked for me. Here's a patch with your proposed change.

These issues appear to be related:

#1838976: field permissions do not work with field collection
#1282714: Support for field_permissions module
#1986712: Field collection with Callendar don´t respect the permissions

I also tried the patch, but it doesn´t work

Unfortunately this patch doesn't work against the latest dev branch., although it looks like the right idea! :-)

Can you please confirm which specific version of the module you originally had this working for?

This patch still applies to field_collection HEAD. Are you applying the patch to the dev release or the repository? You'll need to apply it to the repository. Here's a tutorial-

http://drupal.org/node/1399218

Thanks a lot for the fix, it worked for me. It was giving me a "Trying to get property of non-object" error though, so I changed the code from this:
$this->uid = $this->hostEntity()->uid;
to this:
$this->uid = $this->hostEntityId();

I tested it and it works great. The only people who are able to edit the field are administrators and owners and it actually shows on the edit form.

Not a problem! I don't even know how to makes patches. I usually just look at the code and go change it myself in the files.

The logic in the patch is incorrect. $this->hostEntityId() will return the entity id of the host entity, not the user id. Revised patch attached.

quickly retyped the contents of patch #15 into my install and it fixed the issue for me!

I found this issue because I have a computed field in a field collection that needs to get the host entity to count the number of values of the field collection itself. Got it working great until I was testing as a lower privileged user! This patch made my computed field work as designed and properly respecting permissions.

Was having the same problem (unless fields set to public, would not show.) Patch #15 worked a treat.

When might this get rolled into a dev build?

There is no $item->uid property so setting this makes no sense. Field collections do not have a concept of ownership. Not sure, what's the best fix would be for field permissions? I'd be fine with adding a method to get the host entity owner or something but I'm not sure that helps at all.

@fago If it makes no sense, why does it work? Did you test it and confirm that it fixes the issue?

patch #15 worked for me. Thank you.

In the related issue #1284016: field_collection integration -- add hook for defining entity's owner I proposed the solution to add a hook to field permissions to allow a user id to be defined by a hook. This would avoid the issue of setting a non-property 'uid' on the field collection entity. Of course, this solution depends on the solution in comment #6 being accepted.

Patch attached.

[Note: this patch will only work if patch https://drupal.org/files/issues/field_permissions-add_userid_hook-128401... is also applied.]

It would probably work for field collection items inside a node, but what about nested field collections in a node? If this hook is going to exist then the implementation of it in field collections should call it recursively on the host entity.

Is a custom hook for this really necessary? I know Field Collections don't inherently have an owner, but when they are inside an entity with an owner, then they are owned by the same user. Wouldn't it be better to make this a property with an overridden __get() ? It wouldn't have to store its own $uid then. It can just return $host->uid .

I took a closer look at __get() and I don't think it is a practical solution for a Drupal entity because it will interfere with the way a lot of other code attempts to access fields that may not exist yet. A hook may be the best way afterall. The following problems still remain:

- It must handle nested field collections.

- It must handle the embedded field widget on a node creation form. Oddly field permissions will check for ownership on a node creation form if the field is set to "Private" but the problem can be avoided by using custom permissions, even if it's set up in a way that should act the same.

Here's a patch that gets field_permissions working in a simple installation. I tested it with a mostly standard install and only field_collections and field_permission (and admin_menu) enabled for contrib modules.

The &__get() implementation caused a whitescreen in some entity controller code because of how it was attempting to access the data. I overrode the controller and changed that line, but I don't know if (1) the change will have unintended consequences or (2) another module might try to access data the same way or (3) the &__get() code may also break some other kind of data access attempt.

Jmuzz's patch works form me (comment #26), patch - field_collection-uid-1954124-26.patch

Info on how I am using field collections: my field collection is on a profile2 profile. Also using field_permissions and the admin_menu modules.

@jmuzz, thank you for the patch. We have Field Collections on Entityforms and ECK entities, and we are using Field Permissions to control create/edit/view access.

Your patch solved the problems we were having for roles with restricted access. For example, one role has the ability to create and view their own Field Collection on an Entityform, but does not have edit authority. Before the patch, users with this role could create content, but displayed empty results on reviewing the submission. Now that we've added the patch, users can see their results too.

Hopefully can get more test feedback and have this committed relatively soon!

I did only read through the thread after spending some debugging time, however I can confirm the issue being somewhere between fc and field_permissions. In my case, user profiles do have an attached fc (allowing for unlimited), containing a date and a text field (both limited to 1 per fc). (Background: Some scheduling thingything.)

Setting field permissions to anything but "public" leads to:

• The profile owner him/herself only seeing values he/she added,
• The profile owner not even being able to edit existing fields (only the "remove" button is there, of course, as a part of the fc).
• Only root seeing and being able to modify field values.

Putting them back to "public" resolved this.

@fago "there is no concept of ownership" does not necessarily mean that there must not be one. Obviously many people see this as a desirable approach, as do I.

However it makes little sense for field collections to be an exceptional entity, either way:

• If the concept of ownership is limited to nodes, the scope is (unfortunately) in core, because I think entities should have owners in general, but the primary scope is then "entity" and the issue should first be solved there.
• Once/if entities DO have an ownership by default, so should fc.
• If "entity" as a scope is out of question (e.g.: whom does a user entity belong to, root? a.s.f.), then indeed field_permission should be in charge to determine its "owner", since it introduces this additional concept. That could be achieved by climbing bottom-up until a host is found that has a uid (or otherwise qualifies as an "owner"). In this case, the task should be moved there.

Without looking it up in detail, how is that handled in D8?

Edit: Added details to the suggested scopes, formatting.

I can explain how it works in D7. There is really no 'official' way to express a concept of ownership for entities in general. Field permissions just checks for a uid in the entity object, so for example a user would be 'owned' by themselves and a taxonomy term would have no concept of ownership.

@jmuzz This would mean to either wait for core, or to create a workaround like the suggested one (climb up the parents). But all this makes little sense without the maintainers making a statement on whether or not they acknowledge the basic problem to be one, which is a bit of a pity.

Let's just please make a point here, either way. It's been 2.5 years now. :|

Edit: Cross reference-foo, as you can see. I created #2551721: What if fields are not owned at all? hoping to push it forward a bit.

The solution in 23, in combination with the patch for Field Permissions, has been working well for me.

At this point I would be more in favor of mariacha1's solution than the patch I posted because it could potentially work for any entity that doesn't have a uid as well as the field collections inside them. It depends on field permissions maintainers committing the hook patch. #1284016: field_collection integration -- add hook for defining entity's owner was recently RTBC'ed so it could happen.

Folks in here, if you've been using that hook, go over there and add to the RTBC-call! :)

mariacha1's patch #23 no longer applies cleanly to 7.x-1.x-dev. Attached is an updated version for review.

Yeah just hit this snafu today.
Fortunately, the patches fix it.

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

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

I went ahead and added this patch to the field permissions module instead, so it should be available with the latest dev version there. Since I suspect this patch isn't going to go anywhere on the Field collection side, I'm going to close this issue as a duplicate.

Hello @mariacha1,

I've followed many threads more recently, :https://www.drupal.org/node/2551721, all to pointing back here. I think people are getting confused on how to deal with both modules.

To make this happen properly, let's verify the instructions.

(1) Download dev versions of field_collection and field_permissions
(2) Apply field_collection-ownerless_fields-1954124-38.patch
(3) Apply field_permissions-add_userid_hook-1284016-8.patch

---

Is this recipe acceptable, as of today, for Drupal 7?

If not , please help revise this instruction set.

Thanks for your help also, I appreciate the time and efforts.

Hi @gangaloo,

Sorry for the confusion. At this point, the only step that should be needed is the first one:

1) Download the dev version of field_permissions.

I've committed all the necessary patches there.

@mariacha1

THank you. ^_^

After a clean install, I can verify that everything works as designed, per your instructions that you clarified.

#42 worked for me.

thank you.

@mariacha1 Why do you suspect that? I said I was in favour of your solution.

@jmuzz Sorry for closing this early! I didn't realize you were a maintainer. I saw the chance to implement it straight in Field Permissions and went for that solution. I suppose I closed the issue since it seemed so FP-centric and I didn't want to confuse folks with two.

That being said, if you want to apply the patch, I'm down to update FP as well!

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 own content type 'profile' (not profile2) 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 only 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 create/edit/view fields D-F, only A-C.

The two screencasts show my permissions settings. The 'Public' permission is used for the embedded field collection item and fc fields A-C. The custom permission is used for the 'premium' fields D-F.

Can somebody help me here, please? I read throught the issues and also posted this on the related issue here.

Any help is much apprechiated, thanks.