Better Permissions

Edit own [bundle]:

Use case:

Site with car models.
Each car model has a gallery.
Any user might add new pictures to the gallery, and EDIT / REMOVE his own pictures, but not other user pictures.

To achieve something like this, some glue code + an interface for managing each "car gallery" pictures would do a great gallery for D7 (there isn't anything like this in the moment).

I had actually considered adding that in the initial permissions patch, but didn't want to clutter up the permissions interface or be too presumptuous regarding where you wanted to go in terms of permissions. I agree that it would be good to have this functionality and can say that it should be fairly easy to implement.

Yes, the commented out code was the beginning stage of adding in the permissions, but what you mentioned regarding the uid makes sense. I hadn't added in the code to check for the user level permissions, but that probably wouldn't be too complicated.

I wonder if it would make sense to add a configuration page for eck that allows you to control the level of permission control. You could control the granularity for example. Say 4 levels or something that by checking them off it adds the relevant permissions to the permissions table:

Basic: the main permissions, edit all, view all, delete all, etc...
Per-type: edit entities, view entities, etc...
Per-bundle: edit entities, etc...
user: edit own entities, view own entities, etc...

The only reason I mention this is that once you have a few entity types created each with a few bundles, the permissions start to get overwhelming and if you don't need all that fine grained control then it would be nice to disable some of it.

I'm not sure if this is the place to ask but ....
Will be possible for a user to change the ownership of his Entity or other user to request ownership of that Entity. Changing ownership to require some Conditions and Actions.
looking for something like this - http://drupal.org/node/1434396

@mogop:
If you define an entity type that has a 'author' (user) parameter then yes you can certainly change it. At the moment I don't think this is possible through ECK's UI, but with further development of the behaviours that fmizzell is working on I'm sure it will be. Currently it does integrate with rules through the entity api so the author CAN absolutely be set/changed that way.

In terms of 'request ownership' functionality, this sounds like its a fairly specific type of functionality and not so general. I'm not a maintainer of the module, but I think its fairly safe to say that it won't be built into the module. However, I can think of several ways, depending on your scenario, of achieving this.

In your game site example from #1415644: Request Ownership or Giveaway Ownership (assuming you're using the commerce module) you could add an entity reference field to a product which references the particular game item (lets say a 'character' entity defined through ECK) you want to sell. Before the sale the character entity obviously has you as the 'author' (using ECK terms here). Upon checkout/payment you could invoke a rule that switches the author of the 'character' entity to the user that bought it. It would probably be a fairly complicated rule just in the sense that I believe you would have to loop through the line items of an order in the main rule, invoking a secondary 'rule component' that would then check the product type of a particular line item, check that the entity reference field exists on the line item's product reference, and then based on those conditions passing, set the uid(author) of the entity to the order:owner.

In the example you give regarding google+ pages regarding transferring ownership when a user is deleted. I could see this working with perhaps the relation module. You could define an 'ownership' relation that would associate a user to an entity. Then again have a rule that fires when a user account is deleted that would load all its 'authored' ECK entities and then loop through them, again calling a secondary rule component that would in turn check for any 'ownership' relations and if found change the entity uid to the user associate in the relation.

So there are undoubtedly solutions to what you are asking for, you just need to be a little creative, because as far as I know there isn't anything out of the box that can do this.

fmizzell, I don't feel positive about that.
The central place for managing permissions on Drupal is the only place users should look to when they need, and I hope one day ECK becomes a standard module for every site builder.

Having an exclusive UI for managing permissions wouldn't be much welcoming, but I guess it's understandable if that means more control/features.

I think the there should be a main set of permissions governed by the standard drupal permissions system. Namely:

• Administer Entity Types
• Add Entity Types
• Edit Entity Types
• Delete Entity Types
• Administer Bundles
• Add Bundles
• Edit Bundles
• Delete Bundles
• Administer Entities
• Add Entities
• Edit Entities
• Delete Entities
• View Entities

When it comes down to getting fine grained at the entity type, bundle type and Author(owner) levels then having an ECK defined UI for managing permissions is needed. The drupal permissions ui will just get unmanageable as more entity and bundle types are created, however granularity is needed.

I would suggest adding an eck_access_ui module that ships with ECK and when enabled adds in access granularity into the existing ECK UI. For example on the 'admin/structure/entity-type/' you could have an access tab that lists administer, create, update, delete, etc permissions for each bundle type that has been defined for that entity type. Similar permissions along with viewing for all entities of those bundle types could also be included at this level. On the bundle specific level you could have an access tab that can be used to grant entity owner specific access, etc for entities under that bundle type.

I was playing around with the code for something like this, but ran into a roadblock with hook_entity_info where you define the CRUD and access. I created a function that could implement a hierarchical type function call for access, but couldn't get it to fire using the access callback in that hook. By default it is supposed to supply the operation type, etc, but instead it was just passing me the 'adminster site' permission or something like that. Not sure what the problem was?

On a side tangent, I was also thinking it would be interesting to take advantage of rules conditions components similar to how views allows you to fire rules action components. So for each of these operations at the entity level you could give the site admin, or whomever has administration privileges, the ability to select conditions components from a list that should be checked when a user is attempting that operation on an entity. This would allow for immense flexibility. One example that I would like to take advantage of would be granting edit access to a particular entity for a user that has a relation to it. I could think of endless possibilities for this, it would be amazing!

acrazyanimal's suggestion seems like a good balance between ease of use and granularity.

@fmizzell, absolutely. I think this kind of approach for other modules would make drupal much easier to use, generally.

I am a code developer, but I have a lot of contact with tech savvy / non savvy editors and site builders, so I have a lot of feedback from them in UX aspects. Simplifying interfaces and providing an alternative "advanced" one always helps, and it's one of the things people miss when coming from other systems with more polished UX like Wordpress and Silverstripe.

So yes, I think the distributed permissions UI would be best.

Oh, let me know if you need any help with code, testing or UI design.

@fmizzell: The main con I see with a single permission UI is that you might just be moving the clutter from the drupal permissions page to a separate page with potentially equally as much clutter. However, your idea regarding ajaxifying the whole thing could be interesting. Potentially with the right workflow and display that allows you to hide the bulk (ie collapsible field sets) I could see it being manageable. I imagine something along the following lines (if you can follow my example below):

+ Add new top level permission (this would essentially just be a drop-down of entity types)

  + Organization +  
  |                   |
  |                   |   Corporate  -  
  |                   |                  |
  |                   |                  + Owner  -
  |                   |                  |            | 
  |                   |                  |            +  delete, update own Corporate Organization entities (corp member)
  |                   |                  |            |
  |                   |                  |            + add new "owner" level permission
  |                   |                  |
  |                   |                  +  Add new Corporate Organization entity (corp member)
  |                   |                  |
  |                   |                  +  view any Corporate Organization entity (authenticated)
  |                   |                  |
  |                   |                  + Add new "bundle/entity" level permission
  |                   |
  |                   + Not 4 Profit  - (permissions hidden, click to reveal)
  |                   |  
  |                   + Government - (permissions hidden, click to reveal)
  |                   |  
  |                   + Update own Organization entities (gov members, n4p members)
  |                   |  
  |                   + update, delete any organization entities (Org admin)
  |                   |  
  |                   + Add new "Entity Type" level permission
  |
  + Member (permissions hidden, click to reveal)
  |
  +   Jobs         +  
                      |   
                      +   Opportunities (permissions hidden, click to reveal)
                      |   
                      +   Looking (permissions hidden, click to reveal)
                      |  
                      + Add new "Entity Type" level permission

@acrazyanimal, there is still the matter that every user naturally goes to the general permissions page to manage permissions. A simple tip there, saying that there is another interface for more granular permissions would help.

Right I guess the example isn't super self explanatory.

So what I have above is essentially what a user would see when they go to the "separate access module" enabled UI page. The example shows what an already configured site might look like. Initially, on a fresh site however, all the admin would see would be a single Add new top level permission select box. In the example if you follow a line down you see a Add new * level permission which I guess would be another select box whose options would be all the kinds of permissions that can be added at that level plus the option to add a sub-level. Everything above those select boxes are permissions/sub-levels that have already been added. For example under Organization the Corporate, Not 4 profit and Government entries are sub-levels based on the Organization bundles. There could be additional bundles under Organization, but they aren't displayed because the admin has not added them using the Add new "Entity Type" level permission select box.

The Update own Organization entities (gov members, n4p members) entry above is a permission that was added, or rather a grouped permission I guess. I'm not sure this makes sense, but I thought it would save time and space if the admin could select multiple operations for a given permission. In this case the permission is role based and granted to 'gov members' and 'n4p members' roles. This could easily be extendable through hooks as well. So that additional access functions provided by other contrib modules could be called. They would simply show up in the select box at the level they apply to.

Each level would be wrapped in a field set and would be collapsible so that you can hide the clutter you don't care about at the moment.

Anyway, its an idea. One that would be complicated to implement, but I think it would also be very admin friendly.

In addition to the above, I see all of that sitting on top of a simple access function whose parameters match that of the entity api's entity_access($op, $entity_type, $entity = NULL, $account = NULL). Does anyone know if the 'entity_access' function is fully implemented in entity api?

Why not have the ability to select which permissions are available as part of each bundle, much like the current properties are dynamically changed.

This then means the default permissions remain as per a new install, but then each created entity has a UI to say which permissions are shown on the standard permissions interface, this new UI can be quite complex as it would only be seen very few times.

This way the main permissions page only gets complicated if the site wants entities with different permissions, but by default just the standard ones show. This would also then be no different to installed 10 different modules with their own permissions.

Example,
I create four bundels: e1, e2, e3, and e4

I select that the permissions view, add, and modify are available for e1
I select that the permissions view, add are available for e2
I select that the permissions view, add, and modify own are available for e3
And no permissions for e4.

The standard permissions page then only shows:
...Standard generic ECK permissions...
...Default permissions for all ECK bundels...

e1
- view e1 entry
- add e1 entry
- modify e1 entry

e2
- view e2 entry
- add e2 entry

e3
- view e3 entry
- add e3 entry
- modify own e3 entry

e4 is not listed as no permissions were requested

Any updates on "own" permissions for eck.
Is there an alternative solution as mentioned above, i.e. using rules to assign an author id / uid to the created entity?

still no updates?

we now have to drop eck from our project and implement the entities by ourself! we would really appreciate the implementation of the "own" permissions in eck!

Indeed what fmizzell says is true. You'll have to go it alone either way. What you can do is create a custom module that adds the extra functionality to your eck defined entity through hook_entity_info_alter. You can define an access callback through that or even your own implementation of the crud. I believe you should be able to do this. Another option might be available if you implement a custom property behaviour for a uid... not sure off the top of my head if that can be done, but it may be another avenue to success. Anyway, I think you can accomplish it in conjunction with ECK and tt may save you some time over implementing your own custom entity module.

I actually just got started working on a sandbox project for custom entity access and will port the same principles over to eck once I'm finished.

Thank you for the patch, it works!
You forgot to patch the views handlers too, just add this conditions:

eck_views_handler_field_link_delete.inc:
&& !user_access("eck delete own {$entity_type}")

eck_views_handler_field_link_edit.inc
&& !user_access("eck edit own {$entity_type}")

Just changing the name back to be more descriptive.

Is it possible to make it working on current 7.x-3.x-dev branch?

Yes, and now i read that it's already planned:

4. And better permission management

Nevermind, I'll wait.

Hi fmizzell, 1st of all, many thanks for this module. I'm following the development and I will test later today or tomorrow morning and leave some feedback.

Meanwhile... the status "need review" on drupal is used to review submitted patches (just to let you know if you are not aware of that :))

