field_attach_update() causes OG memberships to be deleted upon user signup

I can confirm that the same thing happened to me. I couldn't figure out why OG wasn't saving the group audience field. Thanks for tracking this down.

Have you reported this in the filefield paths issue queue? If not, maybe we need to move it?

Moving to FFP issue queue. @Deciphered - feel free to move back to og issue queue if this issue doesn't apply to FFP.

This problem happens when an entity is created or updated.

On line 260 in the FileFieldPaths module it calls

// Save any changes back to the database.
field_attach_update() inside of filefield_paths_entity_update.

Does line 260 actually need to be in a hook_entity_update(). I thought hook_entity_update() handles all the field updates?

Filefield_paths_entity_insert() just calls filefield_paths_entity_update(), which is why we see the problem when an entity is created.

The other question is why would calling field_attach_update() blow away OG's Entity Reference field data?

Thanks for any help you can provide.

@Deciphered - Any thoughts on this, or do you think we should move this back to the OG issue queue?

I do not have file field paths installed but I am having same issue.

Just an update, I am planning on looking into this issue, there was a similar issue with Commerce.

The reason it's doing what it's doing is so that any files referenced in any text fields will need to have the reference updated if the file path has changed, there may be a better way to do it, but I would like to determine where the issue actually lies before making that decision.

I'm running into a similar issue, which can also be traced down to this field_attach_update() call. We have code that fires while inserting users to add them to various organic groups. When this function is called for the *user* entity, the membership is deleted. I ran through the git logs to see what the rationale for this call is, but it lead to the initial 7.x-1.x commit :)

In our case, we aren't doing anything with users and filefield paths, so I just disabled the call for that entity type:

    if ($type != 'user') {
      field_attach_update($type, $entity);
    }

@deciphered, it's not clear to me what this is for based on #5. Do you mean if tokens are updated in text fields that would be used in the file path, or for entity reference fields that are referencing a file entity?

Subscribing.

So I'm updating the title of this issue, as I said in #5 there was also another issue related, there have been a few other reports of this issue as well.

The issue is due to File (Field) Paths using field_attach_update(), which subsequently triggers other effects by other modules. FFP uses this call to save any updated textfields that had references to the unprocessed path, but unfortunately this causes to many other issues and this does need to be fixed.

Marking this issue as Critical as it's really the big release blocker and needs to be dealt with ASAP.

Ok, looks like the issue was a lot easier than I though, turns out that stupidly field_attach_update() was running for any entity, regardless of whether said entity had File fields that used File (Field) Paths on it.

It solves at least one of the issues related to this issue that I was able to reproduce, I have not however attempted to reproduce the OG one as there's quite a bit involved to get that setup, but I would greatly appreciate it if someone could do so.

A fix has been committed and will be in the next Dev release which should be out in the next 12 hours.

As an aside, the Commerce issue was long since fixed and it wasn't specifically related to this in the end.

I will try to do some OG testing ASAP, assuming no one else is setup to do the testing on my behalf.

Looks like this issue is fixed. :)

The problem is that the $user entity isn't populated with the necessary OG entityreference fields for the groups the new users has signed up for when field_attach_update() is called. The OG membership is put in storage, but not reflected on the $user entity. So here is the question: is it bad practice to leave field values behind when put in storage (OG's issue), or is it bad practice to call field_attach_update() during the creation ($user->is_new == TRUE) of the entity when clearly this is an insert operation (File (Field) Paths issue)?

This problem still exists in this scenario: Using rules + invite + og: On the rule event 'invite_accept' (during hook_user_insert) the invitee is added to a group upon registering. ($user->is_new == TRUE). OG hasn't bothered reflecting this group membership on the $user entity, only in DB. This all happens in user_save()'s call to

user_module_invoke('insert', $edit, $account, $category);

The line after is

module_invoke_all('entity_insert', $account, 'user');

which is where filefield_paths hooks up. Digging down the field_attach_update() call we end up in OgBehaviorHandler::groupAudiencegetDiff() which compares $entity->og_user_node (empty) with $items (empty). So this would work just fine if they compared these values directly, but $entity->og_user_node is looked up in db (due to EntityAPI).

