Isn't hook_node_access() the proper way to handle this requirement? <br><br>I just wrote a node access module that assigns nodes to subdomains (affliated sites using <a href="http://site.example.com">site.example.com
</a>, <a href="http://site1.example.com">site1.example.com</a>, and so on).<br><br>Some users have the permission 'create X content', other have the permission 'create subdomain content', which allows them to create content type X only if they are creating or editing a node that belongs to a specific subdomain.
<br><br>I would imagine the OGR would use a similar approach. Some users would have a universal 'create' privilege. Others would have 'create only in my groups' privilege. <br><br>I may be very wrong, but it seems like changing roles temporarily is a hackish way to do something that is more fully supported with the Node Access API.
<br><br>- Ken<br><br><div><span class="gmail_quote">On 8/28/07, <b class="gmail_sendername">Karoly Negyesi</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Finally, we have a goal: "I want to change access control to a certain page based on various input (like GET) variables".<br><br>Just overdefine the menu item that you want to change and define your access mechanism. Because node/add is defined as cached you can put your menu definiton in !$may_cache with the same path -- it will overwrite the original definition. In Drupal 6, you want to do a hook_menu_alter and use your own access callback. This does not need fiddling with core.
<br><br>Changing user_access could lead to very obscure and hard to debug priviledge escalation holes: some code may make presumptions about if a page is allowed by menu then certain permissions are set which might not be true if you fiddle with roles on the fly. Saying that this does not happen currently won't change the fact that it could.