anytime I try to add a new permission, i get the following error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'oid' cannot be null: INSERT INTO {eck_permissions} (type, oid, permission) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => admin [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => Edit own contacts ) in DBObject->save() (line 87 of /**********/sites/all/modules/contrib/eck/eck.classes.inc).

It looks like form is missing a parameter (db_insert_placeholder_1).
In the ECK permissions page I can see two text input (User/Role and Permission).
Is it a bug or I'm missing something?

Hi fmizzell, sorry to just reply now but have a personal issues to solve... I test the permissions and everything seems to work fine.

Is there a way to know when a release of the 7.x-3.x will be availlable for production ?

Sorry to open this back up but am I missing something. I am working off latest 3.x-dev and I get the

view entity:myeck|myeck|*
update entity:myeck|myeck|*
delete entity:myeck|myeck|*

To work just fine but

create entity:myeck|myeck|*

and any of the own permissions are not working. Should the own perms be written the same

view own entity:myeck|myeck|*

??

You are right, they work fine without the granularity. I will add a issue for the create case and feature request for the own granularity.

Is it possible to override the access callbacks ourselves in hook_entity_info_alter or some other hook? I tried but cant seem to "overpower" the eck_access callbacks being used as proposed here. Do you have an example if it is possible as I would really like to add some custom access callbacks.

