ECK entity access alter

7.x-3.x has a completely revamped permissions system, that is 100% hook driven, so anyone can have a say on whether an action is allowed, or not, on an eck object. Reviews of that system would be greatly appreciated, and I am keeping people informed on the changes in this issue: #1374150: Better Permissions . After we write the update from 2.x permissions to 3.x, we can easily back port all the functionality.

Hi. Is there any chance we will have better perms in 2.x now?
Thanks

Hello,

I am implementing support for OG group/group content and I have the UI/processing functions ready but I am unable to alter the entity access.
I would need something like:

drupal_alter('eck__entity_access', $access, $op, $entity_or_bundle, $account, $entity_type_name);

Is there any chance of updating the access function to allow other modules to hook in or do I have to patch the module locally?

Thanks,
Mihai

Actually, this will not work with drupal_alter as we are limited to 4 params, and the $entity_type_name will not be passed over.

Getting back on this, I had to patch the access check in order to work with Organic Groups/permissions https://www.drupal.org/node/2133899

The way I altered the access:

drupal_alter('eck__entity_access', $access, $op, $entity_or_bundle, $entity_type_name);

Here's a patch.
I've wrapped all variables in $context to fix the problem from comment #5.

Would you like to also call an access alter entity_type specific?

It would be a good idea to aim for something similar to existing entity modules -- see Profile2 for example. It would also be named hook_eck_entity_access() rather than being an alter hook -- again, see that module.

Lastly, any hooks need to be documented in the api.php file.

+ added hook_eck_entity_access
+ updated the api

Any chance of someone testing this?
Thanks.

Access in eck is terribly messy. I believe the solution in 3.x is much cleaner, so I wonder if we should use this issue to backport the 3.x solution. I do not want to bring the separate permission implementation formulated in 3.x (I think I am going to make that a separate module) but just the cleaner and accessible eck_access() implementation.

I've applied the patch at #10, created my own eck permissions with hook_permissions and used the hook_eck_entity_access defined in the patch. It's been working like a charm since.
Thanks

Just tested the patch in #10:

It works fine, thanks! I was able to implement a hook to grant & restrict access.

However, this does require the permission 'eck view [entity type] [bundle] entities' to be granted, or the eck__multiple_access_check() will always return false & override anything you set in the hook.

Whilst this is fine, it doesn't allow you to restrict access by default then grant access selectively - your hook would have to return FALSE to deny access, which wouldn't allow further hooks to grant access.

I think you could move the following:

$access[] = eck__multiple_access_check($permissions, FALSE, $account);

To replace the final return false:

// Only grant access if at least one module granted access and no one denied
// access.
if (in_array(FALSE, $access, TRUE)) {
  return FALSE;
}
elseif (in_array(TRUE, $access, TRUE)) {
  return TRUE;
}
// If no hooks granted or restricted access, fall back to default check.
return eck__multiple_access_check($permissions, FALSE, $account);

I'm not sure if that's suitable or any better though!

I ran into the same problems as #15, and applying the changes suggested did the trick.

Ditto - here's a patch including smaz's alterations.

Patch again without the debug

Reroll of #18.

#19 works great for me. Thanks a lot!
When it will be released?

Additionally we should check the access informations in the Views' links (edit and delete). Here's a patch including these checks.

Updated patch.

Hi, I'm using the latest patch (#22) with the edit/delete own entity from https://www.drupal.org/node/1374150 and it perfectly works (see https://www.drupal.org/node/1374150#comment-11681713)

Works for me as well, tested the Views edit link as well.

It's a little strange though because I needed to grant a user "edit [type] entities" as well as implement the entity access hook. Is that by design?

Edit: Granting access to edit an entity works on the form, but not views.

Updated patch so that the Views links (edit/delete) use the same access check as the form.

@djdevin, Quick review for #25

+++ b/views/handlers/eck_views_handler_field_link_delete.inc
@@ -40,4 +36,4 @@ class eck_views_handler_field_link_delete extends eck_views_handler_field_link {
-// @codingStandardsIgnoreEnd
\ No newline at end of file
+// @codingStandardsIgnoreEnd

+++ b/views/handlers/eck_views_handler_field_link_edit.inc
@@ -29,4 +26,4 @@ class eck_views_handler_field_link_edit extends eck_views_handler_field_link {
-// @codingStandardsIgnoreEnd
\ No newline at end of file
+// @codingStandardsIgnoreEnd

We should remove all these lines from the patch and we need to end with new line at end of the file.

#25 Works fine, meaning that there is a access control hook. However, the hook execute multiple times in my entity. I am not sure if something related to my entity configuration or is the patch.

I have not test this out on a clear ECK environment.

Attached is an updated patch. #25 wasn't applying cleanly to the latest dev. It also removes the "No new line..." stuff.

@caschbre This should be in "Needs Review" ?

Yep, missed that. Thanks @darol100.

Attached is an updated patch for the latest 7.x-2.x-dev branch. I've been using this in production on several sites for the past year.

Access checks in the views handlers have been added in #2449619: Views link handler access control. This is a reroll of #37 against 7.x-2.x HEAD with the handler changes removed.