It's neither strictly a bug nor a design intent - it is an accidental by-product. Until this time last year, actions could not be applied to collections - and any such methods would be ignored by the reflector. Then we introduced
the idea of 'collection contributed actions' - which works well. (This is documented, but there is also a short video here:
http://www.screencast.com/t/5qEFjVja . The side effect is that if you write an ordinary (non-contributed) action with a collection param (as you have) then it is recognised, but there is no mechanism
for providing the collection. My recommendation is that you move the action onto a service such as:

I have just moved the method into a service and registered the service as a contributed action. As expected I now get an action either when displaying a single group or when displaying a collection (of users. However, that action still does not
provide a find mechanism that allows me to pick one or more users to add to the group when triggered from the single group action menu.

I have just moved the method into a service and registered the service as a contributed action. As expected I now get an action either when displaying a single group or when displaying a collection (of users. However, that action still does not provide a
find mechanism that allows me to pick one or more users to add to the group when triggered from the single group action menu.

- When you display a standalone collection of Users, you should now get the action appearing on a menu and you should be getting check boxes on the standalone collection. First you select the users you want to add, then invoke the action, which
should show you the number of Users you selected. You should then be able to Find the Group, and add them. If this is not working, please advise.

Undesigned behaviour:

- Because this particular action takes a Group parameter, then it is also going to be contributed to a (single) Group object, on its Action menu. However, invoking the action is then going to ask for a collection of users and there is (currently)
no way to specify that collection from there. This is known behaviour.

We either need to make the second case work (somehow) or make it not show up as an action.

To put it another way: the only way you can currently apply an action to a collection of objects, is from that collection of objects.

From a user's point of view, I believe that not having the second case work is a restrictive limitation and would suggest this gets added to your list of potential future features that people could vote on.

I would certainly find it a hugely beneficial enhancement, as it would enable me to add useful redundancy, (2 ways to achieve the same goal from different but appropriate places). It would also allow easier bulk actions. Again in my example...I
could assign 'n' users to 'm' groups in one action rather than 'n' or 'm' actions.

I forgot to say that I think that, given that the second case doesn't work, you can suppress the contribution of the action to the Group object by adding a [NotContributedAction(typeof(Group))] to it. That way the action should only appear on the collection
of Users.