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"
