In the entityform_access function, the comments indicate

@param $op
The operation being performed. One of 'view', 'update', 'create', 'delete'

But in the function code, I only see non-standard 'submit' and 'confirm' options. None of the standard API operations are included.

I detected this behavior while working with the RESTful Web Services (restws) module.

CommentFileSizeAuthor
#3 entityform.module.patch921 bytesemmonsaz
#2 entityform.module.patch657 bytesemmonsaz
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tedbow’s picture

The docs for that function do need to be update.

None of the standard API operations are included.

You don't see the standard ones because the are handled by passing $op to user_access

Here

 338   if (isset($entityform) && $type_name && is_object($entityform)) {
 339     if (user_access("$op any entityform", $account)) {
 340       return TRUE;
 341     }
 342     elseif (!empty($user->uid) && $entityform->uid == $user->uid && user_access("$op own entityform", $account)) {
 343       return TRUE;
 344     }
 345   }

There might be a problem with 'create' though. That might be handle correctly if you calling it externally.

emmonsaz’s picture

FileSize
657 bytes

How about equating "create" with "submit"?

emmonsaz’s picture

FileSize
921 bytes

Here's an updated patch that also fixes user id and time issues for programmatically submitted entityforms

tedbow’s picture

Status: Active » Needs work

Please keep this patch just for this issue.

Cruz3r’s picture

I too stumbled on this issue.

View and Delete operations work with the user_access call,
but Update doesn't since the permission is 'edit any entityform'.

a.vakulenko’s picture

Issue summary: View changes

I just put this in entityform.module:

if ($op == 'update') $op = 'edit';