Active
Project:
Field collection
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
12 Oct 2012 at 16:25 UTC
Updated:
23 Mar 2015 at 23:16 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
baronmunchowsen commentedI'm updating with some more information.
1) Content type with a field collection field
2) Field collection field 'widget type' set to Embedded.
3) Add content using node/add form - creates first revision
4) Edit content using node/%/edit form - edit content title and field collection - check create a new revision - creates second revision
5) Look at node revisions - the revisions respect the changes to the field collections
--everything hunky-dory here--
6) NOW - edit the field collection field value from the node page (node/%) - see attached
7) Edit the field collection field value - save - the field collection field value has been updated BUT the node has not created a new revision.
The issue here is that this allows changes to be made to field collections that belong to nodes without respecting the rules that the node might be restricted by - for instance a module like workbench_moderation.
I can see that it could be very tricky to check and see what entity/bundle the field collection field belongs to and then see what steps need to be taken when saving that field. Perhaps it would be simpler to add a permission or option to turn 'off' the direct field collection edit paths:
field-collection///edit
field-collection//add/node/
when configuring the field - making the fields only editable via the node edit form (and therefore follow any revision control rules that node is under)...
Cheers,
Olly
Comment #2
webchuck commentedAny progress on this issue? It seems like if we can create revisions from the node form, we should be able to do it more generally for all entity updates. I am willing to chip in some development time toward this, but am not too familiar with Entity API. Any suggestions on how we would approach this update?
Comment #3
webchuck commentedOkay, here's what I've found...
In field_collection.pages.inc, the add/edit form calls this function:
Now we compare that to what's being called on node save:
So I tried to copy some of this to the add/edit form. I added the following:
And this worked! Kinda... It did save the node and create a new revision for the field collection.
Unfortunately, I'm using the Revisioning module, which keeps different states of the node, and that's really throwing things off. If I have a node in a saved/draft state, and edit the node again, I lose the previous modifications. So while this approach kinda works, it's obviously not the "right way" to be doing this.
Any thoughts from those who are deeply entrenched with this module?
Comment #4
davidsickmiller commentedI've made a patch that modifies the submit function to check the host entity's options and, if revisions are enabled, signals the field collection item's save() function to create a new host entity revision. This will work for adds and edits.
I personally would like host entity revisions to also be created upon deletion of a field collection item. Unfortunately, this goes through the field_collection_item_delete_confirm_submit() function, not field_collection_item_form_submit(), and seems to be more complicated.
On a side note, the field collection item's save() function has a comment that says "If this is creating a new revision, also do so for the host entity." and the nearby code does a check for $this->is_new_revision. I think either that comment is wrong or else the code is supposed to check $this->is_new. If the latter, a new host entity would already be always created when a field collection item is added (except with explicitly skipped with $skip_host_save), regardless of the changes in my patch.