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

Ok @akalam thanx, btw you can use patch from MR in gitlab :)

We have a link to the patch in Code > Download > Patches > https://git.drupalcode.org/project/entityqueue/-/merge_requests/20.patch

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 issues: 🐛 GitLab Merge Requests Unable to Generate Incremental Patch Files Active and #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces →

Aha got it, makes sense.
Thanx for info @akalam

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

@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.