Opened 15 years ago

Closed 11 years ago

#11652 closed New feature (wontfix)

Simultaneous editing of a record via the admin interface silently overwrites

Reported by: David Findlay <djangoproject-finhome@…> Owned by: nobody
Component: contrib.admin Version: 1.1
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I am seeing the following situation.

  1. sign into admin as user A in one browser and begin to edit a record, e.g. http://example.com/admin/myapp/mymodel/1
  2. sign into admin as user B in another browser and begin to edit the SAME record, i.e. same URL as user A
  3. make a change as user A and press Save
  4. make a different change as user B and press Save

The result is that A's change is silently overwritten with user B's change.

Should it not generate an error when user B saves, informing them that the record has been updated since they started editing it?
That is what I would have expected to have been the default behaviour.

There's likely some corner cases I'm not thinking of, but it seems like this could be checked for by:

  1. saving a copy of the model object when a user does the GET of the model's page, the model object with PK of 1 in my example of http://example.com/admin/myapp/mymodel/1
  2. during the validation that occurs when the user POSTs their updates, pull the model object from the database again - prior to saving any changes. If that copy of the model is different from the copy retrieved in the previous step, then the model has been updated in the interim by someone else. In that case the error could be passed to the user and the save aborted. If the two copies are the same then the model hasn't been altered in the interim, and the save could proceed as normal.

If there's a standard way of implementing this already I'd be most grateful to know how to go about it.

Change History (7)

comment:1 by David Findlay <djangoproject-finhome@…>, 15 years ago

gah, I did the wiki formatting incorrectly. the STR should be:

  1. sign into admin as user A in one browser and begin to edit a record, e.g. http://example.com/admin/myapp/mymodel/1
  2. sign into admin as user B in another browser and begin to edit the SAME record, i.e. same URL as user A
  3. make a change as user A and press Save
  4. make a different change as user B and press Save

my apologies

comment:2 by David Findlay <djangoproject-finhome@…>, 15 years ago

Component: Uncategorizeddjango.contrib.admin

comment:3 by Alex Gaynor, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:4 by Margie Roginski, 14 years ago

Hi,

I just want to note that I have written a wealth of related info on this topic in http://code.djangoproject.com/ticket/12440, based on my experience implementing a multiuser environment. Also, http://code.djangoproject.com/ticket/12337 is related and has some points on this issue as well.

comment:5 by Julien Phalip, 13 years ago

Severity: Normal
Type: New feature

See #11313 for a related issue.

comment:6 by Aymeric Augustin, 13 years ago

Easy pickings: unset
UI/UX: unset

See also #16549 that proposes some changes to the Model and QuerySet APIs to make it easier to implement optimistic locking.

comment:7 by Aymeric Augustin, 11 years ago

Resolution: wontfix
Status: newclosed

This ticket doesn't contain a lot of details, and for this kind of features, the devil is often in the details :)

You haven't addressed inlines, deletion of related objects, proxy models, etc.

I don't think the approach proposed here will be easy to implement; #16549 sounds like a better idea.

Please write to django-developers (preferrably with a proof of concept) if you disagree.

Note: See TracTickets for help on using tickets.
Back to Top