Andrew, That is an interesting situation but I agree there has to be something out there preferably out-of-the-box.
My fellow ARsListers, please correct me if I'm wrong but withh my limited knowledge of dynamic groups, I there the fieldIDs range only 999 IDs, meaning you can only have 999 dynamic groups. Or is it 9999? Anyways, I can begin to see why dynamic computed group isn't the best solution for you. Best Regards, Neel Gautam. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Hicox Sent: Wednesday, April 18, 2007 1:14 PM To: [email protected] Subject: Re: ARS7 & Matching Assignee Group field LOL, 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 only >> be >> > a 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 T >> table). This using the group id's with semicolons gives the same error >> as 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 to >> create 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 only >> be >> > a 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 the >> test >> > is 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' field >> value >> > as a single group, then there are actually zero people in that >> group, >> > 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 only >> >> users >> >> >> who 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 work >> with >> >> >> multiple groups. >> >> >> Specifically, the requirement is that a user must be in ALL of >> the >> >> >> groups listed in the 'Assignee Group' field, to have access to >> the >> >> >> ticket. >> >> >> >> >> >> So for instance if 'Assignee Group' = "Group1 Group2 Group3", a >> >> user >> >> >> must be in all three groups to view the ticket (instead of just >> >> one of >> >> >> the three, which is apparently the default multiple group >> >> behavior). >> >> >> >> >> >> Strangely enough, I can "trick" ARS into doing this with the >> >> following >> >> >> one-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' >> >> field >> >> >> 3) uncheck 'Enable Multiple Assign Groups' >> >> >> >> >> >> Under those circumstances, ARS7 will behave exactly the way I >> want >> >> it >> >> >> to. That is, a user must be in ALL of the groups in the >> 'Assignee >> >> >> Group' field to view the ticket. >> >> >> >> >> >> However, I can't make any new tickets like this while it's in >> the >> >> >> "AND" >> >> >> matching mode (instead of "OR"). ARS7 gives me an error if I >> try to >> >> >> create 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" to >> >> match >> >> >> the 'Assignee Group' field (user can be in any one of the >> groups). >> >> >> >> >> >> ARS7 will only use "AND" to match the 'Assignee Group' field >> (user >> >> has >> >> >> to be in ALL groups) if 'Enable Multiple Assign Groups' is >> turned >> >> off. >> >> >> >> >> >> How can I just tell ARS7 to use "AND" to match the multiple >> >> assignee >> >> >> groups instead of OR (as it does when the feature is turned >> off?) >> >> >> >> >> >> PLEASE HELP! >> >> >> I'm pulling my hair out on this one! >> >> >> >> >> >> Thanks, >> >> >> >> >> >> -Andrew >> >> > >> >> 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" >> > >> > >> 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:"Where the Answers Are" This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
