Current if two or more users working at node/add/story, if one saves, others' autosave will be lost.

CommentFileSizeAuthor
#6 uid_on_node_add.patch1.22 KBliquidcms
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jcisio’s picture

jcisio CreditAttribution: jcisio commented
Priority: Normal » Major

Pump to major. For medium to large sites, most users spending time to add new nodes, not modify the old ones.

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

are these anonymous users? as the autosaved form is keyed with uid so doesn't make sense that this should be happening.

jcisio’s picture

jcisio CreditAttribution: jcisio commented

No, there is no uid in form_id. The form_id is something like this: blog_node_form or story_node_form. The problem is at line 186-194.

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

nope, not what i meant. when the form is stored in the db - it is saved with the user's uid. and when the form values are pulled up later (when that user goes to re-edit) this code is used:

function autosave_get_autosaved_form($form_id, $path, $uid) {
  $result = db_query("SELECT form_id, serialized, timestamp FROM {autosaved_forms} WHERE form_id = '%s' AND path = '%s' AND uid = %d", $form_id, $path, $uid);
.
.

which again uses his uid in the KEY to get which entry is pulled from the db.

So the db stores both the path to the node edit AND the uid. So path is typically enough if they are editting an existing node (path = node/123/edit) but yes, it isn't enough on its own when the user is editing a new node for first time as the path is simply node/add/type.. which is why it is also keyed with the uid.

so basically you would have in the db, if 2 people editing,

node/add/type, 5
node/add/type, 23

and we would be able to distinguish.

the only place this falls down is if you have anonymous users editing as they all have uid = 0. Only way to fix that would be to key off there IP address - although not completely sure how well that would work if multiple users are all behind same router (i.e. at the same company) as they may all present the same IP address.

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

ahh... yup.. i see now.

yes, the code you refer to will cause a problem but was required as mentioned in the comments

// we remove ALL edits for that page (not just the users) to avoid:
// - user1 asaves but doesnt submit
// - user2 edits same node and submits
// - user1 comes back to edit -> user1 SHOULD lose edits since user2 has precedence

but this will break in your case.

likely i need to qualify the delete here with the /add path type. I'll take a look later this afternoon and post a patch.

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented
FileSize
uid_on_node_add.patch1.22 KB

any chance you can try this patch?

jcisio’s picture

jcisio CreditAttribution: jcisio commented

I think, instead of checking the path, we should check the nid in the form (think that the node form can be populated by Ajax or be embedded in any page).

Edit: I didn't see the patch above. Will try it later. However the comment is still valid ;)

liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

yea, except this is when saving the node.. we don't have the form at that point..

but i think you may be right about the form being embedded - although was never the intent of this module; possibly easy to check if $node->nid exists at that point. i'll need to test this out but seems like it should be ok - will test later today and provide a new patch if works