[Django] #30963: Modifying model values via list_editable on admin can rollback data
Django
-------------------------------------------+------------------------
Reporter: Leonardo Arroyo | Owner: nobody
Type: Bug | Status: new
Component: contrib.admin | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------------+------------------------
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/30963>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
---------------------------------+-----------------------------------------
Reporter: Leonardo Arroyo | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* stage: Unreviewed => Someday/Maybe
* version: 2.2 => master
Comment:
> 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:1>
Django
---------------------------------+-----------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:2>
Django
---------------------------------+-----------------------------------------
Type: Bug | Status: new
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Ülgen Sarıkavak):
* cc: Ülgen Sarıkavak (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:3>
Django
---------------------------------+-----------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by AashishDhakal):
Anyone working on this?
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:4>
Django
---------------------------------+-----------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adam Zapletal):
Replying to [comment:4 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:5>
Django
---------------------------------+-----------------------------------------
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Mohammad Ali Mehdizadeh):
I have a suggestion:
storing all the initial states as hidden input in the HTML side, with the
time stamp the page is loaded, on submit, only changed fields are set to
be updated, and others are ignored!
But I think this issue is on the ORM side.
--
Ticket URL: <https://code.djangoproject.com/ticket/30963#comment:6>