<!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. 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. I doubt that
this would be received well, although I'm not a core maintainer.
<div><br class="khtml-block-placeholder">
</div>
</blockquote>
It isn't being well received. 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. </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. 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>
</blockquote>
Don't understand how this would work. 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. 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>
</blockquote>
I've actually implemented something similar for a different application
I'm working on: <span
style="font-size: 12pt; font-family: "Times New Roman";"><a
href="http://drupal.org/node/122173">http://drupal.org/node/122173</a></span>
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). What I want is
far less dramatic: Just add the correct role to <b>user_access</b> OR
<b>$user->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. 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>
</blockquote>
This make a LOT of sense. Some sort of hook that would allow a module
to add whatever permissions it calculates to the user_acess function.
There's just one problem I see there for the og user roles proposition:
It adds permissions (or roles) based upon the group context. I notice
that by default user_access caches permissions. 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. 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->roles permissions
before they are added to the cache. 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. </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>
</blockquote>
If you think my hook_roles idea makes sense, I'd need to know how to
propose it, exactly. 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. 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->roles</b>
with my function that returns the results of $user->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->roles</b>.
If there are og user roles, then the function returns those roles + <b>$user->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>
<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 & B Salsa <a class="moz-txt-link-freetext" href="http://www.randbsalsa.com">http://www.randbsalsa.com</a>
</pre>
</body>
</html>