Allow a given field to be restricted to some entity types

Makes sense. We have similar feature which restrictions actions to certain triggers.

is object_types alterable? the trigger asociation is alterable and thats good; it lets is provide a simplified UI for the majority use case but lets modules get fancy if dev knows what he is doing.

Well, in the case of actions/triggers the association is just a GUI hint. The app does not enforce restrictions. Since nothing about the field definition is alterable today, we have no time to get into that now. Lets RTBC as is.

I see a test that an instance cannot be added to an object type forbidden by the field. Shouldn't there also be a test that an instance can be added to an object type allowed by the field? I added one.

The testbot should be fixed, so let's wait for the test results.

This is green: http://qa.drupal.org/pifr/test/26706

Hm. I can see why this is needed. The lack of an alter() hook though does strike me as potentially problematic. For example, Node Comment module probably wants to also have a comment body field, and will have to duplicate a bunch of code to do it.

However, this is pretty edge-casey, and this will smooth out the UI for the 99.999% of people who aren't doing things like that. So, committed to HEAD.

This does not cause Drupal to cease to function, and is therefore not critical. Downgrading.

I have started an email thread. Very productive: Barry pointed me to this issue as the place where that piece of code was born (I simply assumed it was there since the beginning so I did not run annotate, sorry) while Damien and yched fixed it up nicely which I am posting here.

Reopening because the restriction is way too restrictive: it does not allow adding any new entities to an existing field if the restriction is already set. Ick! I am close to call this critical.

So what does #16 mean exactly? That you can't modify the allowed entities subsequently?

Yeah, that's the problem.

sweet, new drupal wtfs. Always wanted to know why we couldn't replicate the body in other entities, but I can see the reason from an end-users UI perspective. Is there any negative to removing the lock if we alter this manually? There doesn't appear to be any negatives in the code.

For interested parties, this was the update that we used to alter the field "field_featured_image", followed by a devel cache flush:

$field = db_select('field_config', 'c')->fields('c')->condition('field_name', 'field_featured_image')->execute()->fetchObject();
$field->data = unserialize($field->data);
$field->data['entity_types'] = array();
drupal_write_record('field_config', $field, array('field_name'));

Big plus one for making this a configurable option in the field settings. Happy if you could not reduce only increase the allowed range of entities to keep it as simple as possible.

[edit]
Note that this thread refers to object_xx, this was renamed to entity_xx
Also you can not use field_update_field($field) as this throws an exception if you change the entity_types value.

Just noticed this trying to build a field type that would only be allowed on a specific entity type (node) because it has side-effects on the carrying entity (publish/unpublish, in that case). In that specific case, I guess, this means one will have to just emit a warning in the UI.

Still, even without an alter hook, it would be nicer if there was a way to define entity_types in hook_field_info() as a default instead of hardcoding them to array() in field_create_field(). That will have to be bumped to 8.x, I'm afraid.

In Drupal 8.0.x, fields seem to be restricted per entity type. I could not find a relevant change record or issue, but viewing the db of a Drupal 8 installation and playing with the admin interface, I feel confident that the issue here is fixed.