Is there anyway that better permissions can be applied to the 2 branch?
3 does not seem to be very usable at the moment.

Patch for eck 7.x-2.0-rc4

Thanks for submitting this patch.

I'm getting the error when viewing an ECK form
Notice: Undefined property: Entity::$uid in eck__entity_access() (line 821 of

And when I'm editing the ECK entity
Notice: Trying to get property of non-object in eck__entity_access() (line 821 of

I checked line 821 and it looks like $entity_or_bundle only contains the name of the form. No other values.

As reported in #2495527: 3.x Roadmap: Unsupported, do NOT use 7.x-3.x is now abandoned, so this issue still pertains.

I've needed this for a project I'm working on at the moment. Based on #56, I've created a patch for 7.x-2.x based on the patch in #52.

I re-ordered the permissions list, so that the ones with View all & View own etc. are all together.

   $perms_info = array(
     'eck administer' => 'Administer',
-    'eck add' => "Add",
+    'eck list' => 'View List of',
+    'eck add' => 'Add',
     'eck edit' => 'Edit',
     'eck delete' => 'Delete',
-    'eck list' => 'View List of',
     'eck view' => 'View',
   );

For the permissions, I made it so that it will only create own & all options for View, Edit and Delete - you don't need Add all, Add any for example.

function eck_permission() {
       $entity_perm_info = $perms_info + array('eck view' => "View");
 
       foreach ($entity_perm_info as $op => $op_label) {
-        $perm_name = "{$op} {$entity_type->name} {$bundle->name} entities";
-        $perms[$perm_name] = array(
-          'title' => "{$op_label} {$entity_type->label} {$bundle->label} Entities",
-        );
+        // If the op is administer, add or list we only want one permission.
+        if ($op == 'eck administer' || $op == 'eck add' || $op == 'eck list') {
+          $perm_name = "{$op} {$entity_type->name} {$bundle->name} entities";
+          $perms[$perm_name] = array(
+            'title' => "{$op_label} {$entity_type->label} {$bundle->label} Entities",
+          );
+        }
+        // Otherwise, add separate permissions for managing all or just own entities.
+        else {
+          $perm_name = "{$op} {$entity_type->name} {$bundle->name} entities";
+          $perms[$perm_name] = array(
+            'title' => "{$op_label} any {$entity_type->label} {$bundle->label} Entities",
+          );
+
+          $perms[$perm_name.' own'] = array(
+            'title' => "{$op_label} own {$entity_type->label} {$bundle->label} Entities",
+          );
+        }
       }
     }
   }

For eck_multiple_access_check(), it seems the dev version has a start on checking for own permissions, but hasn't been used anywhere. I've renamed $b_own to $is_author, which I think is a little clearer on what the variable is. The current version also looped through the permissions twice if checking against own permissions, which it didn't need to do.

-function eck__multiple_access_check($perms, $b_own = FALSE, $account = NULL) {
+function eck__multiple_access_check($perms, $is_author = FALSE, $account = NULL) {
   if (!isset($account)) {
     $account = $GLOBALS['user'];
   }
   foreach ($perms as $perm) {
-    if (user_access($perm, $account)) {
-      return TRUE;
+    // Check for ownership permissions.
+    if ($is_author){
+      if (user_access($perm . ' own', $account)) {
+        return TRUE;
+      }
     }
-  }
-  if (!$b_own) {
-    return FALSE;
-  }
-  // Check for entity author field and user ownership permissions.
-  foreach ($perms as $perm) {
-    if (user_access($perm . ' own', $account)) {
+    // Check normal permissions.
+    if (user_access($perm, $account)) {
       return TRUE;
     }
   }
+
   // The user does not have any of the supplied permissions.
   return FALSE;
 }

Finally, for the access it will check if the $entity_or_bundle->uid property is set & matches the current user.

@@ -847,6 +860,8 @@ function eck__entity_access($op, $entity_or_bundle, $account, $entity_type_name)
 
   // Check the relevant permissions. If an entity or bundle is provided, use
   // that to get the bundle-specific permissions and check those too.
+  global $user;
+  $is_author = FALSE;
   $permissions = array(
     'eck administer entities',
     "eck {$op} entities",
@@ -854,6 +869,11 @@ function eck__entity_access($op, $entity_or_bundle, $account, $entity_type_name)
   if (isset($entity_or_bundle)) {
     if (is_object($entity_or_bundle)) {
       list(, , $bundle_name) = entity_extract_ids($entity_type_name, $entity_or_bundle);
+      // Check if the current user is the author of this entity.
+      if (isset($entity_or_bundle->uid) && $entity_or_bundle->uid == $user->uid) {
+        $is_author = TRUE;
+      }
+      
     }
     else {
       $bundle_name = $entity_or_bundle;
@@ -864,7 +884,7 @@ function eck__entity_access($op, $entity_or_bundle, $account, $entity_type_name)
 
   // @todo should auto-load entity author here.
 
-  return eck__multiple_access_check($permissions, FALSE, $account);
+  return eck__multiple_access_check($permissions, $is_author, $account);
 }

As I say, work based on patch in #52 so thank you @EuroDomenii.

I had a look at supporting 'List own X entities', but if you grant 'View all X entities' but only 'List own X entities' and not 'List all X entities', the resulting table will still show all entities, rather than just the current's users entities. That's outside the scope of this patch, I believe. It also mimics core in that you can grant Edit / Delete own for certain content types, but only grant access to the Content listing page which will show all content the user has access to.

This doesn't change the name of the current 'View X entities' permission, only the label, so existing permissions should all remain the same.

Please let me know your thoughts?

Also, I'm using the patch in #1969394: ECK entity access alter to add a permissions alter hook. Attached is the same patch as above, but can be applied AFTER patching with the following patch so both work:

https://www.drupal.org/node/1969394#comment-9464017
https://www.drupal.org/files/issues/eck-eck_entity_access-1969394-9.patch

Hopefully helps both issues along.

Hi,

Do you have permissions for any entity bundle entities permission ? Any users could edit/delete entities, that is terrible.

Do you have any better permissions for operations on CRUD ? Node has specific permissions on each bundle's CRUD.

Thanks

A few notes.

Shouldn't this be "eck manage"? So we stick to the same naming convention.

foreach (EntityType::loadAll() as $entity_type) {
    $perms["manage {$entity_type->name} properties"] = array(
      'title' => "Manage {$entity_type->label} Properties",
    );

The other issue has a patch that implements a hook for eck entity access.
https://www.drupal.org/node/1969394
Should we finalize that one first, then continue here, or the other way around?

I'm currently using
https://www.drupal.org/files/issues/eck-eck_entity_access-1969394-22.patch
+
https://www.drupal.org/files/issues/eck-own-permissions-with-access-hook...

And the edit/delete own entity works as expected.

+1 for including on a new ECK stable version.

I've one question: what if the bundle/entity doesn't have the Author property enabled?

Attached is an updated patch against the latest dev.

Note: The patch in #63 does not apply cleanly if using the patch from #1969394-28: ECK entity access alter. Here is a patch that can be applied *after* #1969394-28: ECK entity access alter.

Minor tweaks (e.g. correcting a typo.)

Rerolled plus removed the @todo comment before the last code change.

Rerolled #68 against latest dev.

Lets see what testbot says.