Again, OG doesn't update the entityreference fields on the $user entity during og_group() which causes field_attach_update() to delete the newly created membership. What camp does this issue belong to?

Here is a module that works around this by massaging the $account object during hook_user_insert() to satisfy OGs OgBehaviorHandler::groupAudiencegetDiff() during user creation.

I can confirm this is still happening with the latest dev release.

Scenario: I want to assign og membership on user update, based on some user profile fields values (using hook_user_update).
I see that field_attach_update() triggers another save for the entity, which holds its original values/memberships (before membership update).

I don't have an opinion about the problem being with OG or FFP. I've seen a similar issue posted on OG's queue (https://drupal.org/node/1502916) and my understanding is that other modules "playing nice" with entities is the expected behavior by OG. Anyway, I'd suggest maintainers of both modules discuss here and reach an agreement on what should be done to fix this issue.

For me it's the other way around.
Scenario as following: try to update fields in user account after deleting membership of the user.

First I tried hook_og_membership_delete() with user_save.

Result: the user was deleted from table og_membership and saved again with a new id. The reference in user account was not attached, so I had a reference to og_membership which wasn't existing and a new entry in og_membership.

Then I used hook_og_membership_delete() with field_attach_update().
Result: the user was not deleted from the table instaed there was directly a new entry and the old one too, so the mysql gets busted too because of unsolved relations.

Then I tried to use hook_user_update().
Result: No reaction.

After reading this thread I am convinced that there are issues with entity handling in og.

Meanwhile I updated from .5 to version .7 but the same result.

Hope anybody can analyze this information.

Sorry for me English knowledges.

maen

OK, now I solved my issues with db_update and db_delete

Any news on this issue? My problem might be related: I have a content type with an image field. When I save a new node without an image attached, then edit the node and attach an image, I end up with an incorrect count value for this node and file in the file_usage table (count is 2 instead of 1). When I disable File (Field) Paths for this field, the count value is correct.

Hi All,

Thanks for the patience. I never actually managed to reproduce this issue, but the code that was allegedly responsible has been refactored due to a somewhat similar issue and as such I am extremely confident that this issue is resolved in the latest dev.

However, if anyone is able to reproduce it, please, please, please provide some steps for me to reproduce the issue so I can resolve it once and for all.–

We came across this issue when creating a hook_update() script to initialize values for a new field. We used field_attach_update() so the entire user objects did not need to be loaded/updated, only the new field.

After running the update, roles were removed.

Here's an example of how to reproduce the issue:

$entity = new stdClass();
$entity->bundle = 'user';
$entity->uid = 123;
$entity->field_myfield = array(LANGUAGE_NONE => array(0 => array('value' => 'foo')));
field_attach_update('user', $entity);

field_attach_update() traces into the OgMembershipCrud() method inside plugins/behaviors/OgBehaviorHandler.class.php.

This method does not consider that the entity does not have a field that matches the og field instance it updates. It deletes the membership with og_membership_delete_multiple() and then adds nothing back because there's no field data available.

The attached patch adds a check for the field name in the entity before it lets the code continue.

public function OgMembershipCrud($entity_type, $entity, $field, $instance, $langcode, &$items) {
    if (!isset($entity->{$field['field_name']})) {
      // Field was not prepared in the entity for update.
      return;
    }
    ...

After this patch, I was able to run the update code above without groups being removed from the user.

Given that the patch you've rolled is for OG and not for File (Field) Paths, I assume you are saying that the issue is with OG? If this is the case, please move this issue onto OG.

Yes, it is indeed an OG issue. Apologies for the noise!

I can confirm I have also experienced this issue using the Workflow module and OG, when trying to call the workflow_execute_transition() function. The workflow_execute_transition() function calls workflow_entity_field_save(), which in turn calls field_attach_update(). field_attach_update() then loses the OG group reference.

The patch in #20 fixes the issue in OG for me. Moving back to the OG queue so the patch gets incorporated in a release.