Description: This issue manifests itself when quickly entering field data into a Views display. If a subsequent field ajax event is triggered before earlier ajax callbacks are complete, the entered values are often saved to the wrong entity and/or loaded into the wrong row in the display.

Proposed solution: more fully qualify the form field's id in "function editablefields_views_form" by adding the entity ID to the form's "parents" array. This solves the problem as long as the same entity ID is referenced only once on the page (the form field's ID becomes a unique combination of field ID plus entity ID). See forthcoming patch from _vid for details.

Note: The display's row ID considered instead of entity ID, however it was not enough of a qualifying value, in that a given row ID will show up multiple times when more than one instance of a display is included on a page (as may happen when using a view reference field in a display).

CommentFileSizeAuthor
#5 editablefields.module_name_space_collision-1784158-5.patch1.01 KB_vid
#4 editablefields.module_name_space_collision-1784158-4.patch1.01 KB_vid
#1 editablefields.module_name_space_collision-1784158-1.patch1.07 KB_vid
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

_vid’s picture

_vid CreditAttribution: _vid commented
Status: Active » Needs review
FileSize
editablefields.module_name_space_collision-1784158-1.patch1.07 KB

Patch attached for your review.

dags’s picture

dags CreditAttribution: dags commented
Status: Needs review » Postponed (maintainer needs more info)

The proposed patch seems reasonable but I can't for the life of me reproduce the issue. I even put some sleep()s in my code to slow down the callbacks. Under what conditions did you encountered this bug?

joseph.muennich’s picture

joseph.muennich CreditAttribution: joseph.muennich commented

The impacted views display in our use case:

  1. Contains 1 editable field per row.
  2. Is included multiple times in a separate views display using a views reference field

In our completed use case, the entity type of the field being updated is also subject to a presave function - though this namespace-collision behavior is still present when the presave function is disabled (I just rechecked to be sure). Two other view reference fields are also included in the final display - likely contributing to our lag time.

Let me know if more information / context is needed to reproduce this behavior (or contact me privately for a more in-depth walk-through).

_vid’s picture

_vid CreditAttribution: _vid commented
FileSize
editablefields.module_name_space_collision-1784158-4.patch1.01 KB

We're still using this patch and I just re-rolled it from within the editablefields directory.
Essentially the only change is the 1st line (diff):
diff --git a/editablefields/editablefields.module b/editablefields/editablefields.module
Becomes
diff --git a/editablefields.module b/editablefields.module

_vid’s picture

_vid CreditAttribution: _vid commented
Issue summary: View changes
FileSize
editablefields.module_name_space_collision-1784158-5.patch1.01 KB

One more submission. This patch has a new line at the end which drush make needed.

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet at The University of British Columbia commented
Version: 7.x-1.0-alpha2 » 7.x-1.x-dev
Status: Postponed (maintainer needs more info) » Needs review

Moving this to the right branch and status

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet at The University of British Columbia commented
Status: Needs review » Needs work

Tried this and it doesn't work anymore, the replacements just don't replace because it can't find the element with that parent ID.