Allow other modules to extend this module via alterers and hooks

Works like a charm for me. And kudos for updating the documentation; I never think to do that.

Worked for me too, can we get a commit?

This new hook functionality works great! It will be nice to have it implemented in the module directly.

You can grant permission with this patch for new/custom field-permissions. Though hook_field_access works inverted: if not any module denies, then grant. field_access() in field.module will deny access for the first module that returns FALSE.

Off-course it is nice to grant behaviour, but you cannot trust on it.

So my 2ct is to reverse the behavior, and also give the alterer the option to

1. deny access for custom field-permissions
2. un-deny (not grant) access for existing permissions

We could wait until field_permissions_field_access() is almost finished, and then invoke the hook where you can change the field_permission before returning it.

I've committed this with some changes based on #8:

As @ndf mentions, the concept of returning TRUE and short-circuiting out of the permissions check isn't in keeping with the D7 field access model. The model only cares about when you return FALSE.

I've changed the api function to allow you to further restrict access to permissions, but not to attempt to grant new ones.

This means in a scenario like the one originally described, where I wanted to grant a role permission to view a field, but only on the "teaser" view mode, would need to be implemented in the following way:

1. First, figure out how to pass the view mode into this function. (It's not, from what I can tell, part of any of the data that's being passed in right now.)
2. Second, give the ability to view the field to anyone on the at the generic level
3. Third, remove the ability to view the field at the more specific level (view mode, in this example)

Here's an illustration:

Good:

Bad: