Opened 9 months ago

Last modified 7 months ago

#30963 new Bug

Admin list_editable not suitable for multi-user environment.

Reported by: Leonardo Arroyo Owned by: nobody
Component: contrib.admin Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Suppose you have a model with a delete flag for soft deleting(or any other data for that matter). This field is included in list_display and list_editable on the admin.
Whenever the following flow happens, you can lose data:

  • Admin loads the model records listing page.
  • An end-user deletes some entry while the admin has the page loaded
  • Admin modify another record and save it

This will undelete the record, as django will save the fields for all records listed.
This can be a problem especially for sites with high volume of data being edited, I believe a more appropriate behavior would be to save only the data that the user has actively changed.

Is the current behavior the expected behavior?

Change History (2)

comment:1 Changed 9 months ago by Carlton Gibson

Summary: Modifying model values via list_editable on admin can rollback dataAdmin list_editable not suitable for multi-user environment.
Triage Stage: UnreviewedSomeday/Maybe
Version: 2.2master

Is the current behavior the expected behavior?

It's expected, but not desired.

This has been around as long as the admin has existed. It was noted even before list_editable was available, but that made it more pressing...
See #10922, #11313, #17118. (I'm sure there are more.)

Essentially:

  • Load list view in tab A, edit some fields/submit, but don't submit.
  • Load list view in tab B, edit some (different) fields, submit.
  • Submit tab A.

Expected: previous edits from tab B in place.
Actual: data (from tab B edits) restored to values submitted in tab A. (i.e. the original values.)

If you look at the history, various changes have been made to try to minimize the issue here.
But it still remains.

I'm 100% happy to see this addressed.

I'm going to mark it Someday/Maybe because I'm just not sure what's feasible without a total rewrite of the way the admin works. (It's stateless HTTP requests... — what's needed here is state...) So short of a proposal it's difficult to say if it can be addressed.

I'm half tempted to close as needsinfo for the same reason, but it's a real issue, and comes up intermittently, so I'd rather keep this open to at least track that.

If anyone feels strongly that it should be Accepted, I'd be happy for that too.

comment:2 Changed 7 months ago by Eran Keydar

Maybe the following flow can be used?

  1. Save the timestamp when the page was rendered.
  2. Send this time as part of the POST data
  3. Inside the POST, check if there is any relevant log entry which was created after the timestamp, if so give an error
Last edited 7 months ago by Eran Keydar (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top