I experience problems with removing an item from a list.

I originally posted this issue for the References module. See:

http://drupal.org/node/1318894

It appears that the problem also occurs with items in a Entity Reference list.

Adding an item works. Removal fails. Is this a bug in Rules?

Comments

fago’s picture

please try updating the entity api module to the latest dev version

Goofy2k’s picture

I updated the entity api to 7.x-1.0-beta10. The issue remains. Should this update affect user reference fields as well as entity reference fields?

Goofy2k’s picture

I found this article on adding /removing users from a reference list programmatically.

My knowledge of php is too poor to translate this in some code for a php-code rule.

fago’s picture

please try updating the entity api module to the latest *dev* version

Goofy2k’s picture

Mistake from my side Fago. I now moved to Entity API 7.x-1.x-dev. No improvement.

Of course I also looked at my Rules, but I think they are allright. Adding a user goes OK with almost the same code. I also save the node after updating the field. Have control messages firing OK.

fago’s picture

ah, maybe the entity is not saved by rules. Try reading the debug log, whether it says so. If not, try updating to the latest dev version or use the "save an entity" action.

Goofy2k’s picture

I explicitely save the entity (pool_node) but see no changes.

There are 2 actions list_remove as I use a user_reference and an entity list for testing

Does "evaluating" in the debug output actually mean that the action is executed?
Obviously YES, because I see the result of drupal_message appearing.

DEBUG OUTPUT

" Rule Remove pooler reference from pool node fires. [edit]
0 ms Rule Remove pooler reference from pool node fires.
0.808 ms Evaluating the action list_remove. [edit]
2.137 ms Evaluating the action list_remove. [edit]
2.538 ms Evaluating the action php_eval. [edit]
2.785 ms Evaluating the action entity_save. [edit]
5.423 ms Evaluating the action drupal_message. [edit]
5.594 ms Rule Remove pooler reference from pool node has fired.
19.613 ms Evaluating conditions of rule Generate game set for pooler. [edit]
19.631 ms AND evaluated to TRUE.

Goofy2k’s picture

I finally succeeded to add/remove users on a multi-valued user-reference field.

So all seems to work well !

The origin of the initial issue was in the fact that I tried to change the field after a webform submission on the data-containing node.
I solved the problem by entering explicit entity-fetch and save actions in the rule that was triggered by the webform submission.

Thanks for your support Fago

Ogredude’s picture

For some reason, adding an entity reference to a single-value field does not require an explicit entity save, but adding a value to a multi-value reference field does. This doesn't seem right.

emattias’s picture

Status: Active » Needs review
StatusFileSize
new478 bytes

For me(with node references) it was that stuff is added to the node object so the comparison between the $node object in the db and the current list item returns false. But the entity api adds $node->original which is the original $node object.

Here's a patch that checks if ->original isset on the current item(should work on any entity) and uses that in the comparison instead.

mitchell’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Category: support » bug

Is this patch still needed?

geek-merlin’s picture

Title: Can't remove item from reference field » Can't remove item from reference field IF item is changed before

yes it is.

i can confirm that
* with todays dev and
* a product reference field
a remove($list, $item) does NOT do the remove.

debugging confirms the analysis in #10:
* looks like $item has always an new revision-id even if it is freshly loaded and not changed (suppose entity api prepares this for us)
* so the deep comparison implicit in array_keys($list, $item) can not work
* applying the patch makes it worksforme

@fago: maybe this issue rises a deeper question about how to test equality for entities.
maybe we should just expose the "original" property instead of doing magic.
maybe weh should let user choose "object equality" against "entity id equality".
think you have some ideas about this.

daring to raise prio as data manipulation of this kind is a core use case for rules and this one is badly broken.

geek-merlin’s picture

Title: Can't remove item from multivalued User Reference or Entity Reference list » Can't remove item from reference field
Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

oops, as stated above...

mitchell’s picture

Title: Can't remove item from reference field IF item is changed before » Can't remove item from reference field
Component: Miscellaneous » Rules Core

Updated component.

klausi’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

Cannot reproduce. I tested this with entityreference and commerce_product_reference and in both cases removing an item from a multi-valued field worked without any problems.

Can you provide a minimal setup to reproduce the error?

And the provided patch seems wrong to me, what has the original entity to do with this?

geek-merlin’s picture

ad #15:
> And the provided patch seems wrong to me, what has the original entity to do with this?

read my #12

web360’s picture

Issue summary: View changes

Encountered same issue with node reference with multi-values. #10 Patch works.

thib’s picture

I encountered same issue with Entity Reference

thib’s picture

I used this tutorial to creat a backlinks system : http://nodeone.se/en/creating-multiple-back-links
The problem with this tutorial is that it does not provide solution to remove backlinks created on the other node when one of them is remove to another.
So I create a VBO Views to load node referencing the modified node and set ​​a rule, that the action occurs before the creation of backlink, to remove the modified node from their entity reference fields.
It's this last action that does not work.

I don't know if this is very understandable !!!

asak’s picture

Yep. look like this patch is still needed.
Tested with a reference field that didn't update without the patch - works will with the patch.