Closed (fixed)
Project:
Content Access
Version:
6.x-1.2
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
21 Jan 2010 at 03:17 UTC
Updated:
21 Jan 2010 at 05:19 UTC
Just noticed that while this function *does* clean up table content_access correctly, it fails to clean up the acl schema properly ...
For whatever reason (I don't have time to investigate it) the statement
if (module_exists('acl')) fails to return TRUE... I don't think that it's really necessary to have this test in the first place but I've only given it a quick look. I believe it's superfluous because the module dependencies would have been called out long before this point ... however, commenting out this module test causes the right behavior:
/**
* Deletes all custom per node settings, so that content type defaults are used again.
*/
function content_access_delete_per_node_settings($node) {
db_query("DELETE FROM {content_access} WHERE nid = %d", $node->nid);
// Clear the cache.
content_access_per_node_setting(NULL, $node, FALSE);
// Delete possible acl settings
// if (module_exists('acl')) { <=== Comment this line out
foreach (array('view', 'update', 'delete') as $op) {
$acl_id = content_access_get_acl_id($node, $op);
acl_delete_acl($acl_id);
}
// } <=== Comment this line out
}
Comments
Comment #1
sjz commentedTook more time to understand this - Ignore (part of) the base message ... I took more time to look into the interaction and where there are remnants in the
acl schemaafter the "reset to defaults" takes place.The mechanism here:
... shows the reason for the artifacts left in the
acl schema.node_access_acquire_grantscauses re-insertion of the information in the database. It's unnecessary but harmless. I still suggest that Content Access should clean up completely when resetting to defaults.I'll still stand by the notion that calling
module_exists('acl')is superfluous in the original post - but it *is*, indeed, working properly.