◀ Merged tasks: T1300.

This is vaguely tricky because typeaheads may accept different types of tokens (e.g., a mailing list can be CC'd but can not be an owner) and making the UI explain that clearly is probably a little bit of a pain.

(T3309 is somewhat related, in that it touches the same code.)

In our workflow, we never use anything except usernames, but I see your point. But I don't see a technical issue with this... jQueryUI draggable/droppable have a concept of "acceptance", allowing specific elements to be denied. Continuing your example, something like this would address the concern:

• each username element has token type: class="user" or class="list" etc
• assigned to field has accepts only .user class
• cc field accepts any type

It's pretty easy to prevent the drop from happening technically, the problem is making it clear why the field rejected it. Basically, the UI should ideally prevent anyone from ever showing up in IRC and asking "Why can't I a CC into the owners? It usually works!".

If the state just disables or otherwise simply rejects the drop, it's less clear than if we show a message like "Only users can own tasks. You just tried to drop a mailing list, and it didn't work because a mailing list is not a user, so it can't own tasks." but then we need a bunch of strings for each <accept type, drop type> pair and to figure out how to show the message in the UI without turning everything into a mess if, e.g., the typeahead is in a dialog.

can't I a

can't I drag a

This should be marginally easier now that mailing lists are just a special type of user. there is still some UI work but it isn't a different type of token anymore.