Reworking Workflow Fields module to use CCK Private Fields [#596686]

Hi markus, I am the author and maintainer of Workflow Fields (http://drupal.org/project/workflow_fields) which hides or shows CCK fields based on the workflow state. I'm considering rewriting the module to use your extensible infrastructure, but I need a few functions that I'm not sure your module offers today:

* Ability to show a "view" rendering of a field on the node form. This is useful when making fields read-only for some users but still visible.

* Ability to treat the node author as just another user, not a superuser to whom the restrictions don't apply.

* Ability to extend the field restriction mechanism to non-CCK fields (title, body, etc.)

These are functions that exist in Workflow Fields and that I would like to keep. It would mean changing your module's core to handle them, which I'm ready to work on if you agree to the general concept.

Comments

Comment #1

markus_petrux CreditAttribution: markus_petrux commented 6 October 2009 at 07:41

My main problem is that I'm currently pretty busy trying to finish a project that has been taken me one year already (porting meristation.com to Drupal 6 from a propietary non-open source CMS), so I think I won't have the time to review patches that change the current behavior of this module.

For what is worth, here's another feature request in a similar situation: #583558: Add another privacyStatus - Hook

However, thinking a bit about your use case, maybe you can implement all those features in Workflow Fields in a way that's compatible with CCK Private Fields.

The heart of this module comes from a recent extension in CCK itself ( #514452: Add new argument $node to content_access() to enhance the context for hook_field_access() ), and the fact that content_access() in CCK grants access to fields except when a hook_field_access() implementation returns an explicit FALSE.

Note that if a hook_field_access() implementation returns TRUE, CCK will just ignore that if another hook_field_access() implementation returns FALSE:

function content_access($op, $field, $account = NULL, $node = NULL) {
  global $user;

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

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

In regards to "Ability to treat the node author as just another user, not a superuser to whom the restrictions don't apply":

The hook_field_access() implementation in CCK Private Fields returns TRUE in this case, so any other module has the chance to return FALSE to tell content_access() access is denied. For example, it is still possible to use Content Permissions module (part of CCK itself) to deny access to any field, even for the node owner.

In regards to "Ability to show a "view" rendering of a field on the node form. This is useful when making fields read-only for some users but still visible":

hmm... this one involves hook_field_access() for 'edit' operation, which is something not covered in CCK Private Fields. So I'm not sure how this feature could be integrated here. Maybe this could be implemented by a separate module that implements "read only" access permissions?

In regards to "Ability to extend the field restriction mechanism to non-CCK fields (title, body, etc.)":

I'm not sure this is possible. We can do this for CCK Fields because CCK uses content_access() everywhere a field is about to be displayed, but this is not the case with node data owned by other modules, including node module itself. Everyone can render the node title with no checking of any additional access control to that field.

That being, said I would be happy to review patches to extend CCK Private Fields, but I'm afraid I won't be able for a while. :(