Field Permissions UI

We didn't *completely* punt; we have this in field.module:

/**
 * Determine whether the user has access to a given field.
 *
 * @param $op
 *   The operation to be performed. Possible values:
 *   - "edit"
 *   - "view"
 * @param $field
 *   The field on which the operation is to be performed.
 * @param $account
 *   (optional) The account to check, if not given use currently logged in user.
 * @return
 *   TRUE if the operation is allowed;
 *   FALSE if the operation is denied.
 */
function field_access($op, $field, $account = NULL) {
  global $user;

  if (is_null($account)) {
    $account = $user;
  }

  $field_access = module_invoke_all('field_access', $op, $field, $account);
  foreach ($field_access as $value) {
    if ($value === FALSE) {
      return FALSE;
    }
  }
  return TRUE;
}

I haven't looked at D6 field access functionality but I'm sure there is more to it. :-) As a trivial detail, we should de-$op-ify.

What we have in there is small but consistent and should be working pretty fine - we'd need to write tests :-)
What is not possible right now is stuff like 'limited visibility' that profile.module offers : view my own, edit my own...

That would imply passing the $object as a param to the access hooks - this also implies that the module that implements this '$op my own' stuff knows how to recognize who's the 'owner' of the object : assume $object->uid ?

If Field API, or hooks it calls, need access to owner information, ISTM we should extend field_attach_extract_ids() to return it.

Perhaps that would be false generality. The "owner" would be assumed to be a Drupal user id, so it would pretty much always be $object->uid. However, since we already have field_attach_extract_ids() it would seem odd not to use it.

We should put uid in the list of return values from field_attach_extract_ids() based on its frequency of use relative to the other returned values. I'd either put it last or just before 'cacheable'.

Agreed on field_attach_extract_ids().
Sidenote : shouldn't we move field_attach_extract_ids() to return a structured, keyed array of ['key' => value] pairs ?.

I'm not sure I understand whether you want an 'owner key' => 'uid' entry in hook_fieldable_info(), though.
'id key', 'revision key', etc... are precisely a workaround for the current lack of consistency between $node->nid, $user->uid, $term->tid, ... Ideally, we should (some day... ?) move to unified, predictable keys : $obj_type . '_id', etc... If there's *one* property where we can assume consistency ("owner is $object->uid"), then we should be happy :-)
Ok, that's nitpicking. 'owner id' should be fine..

I'm not sure about de-opifying field_access(). The $op in field_access($op) is not like the one in pre-D7's nodeapi($op). It's the name of the grant you're checking. Most of the time, the same mechanism will be used to retrieve the grant, so it's not bound to end up in separate switch branches that are better off as separate functions with their specific sets of arguments. node_access($op) has not been de-opified in D7. Unless it does, I think we're more consistent where we are now.

I could go either way on assuming $obj->uid vs. having extract_ids() do it. I agree it would be great if we had consistent names for primary id properties across objects.

The reason extract_ids() returns a numerically-indexed array and not a hashtable is so this is possible:

  list($id, $vid, $bundle, $cacheable) = field_attach_extract_ids($obj_type, $object);

Otherwise, our code will look like:

  $ids = field_attach_extract_ids($obj_type, $object);

  if ($ids['id']) { ... }

which I think is uglier. Not a deal breaker, though.

Unfortunately, the list() syntax does not work with hashtables:

% php -r 'list($a,$b) = array("a"=>"a", "b"=>"b"); print "$a, $b\n";'
, 

Tagging to collect some permissions related stuff I see bubbling up

Marked #501404: Field Permissions in Core as a duplicate of this.

So what is a state of the issue?
https://drupal.org/node/1928882 New entity field access control and hooks
https://drupal.org/node/1903124 Entity types now have a generic way to deal with permission granularity

It looks like we have no UI just now

Hi,
when could this module be used in Drupal 8? It would be a great featue in D8! I am not good enough to develop this modul.
Thanks for every answear.
Andy

+1

let's postpone that and properly title

It will be nice to have field permit UI included in core ASAP

Any interest in making this happen now that D8 is out ? Please consider updating this to a major issue.

+1 on this. I feel it should be (should have been) part of core anyway, not handled by a contrib module (that is not D8-ready).

+1

If you need this, look into how you can help make it happen. "+1" voting alone does not make things happen.

Instead: Come up with a plan: what needs to happen, what needs to happen first? Can you or your company commit resources to this effort? Would you be able to sponsor a developer who does have time and expertise? etc.