Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
To prevent confusion, the clone operation should only be visible when the current users has the right permission.
Proposed resolution
Permissions should be checked in entity_operation hook.
Remaining tasks
none
User interface changes
none
API changes
none
Data model changes
none
Comment | File | Size | Author |
---|---|---|---|
#32 | 274337-32-clone-operation-shows-regardless-of-permission.patch | 772 bytes | AshM |
Comments
Comment #2
jmeijer CreditAttribution: jmeijer at SWIS commentedComment #3
AsadKamil CreditAttribution: AsadKamil at Valuebound commentedPatch 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.
Comment #4
donaldp CreditAttribution: donaldp commentedThis 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?
Comment #5
abu-zakham CreditAttribution: abu-zakham as a volunteer and at Vardot commentedI think we should check entity access instead of check permission on entity type.
Comment #6
abu-zakham CreditAttribution: abu-zakham as a volunteer and at Vardot commentedComment #8
abu-zakham CreditAttribution: abu-zakham as a volunteer and at Vardot commentedComment #9
Shawn DeArmond CreditAttribution: Shawn DeArmond as a volunteer commentedto run tests
Comment #11
awm CreditAttribution: awm commentedpatch #7 does not work but patch #1 works.
patch #7 removed the clone operation for all
Comment #12
dpi#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
Comment #13
jibranPatch looks great can we add a quick test, please.
Comment #14
jibranComment #15
John Cook CreditAttribution: John Cook at Creode commentedRTBC++
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.
Comment #16
Anas_maw CreditAttribution: Anas_maw as a volunteer commentedThe 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')
Comment #17
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedI will switch to use #2 the first patch.
Comment #18
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedUpdated the patch
Comment #19
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #20
John Cook CreditAttribution: John Cook at Creode commentedI'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.
Comment #21
John Cook CreditAttribution: John Cook at Creode commentedAs the patch in #18 does not apply to alpha2, I've uploaded a compatible version of the patch.
Comment #22
afi13 CreditAttribution: afi13 commentedRe-roll of patch from #18 for latest dev.
Comment #23
dpiThe extra permission added by 18 is redundant:
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.
Comment #24
dpiComment #25
vpeltot CreditAttribution: vpeltot at Niji commentedRe-roll patch & remove
as @dpi suggested.
Comment #27
vpeltot CreditAttribution: vpeltot at Niji commentedCommited !
Thanks.
Comment #29
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedTo note that access is not a permission
Fix the issue on "AccessResult->orIf"
and that will go with
We will run into some issue like the following
#3037114: Fix issue of unable to edit menu links
Comment #30
slefevre1 CreditAttribution: slefevre1 commentedWe 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?
Comment #31
JasonLuttrellI am also seeing permissions issues with this module in 1.0-beta4.
Comment #32
AshM CreditAttribution: AshM commentedThis fixed the issues for me on 1.0-beta4.