Hrm ... that's an interesting idea.So at create or modify time, I populate 'Assignee Group' with the explicit list of userid's that fall into the access groups.
This could work.I only see one possible flaw, I think the 'Assignee Group' field is limited to 255 chars. Can anyone verify this limitation for me? Can I bump it up to some really high number and have it still work ?
thanks again everyone, -Andrew On Apr 18, 2007, at 3:49 PM, [EMAIL PROTECTED] wrote:
Andrew,Barring changing how all of this works in the first place, I would probablytry something like this . . .Rather than using GROUPS for Row Level Access, I would attempt to use User IDs. Using workflow, I would attempt to find a way to populate either field ID 112 or a Dynamic Group field with the list of User IDs that exist in allGroups associated with the related device(s).Therefore, if Device A and Device B were associated and users ABC and ABD were in the groups associated with Device A and Device B then I would addtheir IDs to field 112 or the Dynamic Group field.With the fluidity (is that a word?) of your Groups in Remedy, I could bewrong, but I do not think you are going to get to where you want to go using Groups. Scott Parrish IT Prophets, LLC (770) 653-5203 http://www.itprophets.com Original Message: ----------------- From: Andrew Hicox [EMAIL PROTECTED] Date: Wed, 18 Apr 2007 14:14:12 -0400 To: [email protected] Subject: Re: ARS7 & Matching Assignee Group fieldLOL, yes, there is more to the story ... since you asked, here it is ...We have an external database which contains device configuration data, and a set of user groups that are assigned to each device. When a ticket is created in our Remedy form, we must restrict access to the ticket based on the user group that is associated to the device the ticket was created for. To further complicate matters, multiple devices can be assigned to a single remedy ticket. So ... if you create a remedy ticket for deviceA, deviceB, and deviceC, the user must have permissions to the group lists assigned to all three devices. Meaning, when the ticket is created or when a device is added to the ticket, we append the 'Assignee Group' field with the list of groups for the given device from the external database. We sync group definitions from the external database to the remedy Groups form on an escalation that runs every few minutes. To even further complicate matters, the user community may create new ad-hoc groups in the device configuration database, that will be propagated to the remedy Groups form. So ... the simplest possible solution .... propagate the group data from the device configuration database into Remedy's group form. Append the 'Assignee Group' field when new devices are added to a ticket. Have ARS use AND as the comparison on the 'Assignee Group' field instead of OR. the other solution ... and I'm not even sure how this would work, exactly ... Propagate the group data from the external device configuration database into Remedy's Group form. Create dynamic computed groups that specify every possible additive combination of the propagated device groups. Create some sort of third form which maps group combinations to the dynamic computed groups, and assign the dynamic group to the ticket when it's created or a new device is added to it. so if $x is the number of propagated groups I guess the number of dynamic computed groups I'd need would be something like !$x ... so say i had just 10 groups ... !10 = 55 dynamic computed groups ... managed by who again ? ;-) I just KNOW I'm missing something here. This has to be a really common requirement ... like I said before, it just can't be this complicated. -Andrew On Apr 18, 2007, at 1:27 PM, Axton wrote:Have you read up on computed groups? Say you have a user: Username: USERA Groups: APP-Support APP-Management APP-Administrator REMEDY SUPPORT Computed Groups: Now say you want to lock rows based on membership of 2 groups: APP-Administrator 'AND' REMEDY SUPPORT You create a computed group with the following qualification: Computed Group Name: REMEDY ADMINS Group Definition: "APP-Administrator" AND "REMEDY SUPPORT" Once that group is created, the user will automatically be placed in the computed group. His user record will looks like this: Username: USERA Groups: APP-Support APP-Management APP-Administrator REMEDY SUPPORT Computed Groups: REMEDY ADMINS Now in your data, just put the computed group REMEDY ADMINS in the assignee group field; then anyone that is a member of APP-Administrator AND REMEDY SUPPORT will be able to access that record. Ask yourself these questions: If you had to count the number of possible group combinations you are going to require for your data set, how many do you have? How many records do you have in your data set? If you want to take the approach you won't give up, what user with Administrator access is going to maintain every record in the data set with the list of groups you want on each record? I fail to see how the computed group approach is more maintenance than what you would like to do. Maybe there is something you haven't shared yet? Axton Grams On 4/18/07, Andrew Hicox <[EMAIL PROTECTED]> wrote:Why is it important to [ 3) uncheck 'Enable Multiple Assign Groups'] ? if you don't turn off 'Enable Multiple Assign Groups', ARS will match the 'Asignee Groups' using "OR" (meaning access granted if user is a member of any one of the listed groups). Turning off 'Enable Multiple Assign Groups' forces ARS to match using "AND" , but disables the ability to submit tickets with multiple groups in the 'Assignee Group' field.When 'Enable Multiple Assign Groups' = FALSE the user must not onlybea member of all the groups, but they must also be a member of the groups in the exact same order. (Just a guess.) ...I guessed this as well. However, I've verified, that it IS actually matching using AND. I verified, by switching the order of the groups listed in the User tables 'Groups' field, as well as adding other groups to the groups list for the user, that weren't in the 'Assignee Group' field in the ticket. Also, I've tried leaving 'Enable Multiple Assign Groups' false, and manually trying to add multiple groups using the semicolons and group id format, and also to the ticket directly in the database (the Ttable). This using the group id's with semicolons gives the same erroras manually attempting to add multiple groups through the GUI. Doing the database method dosen't seem to work either. While the new data shows in the database T table, it won't show in the GUI, meaning I guess it's being stored in yet some other place than the T table by Remedy.So far, I can't see any possible way to make this happen other than tocreate thousands of computed groups ... one for each possible combination of the Regular groups. It can't be this hard. I can't be the first person whose needed to control access to records using additive permission sets. I've got to be missing something here. Help, please, anyone? -Andrew ;-) . On Apr 18, 2007, at 12:23 PM, Carey Matthew Black wrote:Andrew, Why is it important to [ 3) uncheck 'Enable Multiple Assign Groups'] ?I suspect that your root issue is that you are trying to force the server to behave as if 'Enable Multiple Assign Groups' = TRUE, with the setting being set to FALSE. I think what you are seeing is actually this... When 'Enable Multiple Assign Groups' = FALSE the user must not onlybea member of all the groups, but they must also be a member of the groups in the exact same order. (Just a guess.) Meaning that thetestis really not if the user is a member of the group, but if the users 'Group List' value has the STRING that is in the 'Assignee Group' field. If the ARS server is treating the 'Assignee Group' fieldvalueas a single group, then there are actually zero people in thatgroup,because the combined "group" likely does not exist. However... When 'Enable Multiple Assign Groups' = TRUE then the server will put on the end of the where clause a test for each Group in the users 'Group List' in a set of OR conditions. (Example: AND ( 'Assignee Group' LIKE "%;11111;%' OR 'Assignee Group' LIKE "%;22222;%' OR 'Assignee Group' LIKE "%;33333;%') -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two.On 4/18/07, Andrew Hicox <[EMAIL PROTECTED]> wrote:Hello everyone: In ARS7 you can use the 'Assignee Group' (field id 112) field to control access to records (row-level locking). If you grant the 'Assignee Group' permission on the 'entry id' field, then onlyuserswho are in the group specified in the 'Assignee Group' field are granted permission to view the record. This works just fine for me. However, I need to make this workwithmultiple groups. Specifically, the requirement is that a user must be in ALL ofthegroups listed in the 'Assignee Group' field, to have access totheticket. So for instance if 'Assignee Group' = "Group1 Group2 Group3", ausermust be in all three groups to view the ticket (instead of justone ofthe three, which is apparently the default multiple groupbehavior).Strangely enough, I can "trick" ARS into doing this with thefollowingone-off procedure ... 1) check 'Enable Multiple Assign Groups' in "Server Information" dialogue, click "Apply" 2) create a ticket with multiple groups in the 'Assignee Group'field3) uncheck 'Enable Multiple Assign Groups' Under those circumstances, ARS7 will behave exactly the way Iwantitto. That is, a user must be in ALL of the groups in the'AssigneeGroup' field to view the ticket. However, I can't make any new tickets like this while it's inthe"AND" matching mode (instead of "OR"). ARS7 gives me an error if Itry tocreate tickets with multiple groups in the 'Assignee Group'field,unless the 'Enable Multiple Assign Groups' is enabled. If 'Enable Multiple Assign Groups' is enabled, ARS7 uses "OR" tomatchthe 'Assignee Group' field (user can be in any one of thegroups).ARS7 will only use "AND" to match the 'Assignee Group' field(userhasto be in ALL groups) if 'Enable Multiple Assign Groups' isturnedoff.How can I just tell ARS7 to use "AND" to match the multipleassigneegroups instead of OR (as it does when the feature is turnedoff?)_____________________________________________________________________ _PLEASE HELP! I'm pulling my hair out on this one! Thanks, -AndrewAndrew N. Hicox Hicox Information Systems LLC Manassas, VA USA http://hicox.com [EMAIL PROTECTED] 703-367-9085_________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"Andrew N. Hicox Hicox Information Systems LLC Manassas, VA USA http://hicox.com [EMAIL PROTECTED] 703-367-9085_____________________________________________________________________ __________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"______________________________________________________________________ _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"_______________________________________________________________________ ________UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Wherethe Answers Are" -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web_______________________________________________________________________ ________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Andrew N. Hicox Hicox Information Systems LLC Manassas, VA USA http://hicox.com [EMAIL PROTECTED] 703-367-9085 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
