Introduce entity permission providers

@bojanz in #53 you wrote:

New feature (resolving #9 from this issue):
#2977231: EntityPermissionProvider should provide per-bundle view permissions

but the issue summary still says:

Note that view permissions are never per-bundle cause we have no way to enforce it, we'd need query access for that (ala node access).

I wasn't confident enough to remove that from the issue summary, so could you perhaps have a look to be sure it should be removed?

Looks like the MR already contains the relevant code:

  /**
   * Whether per-bundle permissions should be provided for the 'view' operation.
   *
   * Note that self::$bundleGranularity must also be TRUE in order for this
   * setting to be taken into consideration.
   *
   * @var bool
   */
  protected $viewBundleGranularity = FALSE;

(https://git.drupalcode.org/project/drupal/-/merge_requests/2912/diffs#10...)

I just created ✨ Add "view $bundle media" permission Active where exactly that is needed, but I can't tell if it's still an issue. I think it isn't?
Thanks!

Next steps: Solve #85 and #98

We're currently writing a new permission module: https://www.drupal.org/project/entity_access_by_reference_field →

For that reason, we had a look into the different hook_entity_access implementations in core:

• node
• media
• taxonomy term
• user

all of them, but node, use "update", only node uses "edit".

Also the documentation at https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21... says

The operation that is to be performed on $entity. Usually one of:
"view"
"update"
"delete"

but the code in the MR uses "edit" instead of "update". That's quite confusing and we think there should be a consensus on one correct term!

Here's the current implementation from the MR:

    /**
   * @var array
   */
  protected $permissionMap = [
    'admin' => NULL,
    'collection' => NULL,
    'view any published' => NULL,
    'view own published' => NULL,
    'view own unpublished' => NULL,
    'edit any' => NULL,
    'edit own' => NULL,
    'delete any' => NULL,
    'delete own' => NULL,
    'create' => NULL,
  ];

So we'd stronly suggest to change "edit" to "update". Also the method names use "update", like getUpdatePermission()

My bad, the operation is always "update", but the permission is "edit" (which is still quite confusing).

@Core maintainers: Any chance or way to push this forward? Seems this lost traction again, but other important issues are postponed on this (like ✨ Move permission "view any unpublished content" from Content Moderation to Node Postponed ) and that is still something weird in core, because in the current state users are permitted to view a node they can edit and can't save the node they edit, because URL alias checks view access! See 🐛 Non-admins cannot save unpublished nodes with path alias Active

So I think for the permission system this is really important to unblock the other issues. How to proceed?

bhanu951 → closed merge request !9140

bhanu951 → reopened merge request !9140

bhanu951 → closed merge request !2912

bhanu951 → changed the visibility of the branch 2809177-introduce-entity-permission-11.x to hidden.

I'd be willing to give this another go, but with what I've learned in the past 6 years since I commented here I'd have to revisit if what was being discussed back then is still relevant now. I have since dropped my dependency on contrib Entity API and created new mechanisms in Group to deal with access.

Some of these are permission providers and access control handlers, but as services that can easily be decorated. Ultimately, I'd like to see if we can do something similar in core but that would be a huge endeavor. Either way, most of the discussion happened years ago and perhaps the first step should be to check how much of the discussion is still applicable today.

Made changes against head and fixed phpstan issues and tests.

Please read my latest comment.

One thing I for instance think is a huge foot-gun is putting the specific permission methods on the interface. Right now it's getUpdatePermission, getDeletePermission, etc. but we cannot know all of the possible entity operations in a site. In Group I fixed this by having a method that takes an operation and returns a permission.

Either way, I don't think we should introduce yet another handler that no-one else can alter properly due to how handlers work in core right now.