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"
