I've read the code comments for why flagging is disabled for entities that aren't fieldable and I understand the logic.

However in my tests I've found that this makes taxonomy vocabularies impossible to be flag!

There's no "view" page for a taxonomy vocabulary; it has no view modes and, in fact, Display Suite won't even let you add any. Therefore, the only way to flag a vocabulary would be through the edit form, but the option is disabled because it's not fieldable.

I realize that adding the flag checkbox through Form Alter & API is not as clean as doing it through the Field API so my question is: how badly do we want to support flagging taxonomy vocabularies? Because as it stands, it's just taking up space in the list and isn't actually usable... :)

> Yup. I think the actual fix here might be that we exclude vocabs from being flaggable.

That's what I was going for! It's really just a technicality, like being able to Flag Profile2 types. In general, if an entity is being used as the entity type and another as the bundles (a pretty common pattern), in general we can assume that the "type" entity shouldn't be flagged because they are just there to use the Entity API Admin UI features and aren't meant to be viewed directly, but that's another issue.

Can we change this issue's title and exclude taxonomy vocabularies? Maybe we can have an API function to return entity types that aren't supposed to be flaggable and drupal_alter() it so that contribs can use it too?

This is again a core/EntityAPI thing. EntityAPI adds two properties to entity info that are of interest:

- $entity_info['configuration'] is TRUE if the entity is configuration rather than content, like profile2 types
- $entity_info['bundle of'] is TRUE if the entity is the type of another entity, again like profile2 types.

We use the first to skip config entities, but again, core of course doesn't support this.

> Maybe we can have an API function to return entity types that aren't supposed to be flaggable and drupal_alter() it so that contribs can use it too?

That seems a bit fiddly to me.

As you've said ether further up or on another issue, most custom entity modules will be using Entity API, and if they're config entities they'll set the property that we check.