Two people editing a node at the same time can result in loss of first changes [#50316]

The functionality introduced by the patch discussed in this thread is not working in 4.7 Head. This means that the following sequence will result in data loss:

Alice opens a node for editing
Bob opens the same node for editing
Bob saves his changes
Alice saves her changes to the node, overwriting Bob's changes

When Alice tries to save her edits, she should be presented with this error message from line 1581 of node.module:
form_set_error('changed', t('This content has been modified by another user; changes cannot be saved.'));

I've set priority normal, as any data loss should be recoverable through the revisions system. Please clue me if this is not appropriate.

My environment:
Drupal: 4.70 Head (CVS)
node.module: 1.603
PHP: 5.1
MySQL: 5.0.18-max (non-strict mode)
OS: Mac OS X 10.4

Comment	File	Size	Author
#3	node_edit_protect.patch	1.49 KB	hunmonk
#3

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Egon Bianchet CreditAttribution: Egon Bianchet commented 4 May 2006 at 20:35

Version:

4.7.0-beta4

» 4.7.0

Comment #2

hunmonk CreditAttribution: hunmonk commented 16 July 2006 at 15:04

Version:

4.7.0

» x.y.z

this is still a problem in current HEAD.

Comment #3

hunmonk CreditAttribution: hunmonk commented 16 July 2006 at 16:14

File	Size
node_edit_protect.patch	1.49 KB

$node->changed was being passed internally as a value, per the FAPI conversion. this breaks this functionality. so two things need to happen to fix this:

changed has to be sent to the client as a hidden field, so we can mark for them the last time the node was edited
we have to examine $_POST upon submission of the node form, not $form_values, because when the form is submitted, it's rebuilt, and the new changed time is what appears in $form_values, not the original changed time that we need for comparison.

i know using $_POST is frowned upon, but i think it's warranted in this case, as we're merely peeking at it for data, and not saving that data anywhere.

attached patch has been tested as functioning, and corrects the problem.

Comment #4

hunmonk CreditAttribution: hunmonk commented 16 July 2006 at 16:15

Assigned:	Unassigned	» hunmonk
Status:	Active	» Needs review

Comment #5

chx CreditAttribution: chx commented 16 July 2006 at 16:45

Status:

Needs review

» Reviewed & tested by the community

rule of $_POST is: use it to compare but never display or store it. This is kept.

As you are using #value and not #default_value even if the user changes to something foul the hidden field, there is no harm because the actual value of the form can't change. Though it'll show in $_POST and you compare against that. So far, so good.

Restores lost functionality without the mere possibility of boring sechole. RTBC.