Re: ARS7 & Matching Assignee Group field

[Andrew Hicox]

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"