Admin list_editable not suitable for multi-user environment.

[Leonardo Arroyo]

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?

[Carlton Gibson]

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.

[Eran Keydar]

What about the next approach.

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

[Aashish Dhakal]

Anyone working on this?

[Adam Zapletal]

Replying to Aashish Dhakal:

Anyone working on this?

It looks like no one is working on this ticket since it hasn't been updated in a long time, there are no related pull requests, and the "Owned by" field is empty. It's also important that the ticket hasn't been "Accepted" yet in the "Triage Stage" field. Maybe you could suggest something new based on the earlier comments and see if one of the maintainers will accept your proposal.