[development] OG User Roles

[Ron Parker]

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:

David Metzler wrote:

> 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.  
>
It isn't being well received.  That's why the CVS administrator told me 
to post the idea here.

> This functionality is probably best implemented in 5.0 or greater, 
> because of the new node access functionality.  
>
I'm working in 5.1 now.

> 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
>
Don't understand how this would work.  I'll read up on it.

> 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. 
>
> 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.
>
I've actually implemented something similar for a different application 
I'm working on: http://drupal.org/node/122173  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 user_access OR $user->roles depending upon the group.

> 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. 
>
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.

Please let me know how you think some sort of hook would work here.

My suggestions is a sort of _roles 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.

> I think either of these strategies would be far more well received 
> than what you've currenlty proposed. 
>
> 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. 
>
If you think my hook_roles idea makes sense, I'd need to know how to 
propose it, exactly.  Thanks so much for input.

-ron

> On Mar 18, 2007, at 2:11 PM, Ron Parker wrote:
>
>> 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.
>>
>> I have posted details on the proposed project here: 
>> http://drupal.org/node/87679
>>
>> 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.
>>
>> 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. 
>>
>> Specifically, the changes I make are:
>>
>> 1. Creating the og_users_roles table which is the same as the 
>> users_roles table except that adds the GroupID.
>> 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.
>>
>> The change to the user.module is small: simply replacing $user->roles 
>> 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 $user->roles.  If 
>> there are og user roles, then the function returns those roles + 
>> $user->roles.
>>
>> 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.
>>
>> Any suggestions? 
>>
>> Thanks.
>>
>>-- 
>>Ron Parker
>>Software Creations               http://www.scbbs.com
>>Self-Administration Web Site     http://saw.scbbs.com
>>SDSS Subscription Mgmt Service   http://sdss.scbbs.com
>>Central Ave Dance Ensemble       http://www.centralavedance.com
>>R & B Salsa                      http://www.randbsalsa.com
>>    
>>
>
>
>
> __________ NOD32 2125 (20070318) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com



-- 
Ron Parker
Software Creations               http://www.scbbs.com
Self-Administration Web Site     http://saw.scbbs.com
SDSS Subscription Mgmt Service   http://sdss.scbbs.com
Central Ave Dance Ensemble       http://www.centralavedance.com
R & B Salsa                      http://www.randbsalsa.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070318/398a634a/attachment.htm