Clone operation shows regardless of permission

Patch applied successfully,
Thanks.
Now the check permissions functions are working.If admin has not given permission to authenticated user for clone,then authenticated user cannot clone with its article.If admin has given permission then authenticated user can clone.

This appears to work OK. I'm not sure why it was not included in the recent alpha release as having "Clone" options all over the place that only lead to access denied seems a bit odd.
Maybe it breaks some of the modules tests or needs some test cases?

I think we should check entity access instead of check permission on entity type.

to run tests

patch #7 does not work but patch #1 works.
patch #7 removed the clone operation for all

#8 contains a typo in the operation: "close" instead of "clone"

Also, there is no clone operation.

Added a patch which adds a clone operation, then makes use of this operation when building operations list and clone routes.

Changing to normal since this can be misleading/confusing for users without permission

Patch looks great can we add a quick test, please.

RTBC++

I needed this applied to alpha2, so I re-rolled #12 for it as it wouldn't apply. I've added the patch for alpha2 as a .txt file so it won't get tested.

The patch in #12 will break menu item edit page. And give the following error:
Argument 1 passed to Drupal\Core\Access\AccessResult::orIf() must implement interface Drupal\Core\Access\AccessResultInterface, null given, called in /core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php on line 105 in Drupal\Core\Access\AccessResult->orIf() (line 314 of core/lib/Drupal/Core/Access/AccessResult.php).

The issue comes from this line in patch
->setRequirement('_entity_access', $entity_type_id . '.clone')

I will switch to use #2 the first patch.

Updated the patch

I've tested the patch in #18 and it works as expected; the "clone" option is not present in the operations menu if the user does not have clone permissions.

The problem with the menu item edit pages is not present in the new patch.

Because of this, I'm setting to RTCB.

As the patch in #18 does not apply to alpha2, I've uploaded a compatible version of the patch.

Re-roll of patch from #18 for latest dev.

The extra permission added by 18 is redundant:

 '_permission' => 'clone ' . $entity_type_id . ' entity',

Because entity_clone_entity_access added by the patch already checks for it.

Patches since 12 aren't going to make a difference for user 1, as it has permission for everything. You have to fix the root cause of the menu problem as described by #2743379-12: Clone operation shows regardless of permission

My recommendation is that the core issue for Menu Link Content should be fixed here: #3016038: Unrecognised entity operation passed to Menu Link Content throws exceptions, The patch from 12 is still the patch to go with.

Re-roll patch & remove

'_permission' => 'clone ' . $entity_type_id . ' entity',

as @dpi suggested.

Commited !
Thanks.

To note that access is not a permission
Fix the issue on "AccessResult->orIf"
and that will go with

+          '_permission' => 'clone ' . $entity_type_id . ' entity',
+          '_entity_access', $entity_type_id . '.clone',

We will run into some issue like the following
#3037114: Fix issue of unable to edit menu links

We recently discovered that anonymous users could clone entities on our site(!), but when I went to apply patch #25, I found that it didn't apply because it was already rolled in.

So how do we prevent anonymous users from cloning entities on our site? Aside from disabling the entity_clone module?

I am also seeing permissions issues with this module in 1.0-beta4.

This fixed the issues for me on 1.0-beta4.