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.
“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.
Two thoughts, having looked (but only briefly) at the PR.
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…
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…
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.
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.
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.
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.
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?
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.
