We actually just finished creating a module that allows just what you are looking for Axton. Our module contains a list of Functional Roles, and capabilities. You assign capabilities to a role, and then assign the user a Role, it loops a few tables, and builds the groups a user needs to be a member of in order to be part of that role, it allows a user to be a member of multiple roles and manages their capabilities (permission groups) appropriately based on your definitions....we just put it into production and it's working quite well. This allows us to as you said, define 'read access to module x' and then decide which roles have that capability defined.
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, February 21, 2008 7:30 AM To: arslist@ARSLIST.ORG Subject: Re: Filter logging in 7.1 ** That'd be all. The idea would be that a permission group could be a subject of another permission group, thus all members of the group that belongs to another group would have permissions to everything the second group does. Doesn't exist today, but it sure would make application design much cleaner in many cases. It would allow the ability to define a hierarchy of permissions, thus it would be easy to stagger permissions across some common models: - read access for module x - end user access for module x - user role a access for module x - user role b access for module x - user role c access for module x - config access for module x - admin access for module x Thus, the following implicit group memberships could exist: admin -> read, role a-c, config end user -> read user role a -> read, end user user role b -> read, end user user role c -> read, end user config -> read, end user This would obviously have to be available for roles within deployable applications. The idea is that when you are creating objects (forms, active links, fields, etc.), you only have to grant the least common denominator to objects instead of every group explicitly. Axton Grams On Thu, Feb 21, 2008 at 9:08 AM, Nall, Roger <[EMAIL PROTECTED]> wrote: ** Axton, Do you want all users who are members of PowerUser and SuperUser to have access to the objects that members of User have privileges to? Or only certain users who are members of PowerUser or SuperUser? Thanks, Roger A. Nall Manager, OSSNMS Remedy T-Mobile, USA Desk: 813-348-2556 Cell: 973-652-6723 FAX: 813-348-2565 sf49fanv AIM IM RogerNall Yahoo IM _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, February 21, 2008 9:02 AM To: arslist@ARSLIST.ORG Subject: Re: Filter logging in 7.1 ** A computed group gets you part of the way there, but you can not give explicit membership to a computed group. Say you have the following groups: User PowerUser SuperUser Now let's say you have objects that have privileges granted to User and you want members of both PowerUser and SuperUser to have access to those objects. How would you go about using computed groups to achieve that end? Axton Grams On Thu, Feb 21, 2008 at 6:11 AM, Atul Vohra <[EMAIL PROTECTED]> wrote: ** Computed Group? ----- Original Message ----- From: Axton To: arslist@ARSLIST.ORG Subject: Re: Filter logging in 7.1 Date: Wed, 20 Feb 2008 22:43:07 -0500 ** Something that would be nice to have is the ability to make a group a member of another group. Axton Grams On Wed, Feb 20, 2008 at 9:00 PM, LJ Longwing <[EMAIL PROTECTED]> wrote: If the server is set to something other that Administrator, then Demo may not be an explicit member of that group. -----Original Message----- From: Action Request System discussion list(ARSList) __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
