The workflow-ng integration should only work with nodes of a type, where "per node settings" are activated in the content access settings. Then add an action, which allows one to set custom permissions for content. Add another action, which allows one to revert the settings back to the content type defaults.

Furthermore add an condition, which allows one to check the access control settings of a node. One should be able to select permissions by role (and author). Then the condition should return true if all these roles have access, otherwise false. Find an appropriate label for this condition.

If the action/condition runs with a node of a type, which hasn't enabled "per node settings", show an error by using "workflow_ng_handle_error_msg()".

Comments

fago’s picture

Title: GHOP: add workflow-ng integration » GHOP #126: add workflow-ng integration
add1sun’s picture

Status: Active » Postponed (maintainer needs more info)

Claimed by ezyang.

ezyang’s picture

Assigned: Unassigned » ezyang

Assigning to self.

ezyang’s picture

I'm having trouble understanding why this task is asking me to do what it says. Could you elaborate on the use-cases mentioned in the GHOP task description?

fago’s picture

ok, here is a use case:
Take this tutorial: http://drupal.org/node/156317 - a simple reviewing system. With this actions, it could be easily enhanced. E.g. one could use content access to hide the articles from anonymous users. When an article is published, a content access action is used to enable view access for anonymous users. So it's not possible for anonymous users to view content, which needs work or is under review, but they can read published articles!

ezyang’s picture

In order for users to specify what the resulting permissions for a node will be after the action is invoked, I'm reusing content_access_page(). However, there is no "node" associated with it when a user is configuring the action, so I need to make the function work without nodes; I've created a separate function for this task.

When determining the defaults for view/update/delete, the system checks per node rules and then node types. However, it does not appear the form knows about any of these (a user could specify a form type, but this is not very useful for the form generation, which happens before a user could specify anything like that). There are a few possible workarounds: a multistep form and an AJAX call after a user specifies what node type they want the application to apply to, but this feels like overkill. Would it be acceptable to simply leave all the defaults blank, and expect the user to fill things in appropriately? Also, should we still stipulate, in the action, that the action applies only to one node type, or would this be a check more appropriately placed in conditions?

Thank you!

ezyang’s picture

Here's a snapshot of the functionality I currently have. In the interest of rapid iterations I'd like comments on the patch as it stands right now, before I move on to implement the other parts of the task.

fago’s picture

I like that you are reusing the existing page form, however please improve the comments a bit: Note, that the action configuration form uses this function without $node.

* Then your forgot to add an optional parameter $node to function content_access_page_form($defaults = array().

* Please add the workflow-ng code as separate include file, which is included when the workflow-ng module is active

* You forgot a var_dump in your code.

* @label t('Active node') - why active? Please don't call nodes "nodes" in the workflow-ng UI. workflow-ng uses 'content'

* This code conflicts with the code style:
+ // Make sure defaults array is full
+ foreach (array('view', 'update', 'delete') as $i) {
+ if (!isset($defaults[$i])) $defaults[$i] = array();
+ }

If you want to do this with a short code, you could use

  $defaults += array('view' => array(), 'update' => array(), 'delete' => array());
ezyang’s picture

As far as I can tell, this patch is feature complete! If there is anything extra you would like in the patch, please say so!

Drupal doesn't seem to like *.inc files, so I've uploaded the extra include file as a txt file, rename it to content_access.workflow_ng.inc please!

fago’s picture

Status: Postponed (maintainer needs more info) » Needs work

* I don't like content_access_parse_settings(). The idea to share the settings code is nice, however in this case I wouldn't go this way. The original page settings saving code was simpler and easier to understand. Furthermore the parameters of content_access_parse_settings() aren't really intuitive - so better eliminate this function and don't share this code for both cases. Of course you can still use this function just for the actions/conditions submit handler, which should simplify it a bit.

* Furthermore content access is now stable for quite a long time. Try to don't change code where it isn't necessary!

* So also, please don't add content_access_get_ops(). Imho it's a bit more intuitive to read the old way. So also just use array('view', 'update', 'delete') instead.

* There is no need to add ACL workflow-ng integration to content access. This should go into the ACL module. So you can remove the comments, that this could be added later

* @ // No error, just fail the condition
If the condition is misconfigured, I think it's better to also go with the error.

* '#description' => t('Evaluates to TRUE, if node allows all selected operations for given roles.'),
Don't use "node" in workflow-ng's UI. Use 'content'.

code style:

* It's FALSE not false, also TRUE instead of true. Please correct this.

* it's
}
else

and not
+ } else {

* an if should always have {}
e.g.
+ foreach (content_access_get_ops() as $op) {
+ if (!isset($defaults[$op])) $defaults[$op] = array();
+ }

--->

  foreach (content_access_get_ops() as $op) {
     if (!isset($defaults[$op])) {
         $defaults[$op] = array();
     }
   }

* Including files is usually done in the beginning of a file. Please move this to the top. Furthermore it's not "drupal" to use "dirname(__FILE__)". do it like this one:

include_once(drupal_get_path('module', 'workflow_ng_ui') .'/workflow_ng_ui_render.inc');

* Try to avoid variable names that aren't readable like "$cur_roles".

apart from that, code looks good!

ezyang’s picture

(double post, see below)

ezyang’s picture

Updated. I also took the liberty of updating the docblock comments in accordance with Drupal's coding settings.

fago’s picture

thanks! from looking at the code the patch looks good now :) However, I had problems applying it. Have you created the patch for the latest content access version? Looks like you have used content access 1.2 or so.

Best create it for the the latest code in the DRUPAL-5 branch or the latest development version.

ezyang’s picture

Status: Needs work » Needs review
StatusFileSize
new14.01 KB

My apologies, I thought the HEAD branch was the most up to date one. I switched to DRUPAL-5 and resolved the conflicts. Here is the updated patch.

fago’s picture

Status: Needs review » Needs work

thanks, now it applies fine. However when testing I ran over a problem: The node grants were not applied.

The problem is that the action just configures content access, but doesn't update the node grants. Best just modify the actions to return the node to be saved - that should do it as node grants are updated when the node is saved. Letting workflow-ng save the node makes sure that it is only done, when it's really necessary. As e.g. on node submit the node is saved nevertheless.

Just fix that, then it's ready :)

ezyang’s picture

StatusFileSize
new4.51 KB

Ok. I'm not exactly sure how to test for grants, but I have modified the two action methods accordingly.

fago’s picture

Status: Needs work » Fixed

thanks, committed to 5.x-1.x-dev. Good work :)
Please upload your latest code to the google issue too.

You can verify the grants e.g. with the devel node access module part of the "devel" project.
I've also deleted the content of the unused HEAD branch.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.