Opened 8 years ago

Last modified 2 years ago

#28283 new Bug

_changeform_view sends wrong object after ModelForm validation

Reported by: ddein Owned by:
Component: contrib.admin Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no
Pull Requests:How to create a pull request

Description

I noticed strange behavior when changing the form of the admin. If I try to save the form with an error, some functions (get_fieldsets, get_prepopulated_fields, get_readonly_fields, get_inline_formsets, something else) get the wrong object after validation. See here: https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1436-L1437
It seems to me not obvious, that after call is_valid, object obj will be changed. The quick solution for me was the following:

form = ModelForm(request.POST, request.FILES, instance=copy.copy(obj))

But maybe the problem elsewhere. Has anyone encountered a similar one, is this a mistake or normal behavior?

According to the ticket's flags, the next step(s) to move this issue forward are:

  • To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is: [https://github.com/django/django/pull/#### PR].

Change History (4)

comment:1 by Tim Graham, 8 years ago

Triage Stage: UnreviewedAccepted

I think this is related to this note in the documentation:

The cleaning process modifies the model instance passed to the ModelForm constructor in various ways. For instance, any date fields on the model are converted into actual date objects. Failed validation may leave the underlying model instance in an inconsistent state and therefore it’s not recommended to reuse it.

in reply to:  1 comment:2 by ddein, 8 years ago

Replying to Tim Graham:

I think this is related to this note in the documentation:

Alright, I can check my code and not allow this error. But we are talking about the code that is used in administration and obviously a correction is needed here.

comment:3 by ddein, 8 years ago

Owner: changed from nobody to ddein
Status: newassigned

comment:4 by Mariusz Felisiak, 2 years ago

Owner: ddein removed
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top