This patch adds the operator 'access' to the hook_nodeapi hook. it is invoked after hook_access and allows a module to overwrite the hook_access result.
hook_nodeapi('access') gets invoked as node_invoke_nodeapi($node, 'access',$op,$access), where $node is the current node (if any), $op is the requested operation("view","update","delete","create") and $access is the "opinion" of hook_access (either allow(True), deny(False), NoOpinion(NULL)). Each module can either Allow the operation (return TRUE), deny (return FALSE), or don't care (return NULL). The operation is allowed if at least one module returns TRUE and none return FALSE i.e. any deny will overrule an allow. If all modules return NULL then the result of hook_access is used. The default behavior node_access will not change unless a module implements hook_nodeapi("access").
The "access" nodeapi allows the creation of custom access control modules. I have used this patch to create a module which allows more granular access control of og.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | hook_file_142995_3.patch | 25.89 KB | drewish |
| node_nodeapi_access.patch | 1.64 KB | mikew |
Comments
Comment #1
Tobias Maier commentedno new features for drupal 4.7 and 5.0 doesn't accept new features, too
it will not apply against drupal head
Comment #2
mikew commentedthanks tobias,
any clue what i should do with it? Can it be submitted for 5.1/6.0? Is there similar functionality planned?
and what kind work does the code need?
-Mike
Comment #3
coreb commentedMoving out of the "x.y.z" queue to a real queue.
Comment #4
drewish commentedthis is older but i'm going to mark it as a duplicate of http://drupal.org/node/91709 because that got a bit more traction.
Comment #5
drewish commentedi have no idea how that patch got attached but combine that with using the wrong issue number and i'm looking like a dork. teh correct one is: http://drupal.org/node/143075