-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Admin: Issues when updating records through list_editable fields #798
Comments
Interesting. So I guess the solution is to create one revision per updated
row. Not sure how feasible that is with the admin app's architecture.
…On Thu, 4 Jul 2019 at 19:10, Panagis Alisandratos ***@***.***> wrote:
I've encountered 3 issues involving multiple records being updated at the
same time through the admin changelist page (through fields that are
included in ModelAdmin.list_editable):
1. The actions on history pages will be the same across all records in
an update set, rather than being specific to each record. If you were to
perform an update on distinct fields across multiple rows, the updates to
the fields performed for the last row are the ones that will be listed on
every record's history.
2. Reverting one record via the admin interface will revert all
records that were part of the same update (i.e. the same revision), and...
3. ...the history of only one record will be updated (the revert row
will only be present on the history page of the record that was used to
perform the revert).
To reproduce this locally, you can follow the steps list in a repo I
created specifically for this ticket
<https://github.com/Palisand/django_reversion_issue_tester>. It provides
an example that showcases all of the issues mentioned above.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#798?email_source=notifications&email_token=AABEKCEVRBR5UVUSVVGDIE3P5Y4KPA5CNFSM4H56GF3KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G5NTUXA>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABEKCCW2BAYXWJ3ABZBADLP5Y4KPANCNFSM4H56GF3A>
.
|
It would be cool if there was an option on the history page to either revert only one record or all records that were part of an update. I'm currently playing with this project's source; hopefully I'll have a PR ready in the near future. Awesome work by the way. |
So |
Unfortunately, it doesn't look like changelist_view has the required hooks
to implement this, and maintaining a patched copy of that method in
django-reversion is a maintainence burden I don't really want to take on.
I think that the only solution for now is to warn people in the docs that
this doesn't work as expected.
…On Fri, 5 Jul 2019 at 16:34, Panagis Alisandratos ***@***.***> wrote:
So VersionAdmin wraps ModelAdmin.changelist_view with the create_revision
context manager. @etianen <https://github.com/etianen> Is there a way to
have 1 reversion created per save invocation rather 1 for all? I've got a
nasty 🤢 way to do it: copy the contents of ModelAdmin.changelist_view
into VersionAdmin.changelist_view and wrap the saving of resources
<https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1735-L1739>
in self.create_revision(request).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#798?email_source=notifications&email_token=AABEKCGAD2SLHTYXPDOYHIDP55SY3A5CNFSM4H56GF3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZJZ3HQ#issuecomment-508796318>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABEKCFLDDTUA536VOAUNHLP55SY3ANCNFSM4H56GF3A>
.
|
I've encountered 3 issues involving multiple records being updated at the same time through the admin changelist page (through fields that are included in
ModelAdmin.list_editable
):To reproduce this locally, you can follow the steps listed in a repo I created specifically for this ticket. It provides an example that showcases all of the issues mentioned above.
The text was updated successfully, but these errors were encountered: