Create a hook_entity_access() with the same features of cores hook_node_access(). We may also want to implement entity_entity_access() just like core's node_node_access() and auto generate permissions, but I'll leave that for another issue.

CommentFileSizeAuthor
#4 1382252-hook_entity_access.patch3.57 KBboombatower
#3 1382252-hook_entity_access.patch3.56 KBboombatower
#1 1382252-hook_entity_access.patch2.97 KBboombatower

Comments

boombatower’s picture

boombatower commented
Assigned: Unassigned » boombatower
Status: Active » Needs review
StatusFileSize
new 1382252-hook_entity_access.patch2.97 KB

I found and used http://drupalbin.com/17312 from davereid for the basis of this code as it seems like a solid approach.

Status: Needs review » Needs work

The last submitted patch, 1382252-hook_entity_access.patch, failed testing.

boombatower’s picture

boombatower commented
Status: Needs work » Needs review
StatusFileSize
new 1382252-hook_entity_access.patch3.56 KB

Missed some stuff.

boombatower’s picture

boombatower commented
StatusFileSize
new 1382252-hook_entity_access.patch3.57 KB

Comment fixes.

Status: Needs review » Needs work

The last submitted patch, 1382252-hook_entity_access.patch, failed testing.

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Needs work » Closed (won't fix)

!?
entity_access() to helps to access not-unified access-apis of the various entity types. The entity api module does not extend any existing APIs though and I don't see how this should or could properly work.

boombatower’s picture

boombatower commented

I can respect your scope definition so this simply needs another module, but as for how this would work..it does...and that was even from a core patch....lost. It is identical to the proven hook_node_access().

boombatower’s picture

boombatower commented

I mean without access control what is the point of entities? I'm not sure how anyone is using them without this. Having a single callback is quite when you only have one module controlling an entity, but doesn't do much good in real world applications. I am unsure where to put this...making a separate module seems like quite a waste especially since a large majority of people will need/want both. Already had planned a relation integration.

I'd like to understand why you believe this doesn't or couldn't work. Additionally, I'm curious why it falls outside of entity scope since it leaves the access callback in tact and only provides hook_access() if a callback is not specified. Based on core documentation:

access callback: As in hook_menu(). 'user_access' will be assumed if no value is provided.

Node uses node_access() for such a hook_menu(). In fact it almost seems backwards. Shouldn't entity module set the default access callback to entity_access() which then uses permissions and hook_entity_access() which can have custom rules? Then it acts just like nodes...is a) actually usable, b) flexible.

Seems like right now it's just designed backwards which may be why this whole thing is confusing.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Status: Closed (won't fix) » Active

@fago: kindly ask you to read #1186320-10: Get rid of the node grant system
is this a point to reconsider this issue?
can you comment if you see a better way to implement access control for individual entities?
are there other obstacles that should be solved?
(and: is there anyoune who does like the grants system? =;-)

your comment is much appreciated.

fago’s picture

fago
Primary language German
Location Vienna
commented
Status: Active » Closed (fixed)

I don't have any ideas on that right now, I'd appreciate a general entity-access solution including listings though. However, we won't be able to apply this new API to existing core APIs so I don't think it's a good fit for the entity API module right now.

If you come up with something nice, I might be convinced. Else, I'd be happy if this evolves as a separate project too.

boombatower’s picture

boombatower commented

which implies this is not nice...even though it works perfectly...mimics the already accepted node api...and mimics a d8 patch for entity access....that's where I'm lost

agileadam’s picture

agileadam
Location Maine, USA
commented

So what's the scoop on this folks? I really need a way to override an entity_access() check that entityreference is using. Basically I need to allow a user entity reference to be viewed as a "rendered entity" but I don't want to give my users "View user profiles" access.

scott.whittaker’s picture

scott.whittaker commented

I also need this to hide flagged taxonomy terms based on user permissions.

boombatower’s picture

boombatower commented

Anyone building a site more complex then show everything to everyone needs this...which is why it ought to get some attention.

damien tournoud’s picture

damien tournoud commented

If anything happens in this issue, I would recommend adopting the entity access system of Drupal Commerce that supports:

  • unified create / view / list / update / delete access control
  • per-bundle access control
  • "own" permissions

The code lies in three functions (commerce_entity_access(), commerce_entity_access_permissions() and commerce_entity_access_query_alter) in commerce.module.

boombatower’s picture

boombatower commented

By adopt you mean merge into entity? That seems like something that ought to have been it's own project from the start. Short of someone stepping up an doing so, the current patch is usable.

nessunluogo’s picture

nessunluogo commented

At least, did you implement this function in current stable version?

I'm developing a module to grant access to commerce_order entities by role, and I can't get it work.

luksak’s picture

luksak
he/him
commented

@Giovanni Perdicaro: Did you make progress on this? I want to implement access checks depending on role and order billing address country. Did you solve the issue for the role part? What would need to be done to accomplish this?

I bumped into this project:

http://drupal.org/sandbox/dereine/1284426

I have not looked at it. Is it the same thing we are discussing here?

Also this might be interesting, although this is not supposed to solve the problem:

drupal.org/project/accessapi

luksak’s picture

luksak
he/him
commented

Also I need to be able to specify access by order state.

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented
Status: Closed (fixed) » Closed (won't fix)

Changing to "won't fix" as that is more accurate per #6 and #10.