There are certain instances in the web development process when you are being encouraged to implement access control practices that fulfill none of the criteria. That happens if, say, you are going to attach permissions to certain nodes of the same material type, or in case certain users (who have similar roles) should be granted permissions to review a particular material. To have this type of functionality implemented, one needs to make use of ACL API.
Thus, we are going to install the following modules
ACL is the module which is expected to supply us with API so that the lists of permissions could be created. The module lacks user interface and is only utilized to cater to other modules’ needs.
Content Access allows for managing the permissions that are attached to certain material types.
Now we will skip through some major functions employed for ACL operation. So that a new permissions list might be created, the following function is implemented (see below):
acl_create_acl($module, $name = NULL, $number = NULL)
We observe that the above function’s taking three arguments, i.e. the module name, the newly created ACL name and number. Returned by this function is the newly created ACL’s identifier. Adding the material to the list is performed with use of the function below:
acl_node_add_acl($nid, $acl_id, $view, $update, $delete, $priority = 0)
This function operates the following way: the dedicated material is assigned with or revoked the selected permissions (view, edit, delete), while use of the previously created ACL being made. Adding a new user to the newly created list is performed with the following:
acl_add_user($acl_id, $uid)
Where $uid is the user identifier.
Thus far, we have examined some major functions that are implemented to create a new ACL, and at this point a number of practical tasks might be performed to help develop the relevant skills. The first one suggests granting to some user ($uid), who has a “Customer” role, a review permission that’s attached to some sort of material ($nid). We start with revoking the role’s display right permission per selected type material (Content Access module being used for that). To ensure the permission per the material will be granted to a certain user with a “Customer” role, we, next, write the following:
// Create a new ACL.
$acl_id = acl_create_acl('your_module_name', 'your_access_name');
// Provide access control to a node based upon an ACL id.
acl_node_add_acl($nid, $acl_id, 1, 0, 0, 0);
// Add the specified UID to an ACL.
acl_add_user($acl_id, $uid);
// Node access grants for rebuilding.
node_access_needs_rebuild(TRUE);In the above example we were using node_access_needs_rebuild function so as to rearrange the permissions. To get the whole thing going, we make sure the Drupal’s permission system has duly been taken into account. Hence, we are adding the following:
/**
* Implementation of ACL hook hook_enabled()
*/
function id_acl_enabled() {
return !id_acl_disabling();
}
/**
* Implements hook_disable().
*/
function id_acl_disable() {
id_acl_disabling(TRUE);
}
/**
* Remembers if we have disabled access.
*/
function id_acl_disabling($set = NULL) {
static $disabling = FALSE;
if ($set) {
$disabling = $set;
}
return $disabling;
}Not all users with “Customer” role have got the privilege to view the materials, whereas they are only getting displayed to that user who has received a proper access permission from us.
There exist, at the same time, functions that are used for removing users and materials from an ACL, and they are also capable of deleting the list itself. Let us skip through them:
acl_delete_acl($acl_id) removes ACL due to its identifier.
acl_node_clear_acls($nid, $module) removes all ACL from the material.
acl_node_remove_acl($nid, $acl_id) removes the selected material out of the ACL.
acl_remove_user($acl_id, $uid) removes user out of the ACL.
As we have seen, the skill of utilizing ACL is quite handy, particularly, in the instances when you are into creating custom access permission lists.