General ticket for talking about how development is going and submitting of patches in the leadup to 0.1
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | customreports.module.patch | 5.81 KB | j_ten_man |
General ticket for talking about how development is going and submitting of patches in the leadup to 0.1
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | customreports.module.patch | 5.81 KB | j_ten_man |
Comments
Comment #1
a_c_m commentedFurthering j_ten_man and my email discussion, we need to be able to add an additional check when trying to view / edit the custom report nodes. We didnt want to force using a specific node - so we have a problem :
I've gone down the road of option 2, as using hook_access() seems most logical / nice. However were not using hook_node_info(), instead still using your node_type creation code in the settings submit which i've added to.
I *think* in order for us to be able to use hook_access we need to override the node_type's ->module when selecting a exsisting type - which the code now does. It will also set it back to what it was before if we change away from that type. Additionally, i think in the hook_access (and perhaps other hooks like that) we should pass the data onto the original parent module, if it exists. Code to almost do that is in our hook_access.
While i think this might work, its starting to feel quite hacky, perhaps your option 1 is better.
a_c_m
Comment #2
j_ten_man commentedI figured out how to work with hook_node_access_records() and hook_node_grants() to restrict access to reports. It adds overhead to the drupal system by using the node_access table but usually most sites won't have a large number of custom reports...
By the way, I found the answer to this in the Pro Drupal Development book!
Comment #3
j_ten_man commentedHere's the patch with the newest code for reports permissions :). Still waiting on CVS access.
Comment #4
a_c_m commentedcommitted, also now works with http://drupal.org/node/273893#comment-1694938 if you enable tokenSTARTER module
Comment #5
a_c_m commentedWelcome snufkin to the dev team.
snufkin has suggested we use a hook/theme functions instead of trying to use tpl files, hes going to be back porting the module to D5 and getting a working version together.
Comment #6
snufkin commentedHey there.
I committed some stuff to the Drupal-5 branch, for now I removed the need for the input filter and the PHP code support, but I think the rendering is done in a way that it will be easy to plug in extra input/output.
Comment #7
snufkin commentedClosing the issue as we have worked out the releases by now.