Opened 17 years ago
Closed 12 years ago
#5681 closed Bug (fixed)
Save as new disappears on failed validation
Reported by: | Ville Säävuori | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Normal | Keywords: | admin, save |
Cc: | mathijs@… | Triage Stage: | Design decision needed |
Has patch: | no | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
When I have a model with admin attribute save_as = True
, and save it via admin in a way that it triggers validation (ie. some fields are missing or incorrect), 'Save as new' button disappears from the page. After correcting the given values, when saving the object, it's saved on top of the old object and not as a new as was intended.
Attachments (2)
Change History (11)
comment:1 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
by , 16 years ago
Attachment: | patch5681.diff added |
---|
by , 16 years ago
Attachment: | patch5681-1.diff added |
---|
comment:2 by , 16 years ago
If after pressing the "Save as new" button the form is not valid, the user should be presented the same form. (the "edit" form instead of the "add" form), because as long as the form is not valid the instance should be the same. The patch I uploaded solves this issue.
comment:3 by , 14 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
comment:4 by , 14 years ago
Triage Stage: | Accepted → Design decision needed |
---|
Use case: When I have a model with admin attribute save_as = True
, and save it via admin in a way that it triggers validation errors (ie. some fields are missing or incorrect).
Users Uninen (the original reporter) and Cornel (in comment:2) report three issues here:
- In that case the user should be presented the same form (the "edit" form instead of the "add" form as it happens currently), because as long as the form is not valid the instance should be the same.
- Save as new button disappears from the page (it is replaced by the usual Save and add another button of an "add" form.)
- After correcting the given values, when saving the object, it's saved on top of the old object and not as a new as was intended.
Currently item 3 (the only that would cause data loss) doesn't happen anymore (possibly some other work in the area during the last three years fixed it). A new model instance is created when you press either the Save and add another, Save an continue editing or Save buttons.
I don't agree with items 1 and 2, once the user has made the decision she wants to create a clone copy of the original model instance, the form shown after a validation error doesn't have to be the one pointing to the original object. IMHO it is better the way it works now: An "add" form is shown with all the valid fields pre-filled and all the possible save options do create a new model instance without endangering the original one.
I'm moving back this ticket to Decision needed.
comment:5 by , 14 years ago
Cc: | added |
---|
comment:6 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:7 by , 13 years ago
Easy pickings: | unset |
---|---|
Resolution: | → fixed |
Status: | new → closed |
UI/UX: | unset |
On the basis of ramiro's comment, closing this as fixed, since the real problem is that a new object was not created. Otherwise, existing behavior seems reasonable.
follow-up: 9 comment:8 by , 13 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I can confirm that under some circumstances at least, using any Save option after a validation failure on Save as New does not create a new model instance. Instead, the original item is overwritten.
This is with 1.3.0 final. So, I think that this should not be considered resolved.
comment:9 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Replying to anonymous:
I can confirm that under some circumstances at least, using any Save option after a validation failure on Save as New does not create a new model instance. Instead, the original item is overwritten.
This is with 1.3.0 final. So, I think that this should not be considered resolved.
At this point we'd need a failing test case (with a models/admin setup as simple as possible) or script (as in a sequence of user actions) that shows the described behavior, using currently supported versions (1.4 and maybe in-development 1.5 or trunk). Feel free to reopen the ticket if you can provide any of these,
against rev 10203