TrangPham
commented
3 years ago There is a design choice here and some tradeoffs.
Option 1:
- add
confirm_actionoption to an admin- it can confirm all the actions (Maybe as a default?)
- or have a
confirmation_actionsoption to list which actions should be confirmed
- this would entail overriding
response_actionon the ModelAdmin - to make the
Gobutton actually call theresponse_actionwith a parameter indicating that confirmation is required- maybe override the current ActionForm on the model to use the
confirm_actionoption when first pressed and then after the confirmation template will call the ActionForm again without theconfirm_action. This would be similar to how the confirm_add/confirm_change overrideschangeform_view - Or we can look for where the button html actually is and redirect that to the confirm_action template/form and then confirmation will call the response_action. With this we probably won't need to override ActionForm or response_action.
- maybe override the current ActionForm on the model to use the
Pros:
- simple
- settings/options format is similar to current options
Cons:
- does not handle when end-user has already set ActionForm or returned an intermediate page for their action
- Django docs recommend using intermediate page and doesn't mention the ActionForm. They also say that the intermediate page is up to the end-user to define/create
- would be going against the way that Django already has set up for this.
- If you look at the delete confirmation that's built into Django, the action is what gets called twice, and that determines if the confirmation needs to be shown or not, and the confirmation page calls it again (somehow? I need to look more at this) and then the action is actually performed in the action function. ActionForm and response_action are not modified for this.
Option 2:
- use a wrapper/decorator for setting which actions should be confirmed ie
@confirm_action - this could probably use the same method as delete confirmation, except the wrapper would be adding the intermediate page for the user and then calling the action function from the confirmation page.
- I actually. think this is better... since we won't have to override the internals of Django ModelAdmin (since we do run a risk of things changing underneath and breaking our library). This would also use the method recommended by documentation and used by Django's delete confirmation.
- In this case if the end-user has defined an intermediate page already and uses the wrapper, the confirmation page will show first and then the end-user's intermediate page would probably show after the confirmation page.
Option 3:
- can we somehow apply the wrapper to the functions if we have
confirm_actionandconfirmation_actions? And then we can be flexible in the way the end-user can configure the confirmation for actions?- It looks like there might be a way to do this in init
- see https://stackoverflow.com/questions/6307761/how-to-decorate-all-functions-of-a-class-without-typing-it-over-and-over-for-eac
Option 3 seems to have the best of both worlds, so this is what we're going with.
Here's some basic research:
Beware of: https://docs.djangoproject.com/en/3.1/ref/contrib/admin/actions/#actions-that-provide-intermediate-pages
ActionForm
https://github.com/django/django/blob/b79088306513d5ed76d31ac40ab3c15f858946ea/django/contrib/admin/helpers.py#L22
Built in Delete action has a confirmation page: https://github.com/django/django/blob/master/django/contrib/admin/actions.py https://github.com/django/django/blob/master/django/contrib/admin/templates/admin/delete_selected_confirmation.html
This is the code that actually runs the action: https://github.com/django/django/blob/aade2b461acafd16cfc82449b3df88a0f1c1c197/django/contrib/admin/options.py#L1354
So you'll want to surround that and then call the action. This won't work well if the end-user is already returning a custom form.