Add docs on possible values of $operation in hook_entity_field_access()

Given it a try!

Please review and suggest modifications if required.

Hey Sonal, I'm curious where you got the values 'add', 'edit', and 'delete' from? Looking at the code it's not immediately obvious to me where that's coming from.

hook_entity_field_access() is invoked once inside of https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21..., and passed the $operations parameter from that that method has been given. The documentation there says this will likely be one of 'view', or 'edit'.

This is called once here:

\Drupal\views\Plugin\views\field\Field::access() with 'view' as the operation.

And then here as well \Drupal\Core\Field\FieldItemList::access(), so far the only usages of FieldItemList::access() I've been able to track down thus far have 'edit', and 'view' as the operations.

Were you able to track down example usages of the 'add' and 'delete' argument?

I searched for fieldAccess which is calls this hooks and multiple tests and Views call fieldAccess('view'). Some tests (UserAccessControlHandlerTest) also use edit and delete. It's possible that's all. create access usually has a different way since there's no entity yet.

Note the _entity_access key / relevant EntityAccessCheck uses different names -- it uses view, update and delete but also arbitrary strings.

Fields basically just use view and edit. They have on concept of adding or deleting, since everything happens while editing.

But yes, essentially it's just a string that's passed through to the hooks and method on the field classes. But unlike entity access, were special operations are quite often used, I think that's pretty rare for field level access. I don't think I ever had a use case for that.

Thanks Berdir for the quick answer. I found that fieldAccess $operation is documented with these exact strings you mentioned. And I agree with the original that keeping this docs in one place is a good idea.

+++ b/core/lib/Drupal/Core/Entity/entity.api.php
@@ -1845,7 +1845,8 @@ function hook_entity_operation_alter(array &$operations, \Drupal\Core\Entity\Ent
+ *   \Drupal\Core\Entity\EntityAccessControlHandlerInterface::fieldAccess()

it makes sense to add @see

Added @see reference.

Looks good, not sure a bug

Looks good, not sure a bug

Well, what do I know. A few years ago I would have filed this as a critical issue because it's security related and it's insane that entity access uses update while field access uses edit. That's the kind of thing that leads to security holes.

But that's the old kind of thinking where I was relentlessly chasing security and often choosing security over user/developer experience.

However, the community no longer cares about security as much (proof: #2628870: Access result caching per user(.permissions) does not check for correct user is still not addressed) and that is fine as well so feel free to mark this as a minor feature request. What do I know? What do I care? I wrote my field access hook for Smartsheet and so I am done.

Unfollowing.

Committed and pushed 71ca377 to 8.3.x and 2495e7b to 8.2.x and f01ff77 to 8.1.x. Thanks!