Code

Opened 3 years ago

Last modified 3 months ago

#16327 new Bug

"save as new" redirects to list view instead of newly-created item

Reported by: candlerb Owned by: nobody
Component: contrib.admin Version: 1.3
Severity: Normal Keywords: saveasnew
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have a model with save_as = True

After browsing to the model, changing some parameters and clicking "Save As", the browser redirects to the list of all objects instead of the newly-saved model instance.

There is code in response_change which looks like it is supposed to handle this case. However, after putting in some sys.stderr.write's, I see that the request is actually ending up in response_add instead :-(

The attached one-line patch to django/contrib/admin/options.py fixes it for me. However I'm not sure if that's right for all circumstances, nor whether the code in response_change which tests for "_saveasnew" is always unused and should also be removed.

Attachments (1)

django-16327.diff (727 bytes) - added by candlerb 3 years ago.

Download all attachments as: .zip

Change History (6)

Changed 3 years ago by candlerb

comment:1 Changed 3 years ago by ramiro

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed
  • Type changed from Bug to Uncategorized

tl;dr: We need to decide if after clicking the 'Save as new' in a model change view the user should be taken to the changelist like we are doing or to the change view of the model instance just cloned as the OP proposes.

The behavior of redirecting to the model changelist (or the admin app index page) has been so since newforms admin was merged back in r7967 (with later fixups like the ones in #10448/r10713). And yes, AFAICT the code block in ModelAdmin.response_change() that supposedly handles this has been dead code since its introduction in r8273.

See also #8001.

Last edited 3 years ago by ramiro (previous) (diff)

comment:2 Changed 3 years ago by candlerb

The use case is to be able to make multiple clones of an existing model, each slightly different. It's painful if you have to keep re-locating the just-saved model in the changelist.

"continue editing" is arguably orthogonal to "save / save as new" - but I don't want four buttons :-)

Suggestion: permit _continue as a separate form field. That is, the posted data could contain both _saveasnew and _continue. You could then add _continue as a hidden field (for fixed behaviour) or a checkbox.

For this to work, we just need to ensure that both flags are honoured if they are both present in the view code. It should be backwards-compatible, since _continue can also be a submit button.

I would like to be able to control this from the ModelAdmin without having to write my own submit_line though. e.g.

save_as = True
continue_editing = False / True / 'ask' # ???

comment:3 Changed 13 months ago by aaugustin

  • Type changed from Uncategorized to Bug

comment:4 Changed 13 months ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

comment:5 Changed 3 months ago by ste@…

This is still a problem with 1.6.1. I agree with candlerb - the 'save as' feature is useful for quickly hammering out lists of objects where only 1 or 2 (of many) fields change each time.

I think ModelAdmin.continue_after_save_as = False would probably be the best way to achieve this. It wouldn't break backwards compatibility. If anyone else thinks this is a good idea, I can hack up a patch.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.