[META] Missing access control for base fields

Added #2028027: [META] Missing access control for base fields to issue summary. We need to create similar issues for other entities/fields.

tagging

Updated issue summary.

So what would be the best way to handle that, do it per field, per entity-type?

Imo per entity-type might be a good granularity.

Updated issue summary.

Updated issue summary.

Here's an alternative idea of tackling this issue. This idea depends upon #1994140: Unify entity field access and Field API access.
With that issue in, we may do this:

function user_entity_field_access($operation, $field_definition, $account, $items) {
  if ($field_definition->getFieldName() == 'Name' && $items->getParent()->entityType() == 'user') {
    switch ($operation) {
      case 'view':
        // Do and return something.
        break;
      
      default:
        # code...
        break;
    }
  }
}

Thus, we don't have to create new fieldItemList classes for base fields. Also, it provides a central place to handle all operations access for base fields attached to a spcific Entity, e.g, user.

For a particular base field, e.g., user_name:Name, we can still use $items::access() to check the access.

Updated issue summary.

Discussed how we approach that best with yched - it's a general question on how to best provide custom logic per field instance.

We've not been able to identify what's the best approach right now, but agreed that it would make most sense to move with create per field instance field item list classes for now.

We kind of dislike having the entity type module implementing a hook and obfuscating the default-access logic from the field / field definition as a whole.

Other options discussed have been
- add some method on the entity class that's called by default, but this will lead to ugly switch logic there as well
- provide a way to specify custom access callbacks on the field definition, which then could sit on the entity class but be organized more neatly, i.e. group fields with common access logic to use the same callback
-provide a mechanism to provide separate access logic class and define them on the field definition, analogously to validation constraints.

See comment in #2029855: Missing access control for user base fields

Fixing yoda speak

The API addition that we need from this is in. While this is still a critical bug that we have to sort out, I believe this and the sub issues are now longer beta targets, it doesn't matter when we fix this as long as we do it before 8.0.0.

Can't see reference to 'Block Content' entity in OP - should we have an issue for that too?

@larowlan opened that issue, well spotted that it was missing.

And that issue is apparently not necessary.

All child issues were fixed.