It would be very great to see this integration happen.

If we can get the whole api exposed in rules gui and tokens, that is really going to bring a whole usability and flexbile functionality to the modular drupal platform.

For the time being, I am using execute php blocks to call ACL api as follows:

// $object_form_x_nid		= $referenced_parent_node->field_nid_of_recent_assignment[0][nid];
$subject_ownership_entry_nid	= $node->nid;

$Recent_Assignee_uid		= $node->field_ownership_to_uid[0][uid];
$Active_Assignee_uid		= $referenced_parent_node->field_assign_to_uid[0][uid]; 

$assignee_old    =  user_load( array( 'uid' => $Recent_Assignee_uid ));
$assignee_new  =  user_load( array( 'uid' => $Active_Assignee_uid ));

if ($Recent_Assignee_uid == $Active_Assignee_uid)
{

         // ------------------------------------------------------------------------------
        //  Grant Access to NEW Assignee
        //  Create/update an 'EDIT' ACL entry for this 'Ownership-Entry' 
        //  ----------------------------------------------------------------------------
        // Definition of function::  function acl_node_add_acl($nid, $acl_id, $view, $update, $delete, $priority = 0)

        $acl_edit_id = acl_example_get_or_create_acl_by_prefix_nid($subject_ownership_entry_nid, 'edit');
        
        // Grant EDIT Access to new Assignee
        //=========================
	acl_add_user($acl_edit_id, $Active_Assignee_uid);
	acl_node_add_acl($subject_ownership_entry_nid, $acl_edit_id, 0, 1, 0, 0);
                node_access_acquire_grants($node);
 }
else
{

        // ------------------------------------------------------------------------------     
        // Revoke Access to Recent Assignee
        //  Create/update an 'EDIT' ACL entry for this 'Ownership-Entry' 
        // ------------------------------------------------------------------------------

        $acl_edit_id = acl_example_get_or_create_acl_by_prefix_nid($subject_ownership_entry_nid, 'edit');
        
                // Clear ACL Entry for OLD Assignee
                acl_delete_acl($acl_edit_id);
                acl_remove_user($acl_edit_id, $Recent_Assignee_uid);
           
              //   acl_add_user($acl_edit_id, $Active_Assignee_uid);
             //   acl_node_add_acl($subject_ownership_entry_nid, $acl_edit_id, 1, 0, 0, 0);
        
       node_access_acquire_grants($node);

}

CommentFileSizeAuthor
#3 Untiaaatled.png335.39 KBbakr
#3 Capture4343.PNG78.13 KBbakr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bakr’s picture

As you can see, the above code took some time for me to rave it through. apart from the time spent on studying the api.

salvis’s picture

Title: ACL and RULES » ACL and Rules

What is the purpose of your code?

What would you want to do with Rules? How would you want to do it? What's needed in ACL to make it happen?

Let's discuss first. Then we'll need a patch for D7, including documentation and probably tests, too. Then we'll need people who test it, and finally we can backport to D6.

Are you prepared to put some serious work into this?

bakr’s picture

FileSize
78.13 KB
335.39 KB

the above code was a snopshot or a rules which mainly served the following purpose:

The whole point is the ability to programatically be able to grant/revoke certain permission to users on certain nodes. this differs from giving them a permenent role or a permanent permission.

I do not want to use virtual roles or introduce new temporal roles.

Partially, the following module is serving my purpose:
http://drupal.org/project/nodeaccess_userreference

But the problem with the above module is that it operates in static access grants which are set at cck field level.

What if I wanted to remove that permission automatically from that node in case it goes through different workflow ..

The possible answer is to use the workflow fields access helper module, which in essence gives you access control on the field level rather than node level, that is, more granular and fine.

The problem and need arises more in the following scenario:

and NodeX is workflow enabled

-- I am using the workflow module + workflow field access

-- We have nodeX and nodeY
nodeY is having a nodereference pointing to NodeX

-- Certain node type (nodeX) is subject to workflow (WorkflowX)

-- The node travels through different workflow state, and naturaly inherits different permissions from the workflow access module per each workflow state.

Now observe:

-- nodeX is a parent, and nodeY is a child, as a one-to-many relation.
-- Permission to 'Edit' nodeY should go side-by-side with the permission applied to its parent from the workflow module
-- As soon nodeX leave certain workflow state, I am setting up a rule to clear reset the ACL on all child nodes
-- Equally, vice-versa, As soon as NodeX gets pushed back to the same workflow state, I want all child nodes to be equally affected and to allow editing again,

I hope this clarifies better.

------------

I am not a php developer, hoped to better enhance this module, rather, I use lasso middleware from lassosoft.com

with it I was able to develop a new dashboard that interacts with workflow fields access module

see the snapshot, I do not mind sharing the source-code of the lasso scripts.

The project which i work on is a helpdesk application in addition to automating many complex bussiness workflows for different node types...

1) I am already using the user

salvis’s picture

Status: Active » Closed (won't fix)

Thank you for your explanation. I must admit I don't really understand what you're doing and how ACL could fit better into this complex system. The goal of ACL is to provide a general purpose API. What you're doing seems to be a very specific, custom-tailored workflow, that can probably not be implemented without a certain amount of custom programming.

If you find some general-purpose (!) glue code between ACL and Rules that can be explained and documented in a way so that more than a hand-full of people will be able to use it readily, then I'm definitely interested.

At this point I can't see any of this and I'm closing this issue for now. Please reopen if you see something along these lines.

bakr’s picture

You are right, it is a specific requirement.

though i am happy with the existing acl module.

it is only interesting how advanced things can go.

My Salues..

bakr’s picture

This ACL api functions worked fine for me

$nid = $node->nid;

$this_wf_state = $node->	field_current_wf_state[0][value];

$approver_1	=	$node->field_hidden_1st_approver[0][uid];
$approver_2	= 	$node->field_hidden_2nd_approver[0][uid];
$approver_3	= 	$node->field_hidden_3rd_approver[0][uid];

$field_mgmt_approval_level	= $node->field_mgmt_approval_level[0]['value'];

if      ($field_mgmt_approval_level == '1')
	{
		$Active_Assignee_uid		= $approver_1; 
	}
else if ($field_mgmt_approval_level == '2')
	{
		$Active_Assignee_uid		= $approver_2; 
	}
else if ($field_mgmt_approval_level == '3')
	{
		$Active_Assignee_uid		= $approver_3; 
	}


// ------------------------------------------------------------------------------
//  Grant Access to NEW Assignee
//  Create/update an 'EDIT' ACL entry for this 'Ownership-Entry' 
//  ----------------------------------------------------------------------------
// Definition of function::  function acl_node_add_acl($nid, $acl_id, $view, $update, $delete, $priority = 0)

$module_name = "acl_example";

$acl_edit_id = acl_example_get_or_create_acl_by_prefix_nid($nid, 'edit');


if ($this_wf_state == "Under Approval (Mgmt)")
	{
	
		// CLEAR all relevant current node & /user associations with this ACL entry: "$acl_edit_id"

		acl_remove_all_users($acl_edit_id);
		
		// ADD all node associations with this ACL entry

		acl_node_add_acl($nid, $acl_edit_id, 0, 1, 0, 0);
		
		acl_add_user($acl_edit_id, $Active_Assignee_uid);


	}
	
		
// Gets the list of node access grants and writes them to the database
node_access_acquire_grants($node);