It sounds like you're trying to define functional roles kind of like what you have with ITSM (sorry, I keep going back to that). There, you've got permissions that get added to your profile, but then you can also have roles within a support group that give you additional "permissions" or functionality within the system. In that case, you may have Remedy permissions that allow you to submit and edit records (kind of like your A1_Change group), but then based on your role within a support group, you can enabled or disable certain functionality in the application.
In your case, perhaps you could maintain conceptual groups - these groups don't correspond to Remedy permission groups, they just define what functionality you want to be available to users. Users can then be added to and removed from these conceptual groups by someone in the Maintainer "group". As users use the application, you would check whether they belong to certain groups and disable or enable functionality when forms load and/or when they attempt to take certain actions. For example, you build everything pretty much just like you would for the person that has all permissions, and then selectively remove or disable functionality that JoeUser doesn't have as forms are viewed by that person. Does that make sense? In that case, you still only have the one Remedy permission group, and you're free to define more groups as you see fit without causing server recaching, etc. The catch is that as you add groups, you still need to add logic to take those into account. I don't know if there's an easy way around that, though. If you wanted to make adding groups and defining their functional abilities both configurable, that starts getting pretty complex... Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Reiser, John J Sent: Friday, August 21, 2009 6:51 AM To: [email protected] Subject: Re: Functional Group usage (long post) 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:[email protected]] On Behalf Of Lyle Taylor Sent: Thursday, August 20, 2009 6:16 PM To: [email protected] 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:[email protected]] On Behalf Of Reiser, John J Sent: Thursday, August 20, 2009 2:32 PM To: [email protected] 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:[email protected] 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:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] 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:[email protected] ARSlist: "Where the Answers Are"
