Define an Enum for entity operations

Hmmmm... I love the idea of an Enum, but there's def. a question of extensibility. Enums can implement interfaces, so perhaps there's some way to typehint that, and some sort of trait or static method implemented by the Enum can validate the operation? Is that crazy or too clever?

Been thinking of something similar recently so glad to find an existing issue :)

Definitely a +1 for Enums, we can use interfaces too as @bradjones1 says to typehint access() calls, etc.

I can't tell you the number of times I've written edit instead of update in an entity access control handler or test and lost $time to these magical strings.

I'm going to slightly retitle this as I think Enums are the obvious pick here, we already have enums replacing constants in core with FileExists.

So if I understand this correctly, we'd define two interfaces, EntityAccessOperationInterface and FieldAccessOperationInterface.

We'd then have in core an enum implementing each one, EntityAccess and FieldAccess, so we'd have EntityAccess::Edit, EntityAccess::Create, etc.

A contrib module could then define something like:

enum MyModuleEntityAccess implements EntityAccessOperationInterface {

  case Clone;
}

And since it implements the interface, code can pass MyModuleEntityAccess::Clone to the entity access check API.

And for BC, we change the parameter types to EntityAccessOperationInterface|string.

Yes.

#4 - 100%

Oh one other thing - the enums should be backed, as the access system still needs to pass string operations when invoking the various access hooks.

(Converting those to take enums will be a whole other issue to deal with the BC.)

Tagging as it would be good to get maintainer approval on the approach before starting work.