Hi Axton
You'd make User a computed group and make Power User and Super User part of the computed group qualification. The problem here is that it is not then easy to add Users directly into the User group apart from adding them individually to the group qualification. So, you need to plan these things in advance to grant permissions to the correct group/roles. Say you have a deployable application. You need to set up the correct roles and grant object permissions to the roles. Then you need to map the roles to a computed group for permissions. Then you need to create and populate your normal groups that will contain users. Finally you then add the user groups to the computed groups used in the roles mappings. This is a 3-tier arrangement. If you are not in a deployable application then Roles do not come into it. In that case you set up computed groups and give object permissions directly to the computed groups. Then set up your user groups. Then add the user groups to the computed group definitions. This is a two-tier arrangement. The key point in both these scenarios is that permissions are not given directly to groups that will have normal group members, but to groups/roles set up specifically to control access to functionality or data. That requires planning the roles needed in advance - but how the user groups are mapped to those roles can be adjusted afterwards as needed. One 'hole' in this architecture is if you have workflow that uses APPLICATION-CONFIRM-GROUP. This can only be used to check for Group membership and not for 'Role' membership. As the Groups mapped to a Role can change (between Production and Test states for example), this effectively means that this functionality cannot be used in a deployable application. Regards David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== ARS List Award Winner 2005 Best 3rd party Remedy Application See the <http://www.westoverconsulting.co.uk/downloads/ESS_Concepts_Guide.pdf> ESS Concepts Guide tel +44 1494 468980 mobile +44 7710 377761 email [EMAIL PROTECTED] web http://www.westoverconsulting.co.uk <http://www.westoverconsulting.co.uk/> _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, February 21, 2008 2:02 PM 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___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
