Description

After updating to head this morning I noticed that I was unable to delete items in the administrator via the delete dropdown action (and confirmation). I was able to track the issue back to [12525]. Specifically, the introduced check looks for 'index', which will not be present when coming from the delete confirmation page:

Notice that it sets 'index' equal to 0 in delete_confirmation_data. This is not what happens for real. In fact, when you confirm you want to delete objects, 'index' is never set in the post data. The fact that 'index' is set to 0 in this test is what caused this test to pass way back when 12525 actually happened.

So, I don't know if index SHOULD be set in the post data when the objects are actually deleted, or if the test is incorrect. Some more info on how to proceed from someone who knows WAY more about this code than me would be awesome :-)

Oh, no... there was definitely a problem before the patch. The patch makes how we're differentiating between action POSTs and list_editable POSTs more explicit (and it works). In doing so, it also reveals why we actually need to be even more explicit to cover cases where users might intend to launch an action, but do a list_editable submit, or vice-versa. So no: the patch is fine, it just needs to do a little more.

Think I have something that works, but you're absolutely right - we need to get some up-to-date tests written so this doesn't come back up.

Removing 'index' from delete_confirmation_data in test_model_admin_default_delete_action fails on the current revision [12812] and passes with the patch. I started a blank project which included the admin. I created a new user and then selected it to be deleted with the admin action. Inspecting what is actually posted in each step in Firebug I see:

I have another patch that covers cases where the user might change list_editable elements and hit the action 'Go' button, or select an action to execute and hit 'Save' (which will be there for 'list_editable' fields). In our current state BOTH interactions are handled in the same form, and both sets of changes get handled - an ambiguous and confusing situation that this patch fixes.