<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thank you so much for the response.&nbsp; You know a heck of a lot more
about this than I, but I will respond inline below:<br>
<br>
David Metzler wrote:<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">If I understand it correctly, the proposed modification
would put OG specific functionality into user.module.&nbsp; I doubt that
this would be received well, although I'm not a core maintainer.&nbsp;&nbsp;
  <div><br class="khtml-block-placeholder">
  </div>
</blockquote>
It isn't being well received.&nbsp; That's why the CVS administrator told me
to post the idea here.<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <div>This functionality is probably best implemented in 5.0 or
greater, because of the new node access functionality.&nbsp;&nbsp;</div>
  <div><br class="khtml-block-placeholder">
  </div>
</blockquote>
I'm working in 5.1 now.<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <div>Here's an alternate strategy to consider while you're waiting
for core patches.&nbsp; Move the logic about testing for permissions into a
form_alter hook.&nbsp; You ought to be able to then redirect to an access
denied error message if the conditions for the node insert aren't
correct.&nbsp; I haven't tried this yet, but it seems p</div>
  <div><br class="khtml-block-placeholder">
  </div>
</blockquote>
Don't understand how this would work.&nbsp; I'll read up on it.<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <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.&nbsp; I think that ultimately this is the right fix,
rather than altering user_access, which controls a lot more than node
access.&nbsp;</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>
</blockquote>
I've actually implemented something similar for a different application
I'm working on: <span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;"><a
 href="http://drupal.org/node/122173">http://drupal.org/node/122173</a></span>&nbsp;
It works farily well, but brings up another problem:
view/create/update/delete permissions (access_grants) are handled
differently from list permissons (node_db_rewrite_sql).&nbsp; What I want is
far less dramatic:&nbsp; Just add the correct role to <b>user_access</b> OR
<b>$user-&gt;roles</b> depending upon the group.<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <div>Alternatively, propose a new hook that would be called from
within user_access.&nbsp; 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.&nbsp;</div>
  <div><br class="khtml-block-placeholder">
  </div>
</blockquote>
This make a LOT of sense.&nbsp; Some sort of hook that would allow a module
to add whatever permissions it calculates to the user_acess function.&nbsp;
There's just one problem I see there for the og user roles proposition:
It adds permissions (or roles) based upon the group context.&nbsp; I notice
that by default user_access caches permissions.&nbsp; This won't work since
a user's role will really depend upon what nodes he's looking at and
where at the time user_access is called.&nbsp; Unless the hook would also
allow the module to delete the permissions cache for this user.<br>
<br>
Please let me know how you think some sort of hook would work here.<br>
<br>
My suggestions is a sort of <b>_roles </b>hook that would be called
from within user_access and added to the $user-&gt;roles permissions
before they are added to the cache.&nbsp; The module_name_roles function
would then do it's thing to create a list of permissions to add,
deleting the user's permissions cache.<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <div>I think either of these strategies would be far more well
received than what you've currenlty proposed.&nbsp;</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.&nbsp;</div>
  <div><br>
  </div>
</blockquote>
If you think my hook_roles idea makes sense, I'd need to know how to
propose it, exactly.&nbsp; Thanks so much for input.<br>
<br>
-ron<br>
<blockquote cite="midBAF61AF3-5800-4FC1-A5CC-28AF437177B2@metzlerd.com"
 type="cite">
  <div>
  <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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; <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).&nbsp; I haven't
changed the core functionality of the function, only added the og user
roles addtional functionality.&nbsp; In other words, if there are no og user
roles, then the function still returns only <b>$user-&gt;roles</b>.&nbsp;
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.&nbsp; 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.&nbsp; 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?&nbsp; <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 &amp; B Salsa                      <a class="moz-txt-link-freetext"
 href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
    </pre>
  </blockquote>
  </div>
  <br>
  </div>
  <br>
  <br>
__________ NOD32 2125 (20070318) Information __________<br>
  <br>
This message was checked by NOD32 antivirus system.<br>
  <a href="http://www.eset.com">http://www.eset.com</a><br>
</blockquote>
<br>
<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 &amp; B Salsa                      <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</body>
</html>