Admin-Actions also in the object details view

Hello everyone!

I’m bringing this topic from the google-developers mailing list back: “Admin-Actions also in the object details view

There is a ticket in which I’m currently working on: #12090

And as @nessita well mention in the pull request: Fixed #12090 -- Show admin actions on the edit pages too by mgaligniana · Pull Request #16012 · django/django · GitHub we (as a community) haven’t defined a feature design.

So, a couple of things to define are:

  1. The work I’ve done was to add a new attribute: detail_actions, trying to be “less disruptive”. So you can define some actions for list and others for change view.
  2. “what happens with unsaved objects” → In my approach if you edit the object, choose an action and press “Go” the object won’t be saved but the action would be executed.

I appreciate any feedback!

Thank you!

1 Like

Hi @mgaligniana, thanks for taking this on.

Two thoughts, having looked (but only briefly) at the PR.

  1. I’m not sure the detail_actions attribute pays its way… I suspect most cases would just want actions to be picked up there, getting just the single object QS. For the times when those need to differ, there are the method hooks that I could override. Not sure, but I generally lean to keeping the API tighter as a rule, and I suspect that applies here… :thinking:
  2. I’d disable the detail actions for unsaved objects TBH. Otherwise my action code has to include checks for the pk everywhere. I’m not seeing where the need for actions on an unsaved object is that would pay for that. Again… :thinking:
1 Like

+1 to both of Carlton’s suggestions. If a user wants to disable actions in the detail or list views, they can do so in a custom get_actions method.

1 Like

I agree with both items with one clarification. For the “what happens with unsaved objects”, we should consider the cases where:

  • the object is being created (ie no pk which I think is what Carlton refers to), or
  • the object exists and is being edited.

For the former, I agree actions should be disabled. For the latter… I think it could be confusing as to why the actions are disabled. In general UI/UX terms, having buttons/links showing in a disabled state generally leads to user frustration because they have to “guess” what magic incantation to spell to make those functional.

OTOH, the actions could be initially enabled for an existing object (I think?) and then switched to disabled when the user changes a value. But I personally don’t like this option because it’d need some untrivial JS (afaik). What about:

  • For non persisted objects (no pk, creation page), disable the actions with a small legend “Actions are disabled for unsaved objects”.
  • For existing objects (ie objects with a pk), have the actions enabled at all times and perform the action on the object state as found in the db.

What do you think?

Good point @nessita. I only had new objects in mind.

I agree that tracking the unsaved changes state in JS is probably more effort than it’s worth. Actions performed on the object as in the DB seems a good default to me.


1 Like

Agree as well, I was reading Carlton’s suggestion as applying to new objects. I don’t think it should be surprising that if you edit an existing object and then click an action (rather than “save”) that the edits aren’t saved.

1 Like

Thank you all for your comments and feedback! :heart:

I pushed some progress and added tests to “reflect” what we’ve defined:

  • test_available_detail_actions
    DELETE action is not present because in change view already exists a button to do that.

  • test_detail_actions_are_not_present_in_add_view
    nessita proposes disable the actions. But why not simple not render them in ADD view?

  • test_update_external_subscriber_without_select_an_action
    If user edits the form and don’t select any action, object will be saved successfully.

  • test_external_subscriber_is_not_updated_when_select_an_action
    If user edits the form and choose an action, the action will be executed but object is not updated.

  • test_custom_function_action_streaming_response
    The same action function is supported in LIST and EDIT view.
    But I have a question: how should we handle the fact that the function could receive a QUERYSET or a an OBJECT? I added the doubt here.

And as a last question: What should we do with the djm’s comment about action description?

What about leaving the DELETE action in the new action dropdown and removing the button from the submit-row?
This would align with my comment in ticket-33728

This is a valid and interesting point. I did some research, and I agree with what this article concludes. So, I think not adding the action list in the ADD view is the right path forward, as you suggest @mgaligniana . It also matches the current UI where the DELETE button is not rendered either when creating an object.

I will review the branch next week to further understand possible options and make a recommendation based on that.

My first gut feeling would be to have a new description_plural that would default to description if not set, and add clear documentation for both the feature and the release notes. What do you think?

1 Like

Ohh, I hadn’t seen that ticket! I +1, IMO have the delete action in the dropdown will be intuitive because you already comes from the list view.

Yes! The “description” is too generic to do an approach like verbose_name and verbose_name_plural, so give the user the opportunity to specifiy/describe the action for only 1 object makes sense to me.

Thank you! :hugs: