enitity_save_uuid() saves a node revision as an update, not a new record [#1890666]

When attempting to save a revision as a new record by uuid, entity_uuid_save() will change the revision flag to 0 (since the vid isn't set because the vuuid doesn't exist, but the is_new flag is turned off because the UUID does exist in the database) in entity_make_entity_local() before it calls entity_save(), and therefore the node will only get updated and revisions will not be saved.

Comment	File	Size	Author
#4	save_node_new_revision-1890666.patch	811 bytes	timaholt

Comments

Comment #1

getweed commented 30 June 2013 at 11:12

Version:	7.x-1.0-alpha3	» 7.x-1.x-dev
Component:	Code	» Documentation
Assigned:	Unassigned	» getweed
Category:	bug	» task
Status:	Active	» Patch (to be ported)

Comment #2

skwashd commented 3 July 2013 at 08:00

Component:	Documentation	» Code
Category:	task	» bug
Status:	Patch (to be ported)	» Active

Updating fields to reflect the correct information for the issue.

@getweed are you planning on fixing this issue? If not please unassign it from yourself.

Comment #3

timaholt commented 19 August 2013 at 19:00

@getweed what is your use case here? I'm about to work up a patch to change this behavior if the vuuid does exist if the revision is being pushed in via deploy. It's easy enough to check for isset($entity->{$vuuid_key}) and then flick the revision switch to 1, but that is the use case I have for it. It sounds like you have a use case where you are saving the node without a vid or vuuid, but still want to force a revision?

Comment #4

timaholt commented 20 August 2013 at 15:08

Assigned:	getweed	» Unassigned
Status:	Active	» Needs review

Status	File	Size
new	save_node_new_revision-1890666.patch	811 bytes

Ok attached is a patch that will see if the content type has revisions enabled by default, and then change $entity->revision to 1 if that is the case. This should work for both of our use cases. Can you review?