Lyle, I was going in that direction at first but I backed off of manipulating the User form. I already have 235 groups and most of them are for notification purposes. I was hoping to avoid adding more groups that would just be for notification and "reporting" roles. If I get this working I should be able to eliminate some of the Groups for other applications and use this format.
I only need one (1) group to permit changes (A1_Change) on the application. So any new user will get their account created with A1_Change permissions. When the customer needs to add a new functional group (Procurement) the Maintainer can create the pseudo-group in the permissions form and pull in the new employee to that functional group. They could then select check boxes for Create , Change or Maintain depending on what they want that permission group to do. If we use additional ARS Groups they will need to wait for an ARS Admin to create the group, set up the workflow and add it to the proper table for the Maintainers to have access. I'm just trying to off load the tasks that can be better maintained by some one closer to the business process and reduce the amount of unnecessary Groups for the system to cache. Am I complicating things? Is there a point when there are too many Groups? Thanks, --- John J. Reiser Senior Software Development Analyst Remedy Administrator/Developer Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor Sent: Thursday, August 20, 2009 6:16 PM To: arslist@ARSLIST.ORG Subject: Re: Functional Group usage (long post) If I'm understand you correctly, and you're primarily wondering about how to give Maintainers the ability to move people into and out of the four groups, this may not be too difficult. If you use filters to update the User form (you shouldn't have to have anyone update the Group form, since you'll create the 4 groups as an Administrator, and they shouldn't change once created unless you add more functional groups to your list), then you don't need to give the Maintainers Administrator privileges. You could take an approach similar to how ITSM handles it. There is a form that stores the ITSM-related permissions that users have been granted and a form for maintaining those permissions (you could do it all on one form, if you wanted to). Changes made to the form that stores their permissions trigger filters that make the appropriate updates to the User form, adding and removing them from the appropriate Remedy group. For example, if you add CS permissions to JoeUser in your form, it would trigger a filter that adds that to the Groups list on the User form. Then, your main problem is just limiting access to that form to people with Maintainer permissions, or locking it down (disabling update ability) for non-Maintainers. Does that make sense? Would something like that work for what you're looking for? Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Reiser, John J Sent: Thursday, August 20, 2009 2:32 PM To: arslist@ARSLIST.ORG Subject: Functional Group usage (long post) Hello Listers, ARS 7.1 patch 4 MS SQL 2005 MS 2003 Enterprise SP2 I am trying to nail down a method to using functional groupings for users. We have 4 functional groups for an application. CustService (CS), Tech, Logistics(Log) and Maintainer The first three deal with handling customer requests. CS and Log can create and change Customer Requests. Techs cannot create but can change requests. Maintainers can create and change requests. They must also maintain data driven menus via workflow. CS Tech Log Maintainer ----------------------------------------- Create X X X Change X X X X Maintain X I was going to make 4 entries in the Group form but the Maintainers need to move users in and out of the four functional groups. I can't give the Maintainers access to the Group and User form because the ARServer has multiple tenants using other applications. I would not be able to restrict them to this application's users because as new people are added we do not know if they will eventually work this application. Plus if the Maintainer removes someone from all of the groups they would not be able to get them back if we setup row-level access restrictions. I thought a data driven form could be used as a pseudo-group form to control who can create, change or maintain the primary form's data and menus. I'm just having a hard time getting my mind wrapped around structure of this idea. I need a table to track what I tried to display above. The "Permissions" form would be extensible if they added a new functional group. Then I think I would need to use a join to the People_Info form so I could flag a global field on the Request form to restrict the current $USER$ to their functional group permissions. Set flag = CS and the workflow would prevent them from seeing the Menu Maintenance button, or Flag = Tech and they get warned when they open the form in "New" mode. Of course that means I have to hard code information into the Workflow to make the proper restrictions/allowances. Does this sound like the right course of action? Thanks for being a sounding board. --- John J. Reiser Senior Software Development Analyst Remedy Administrator/Developer Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
