Opened 6 years ago

Closed 2 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 Changed 6 years ago by David Findlay <djangoproject-finhome@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 Changed 6 years ago by David Findlay <djangoproject-finhome@…>

  • Component changed from Uncategorized to django.contrib.admin

comment:3 Changed 6 years ago by Alex

  • Triage Stage changed from Unreviewed to Design decision needed

comment:4 Changed 5 years ago by margieroginski

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 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

See #11313 for a related issue.

comment:6 Changed 4 years ago by aaugustin

  • 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 Changed 2 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to closed

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