Allow for Admin Actions to be applied to an empty QuerySet

[andrepleblanc@…]

Currently if you perform an Admin Action without selecting any rows on the change-list, the action's method doesn't get called at all. I think there are many use cases for actions which do not require an explicit collection. for example if the items are pulled from some external source there could be an action for updating the data, or perhaps various options for exporting the entire list. in this way, an action which gets an empty queryset can be applied to either "ALL" items (which currently isn't possible if the items span more than 1 page) or can apply some generic operation which doesn't pertain to a collection of items. As far as I can tell this has no negative repercussions because any potentially destructive actions, like Delete, will simply attempt to perform their action on an empty queryset, which should do nothing at all.

I haven't created a patch, but the solution is as simple as removing 2 lines (688, 689) from admin/options.py

[Alex Gaynor]

This is an intentional design decision. Actions that don't act on specific items are a fundamentally different and representing them in the same UI is bad practice. You can add links to the object-tools portion of the page to have non-item specific actions.

[andrepleblanc@…]

at the risk of stepping on someone's toes, I'm going to push this issue just a little bit further. The decision to NOT call the method when the selection is empty seems unnecessary. Actions are there for an easy way for developers to add custom functionality to the admin, it should be up to the action itself to decide how to behave with an empty queryset, and any action that is written to work with a queryset will effectively be a no-op when given an empty queryset anyway. what if all I wanted to do was add a message stating 'Please select at least one item to perform this action on' when passed an empty queryset, I dont even have that option because the admin app arbitrarily decides not to call my function, even though it can't have any negative side-effects to simply pass it an empty one. object tools may be the more 'correct' place for a developer to add these types of functionality, but realistically, it's a LOT more work, urls and views need to be constructed to handle it all, templates need to be overridden, and it just feels hacky.

[kvanque]

i agree with andrepleblanc on this. Django is great because it allows the developer to override and
modify the framework easily. I do see Alex's argumentation as violating that pattern, why shall
django lock the developers freedom into what the django-team considers "good UI practice" ?

And as Andre has andrepleblanc has pointed out, also adding helpfull messages is restricted by this code.

[Chris Beaven]

See also: #10768

[Chris Beaven]

Uh, sorry. See also: #12281

[Karen Tracey]

Performing an action on an empty query set should do nothing. Therefore there is no point in calling the action with an empty query set. (If the action did something other than nothing, that would be surprising; enabling such surprises in the admin UI seems like a Bad Idea.) #12281 covers the case of issuing a message that something needs to be selecting before you can successfully perform an action. We should fix #12281 and reject this one.

[xtrinch]

I've got promo codes in my admin panel, and it would be really nice if I could allow users to generate them with a script when they run out of them...

[Humberto Yances]

Replying to Karen Tracey:

Performing an action on an empty query set should do nothing. Therefore there is no point in calling the action with an empty query set. (If the action did something other than nothing, that would be surprising; enabling such surprises in the admin UI seems like a Bad Idea.) #12281 covers the case of issuing a message that something needs to be selecting before you can successfully perform an action. We should fix #12281 and reject this one.

Actions that don't act on specific items are a fundamentally different

I would not state this in such an absolute way, and preclude users the option to make their own wrong choices…

Limited to django, I'm not particularly experienced, I seldom contribute to django programs. Now in the current assignment we need to import data from external sources (openstreetmap, wubook), and we either need to refresh a subset of our already existing items, or we want to import things from scratch. The code in the two cases is obviously the same. The "import from scratch" we run on an empty selection, and our initial workaround was really terrible, that is remove everything, add a fake new object, select it, then run the action.

I'm looking into the object-tools, and I have several perplexities: one is that it looks quite a bit more work to add them; two is that I need to program my actions elsewhere, while they do fundamentally the same thing; three is that the action I need depends on the table I'm in, it's definitely not a generic tool.

so while we can't activate the action on an empty selection, I'm afraid I'm going to register the same action twice, where one will just invoke the other with an empty selection, simply by-passing this django check

[Hélène Charpentier]

Replying to Humberto Yances:

Replying to Karen Tracey:

Performing an action on an empty query set should do nothing. Therefore there is no point in calling the action with an empty query set. (If the action did something other than nothing, that would be surprising; enabling such surprises in the admin UI seems like a Bad Idea.) #12281 covers the case of issuing a message that something needs to be selecting before you can successfully perform an action. We should fix #12281 and reject this one.

Actions that don't act on specific items are a fundamentally different

I would not state this in such an absolute way, and preclude users the option to make their own wrong choices…

Limited to django, I'm not particularly experienced, I seldom contribute to django programs. Now in the current assignment we need to import data from external sources (openstreetmap, wubook), and we either need to refresh a subset of our already existing items, or we want to import things from scratch. The code in the two cases is obviously the same. The "import from scratch" we run on an empty selection, and our initial workaround was really terrible, that is remove everything, add a fake new object, select it, then run the action.

I'm looking into the object-tools, and I have several perplexities: one is that it looks quite a bit more work to add them; two is that I need to program my actions elsewhere, while they do fundamentally the same thing; three is that the action I need depends on the table I'm in, it's definitely not a generic tool.

so while we can't activate the action on an empty selection, I'm afraid I'm going to register the same action twice, where one will just invoke the other with an empty selection, simply by-passing this django check

I have the EXACT same issue ; it can seem to be a bad UI practice, but we can have needs that you have not thought about yet. And I agree with the freedom of customization.
Plus, both the doc and community about how to add a button that would do that are not as clear as the doc for Custom Actions.

For beginners, it could allow to get a MVP, something that could be a bad UI practice for you, but at least, something that works.