[development] OG User Roles
David Metzler
metzlerd at metzlerd.com
Sun Mar 18 23:03:22 UTC 2007
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.
This functionality is probably best implemented in 5.0 or greater,
because of the new node access functionality.
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
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.
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070318/916f2237/attachment-0001.htm
More information about the development
mailing list