<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">If I understand it correctly, the proposed modification would put OG specific functionality into user.module.  I doubt that this would be received well, although I'm not a core maintainer.  <DIV><BR class="khtml-block-placeholder"></DIV><DIV>This functionality is probably best implemented in 5.0 or greater, because of the new node access functionality.  </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Here's an alternate strategy to consider while you're waiting for core patches.  Move the logic about testing for permissions into a form_alter hook.  You ought to be able to then redirect to an access denied error message if the conditions for the node insert aren't correct.  I haven't tried this yet, but it seems p</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This does point out a subtle flaw in drupals access permissions in that it doesn't provide the ability to have an access module control "insert" permissions.  I think that ultimately this is the right fix, rather than altering user_access, which controls a lot more than node access. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A patch for making drupal call the appropriate access control hooks before insert (access_records and node_access_grants) would be a much more well received patch, and probably make your code a lot cleaner, as it would remove all the arg checking that you're doing in your current strategy.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Alternatively, propose a new hook that would be called from within user_access.  For example, user_access is called and after it's done it's work it invokes a module _access hook that would allow the og_roles module to change the result of the user_access calls. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I think either of these strategies would be far more well received than what you've currenlty proposed. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm pretty familiar with node_access in drupal5, having participated in the simple_access port, so if you need more info on how these would be implemented, let me know. </DIV><DIV><BR><DIV><DIV>On Mar 18, 2007, at 2:11 PM, Ron Parker wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">  Hello. I'm new to this list, so please bear with me.  I've been working on a module for the past 9 months and recently submitted a request to the CVS administrator for a project account.  The administrator told me I needed to run this project past the developers mailing list.<BR> <BR> I have posted details on the proposed project here: <A class="moz-txt-link-freetext" href="http://drupal.org/node/87679">http://drupal.org/node/87679</A><BR> <BR> Essentially, I updated the existing og_roles module to be able to define roles by individual groups.  So, instead of assigning a role to a user account and that user then having that role everywhere in the site, my module assigns a role to a user in a group, and the user only has the access granted by that role in the group that role is assigned to him.  Therefore, a user can now have different roles in different groups.<BR> <BR> The problem is that in order to make this work, I needed to modify the user_access function of the user.module to recognize roles based upon the group context.  <BR> <BR> Specifically, the changes I make are:<BR> <BR> 1. Creating the og_users_roles table which is the same as the users_roles table except that adds the GroupID. <BR> 2. Modifying the user_access function so that it additionally reads the og_users_roles table, recognizes the existing group context (if any), and adds whatever roles are appropriate. <BR> <BR> The change to the user.module is small: simply replacing <B>$user-&gt;roles</B> with my function that returns the results of $user-&gt;roles + whatever roles are allowed based upon the group (og user roles).  I haven't changed the core functionality of the function, only added the og user roles addtional functionality.  In other words, if there are no og user roles, then the function still returns only <B>$user-&gt;roles</B>.  If there are og user roles, then the function returns those roles + <B>$user-&gt;roles</B>.<BR> <BR> Needless to say, the CVS administrator has a big problem with #2.  He asked that I run this concept by the developers mailing list in order to see if anyone might have a workaround solution that doesn't involve "hacking" the core.  I don't see how you do it without user_access recognizing the group context, but then again, everything I've learned about Drupal has been through trial and error, so there is certainly a ton of things I don't know.<BR> <BR> Any suggestions?  <BR> <BR> Thanks.<BR> <PRE class="moz-signature" cols="72">-- 
Ron Parker
Software Creations               <A class="moz-txt-link-freetext" href="http://www.scbbs.com">http://www.scbbs.com</A>
Self-Administration Web Site     <A class="moz-txt-link-freetext" href="http://saw.scbbs.com">http://saw.scbbs.com</A>
SDSS Subscription Mgmt Service   <A class="moz-txt-link-freetext" href="http://sdss.scbbs.com">http://sdss.scbbs.com</A>
Central Ave Dance Ensemble       <A class="moz-txt-link-freetext" href="http://www.centralavedance.com">http://www.centralavedance.com</A>
R & B Salsa                      <A class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</A>
</PRE>  </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>