Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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);
}
Comment | File | Size | Author |
---|---|---|---|
#3 | Untiaaatled.png | 335.39 KB | bakr |
#3 | Capture4343.PNG | 78.13 KB | bakr |
Comments
Comment #1
bakr CreditAttribution: bakr commentedAs you can see, the above code took some time for me to rave it through. apart from the time spent on studying the api.
Comment #2
salvisWhat 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?
Comment #3
bakr CreditAttribution: bakr commentedthe 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
Comment #4
salvisThank 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.
Comment #5
bakr CreditAttribution: bakr commentedYou 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..
Comment #6
bakr CreditAttribution: bakr commentedThis ACL api functions worked fine for me