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