Fixes to permissions

Thanks for the MR @artemboiko! I'm still seeing the links for the operations which the user don't have access on the "Entity Queue" tab on entities, so I'm adding a new commit to fix it.
In the commit I'm checking the access to the url instead of checking the access to the entity operation. That's because the access could had been extended by other modules (like the group_entityqueue for example or custom access requirements) and by checking the access to the url will work properly on all scenarios.

I'm uploading a static patch to apply from composer

Hi @artemboiko the problem with patches from MR is that they are dynamic, they are generated automatically from the MR and the MR can change at anytime. It can lead on your site being deployed introducing untested code, or even the patch not applying without prior notification. There's a big discussion on this topic on the following issue: #3204538: GitLab Merge Requests Unable to Generate Incremental Patch Files

I've moved @akalam's commit into a separate issue: #3451509: Display only the operations the user has access to in subqueueListForEntity

@artemboiko, can you please write some steps to reproduce for this part?

we have a bug with configure user don't have access to this page but still can see link on entityqueue list page

Also, what's the use case for a separate enable/disable permission? Is the general "update" permission not sufficient?

Rerolled for the version 8.x-1.8

> can you please write some steps to reproduce for this part?
"we have a bug with configure user don't have access to this page but still can see link on entityqueue list page"

If a role doesn't get the permission "Administer entityqueue", but it does get the permission to "manipulate" the queue, then users with that role will see the "Configure" action for that queue, however, they can't access the corresponding page to configure it. They shouldn't see the "Configure" operation.

> Also, what's the use case for a separate enable/disable permission? Is the general "update" permission not sufficient?

Is not sufficient, because we could allow them just to edit the queue, so they can alter the order of the elements, add, edit, or delete those items. That doesn't imply configuration changes. However, with manipulate queue permission gives them the ability to "Disable" the queue itself, and we might not give them that permission, which actually does generates a configuration change which would imply a change in the config files and in the repository.

Fixed and updated Merge request.

Now granting "Manipulate all queues" permissions would be equal to granting one by one all "Manipulate ... queue", which means just edit the items in the queue (and doesn't produce config changes); not delete, not enable/disable, not configure.

So this last adjustment also adds the "Delete ... queue" permissions and removes access with just "Manipulate all queues", requiring those specific enable/disable or delete permissions, since those are more dangerous actions for the site and also would produce changes in configuration.

In summary, for example now editor users (non developers) would be able to manipulate the items of a queue without granting them the possibility of disabling or deleting the queue, which is a very common needed use case.

https://git.drupalcode.org/project/entityqueue/-/merge_requests/20.diff patch doesn't apply to latest release 8.x-1.9, so I am uploading the patch re-rolled for this last release version.

I've read through the latest comments and I agree that having access to enable/disable queues through the update permission is problematic.

However, I think it's an advanced enough use-case that we can use the administer entityqueue permission instead of adding a new one. Updated the MR to do that and also fixed a few other things.

Merged into 8.x-1.x, thanks for all the work on this!