Hi Andrew
If you have the 'Allow Multiple Assignee Groups' setting enabled on your
server and row level access defined for a form using the Assignee Group
field (112), the SQL generated by ARS contains clauses like the following:
((T201.C112 LIKE '%;''fred";%'') OR ((T201.C112 LIKE '%;0;%') OR ((T201.C112
LIKE '%;73421;%') OR ((T201.C112 LIKE '%;73419;%') OR ((T201.C112 LIKE
'%;73404;%') OR (T201.C112 LIKE '%;73401;%'))))))
That is, the server constructs a series of LIKE statements for each group
that the user is a member of (with OR between so the user only needs to be a
member of one matching group to access the record. What you want is a
similar clause where the Ors are replaced with ANDs so the user must be a
member of all groups specified in 112.
You can't do this through normal row level access, but I wonder if you can
not use row level access, but construct a similar query on the fly to add to
whatever the user query is. ('Assignee Group' LIKE "%;73404;%" AND 'Assignee
Group' LIKE "%;73405;%" etc.) I haven't tried this myself.
What you'd need to do is have workflow to grab and parse the group list from
the user record. Then construct the qualification you need, then set this to
the advanced search bar field 1005 (that you'd need to add to your forms).
Put this workflow in a guide, and run it whenever a query is performed.
You'd also need something similar for table fields to construct a suitable
EXTERNAL qualification.
As I said, I haven't tried this approach and don't know what the performance
overhead would be, but it sounds better that creating groups on the fly.
HTH
David Sanders
Remedy Solution Architect
Enterprise Service Suite @ Work
==========================
ARS List Award Winner 2005
Best 3rd party Remedy Application
See the ESS Concepts Guide
tel +44 1494 468980
mobile +44 7710 377761
email [EMAIL PROTECTED]
web http://www.westoverconsulting.co.uk
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew Hicox
Sent: Wednesday, April 25, 2007 2:53 AM
To: [email protected]
Subject: Re: filter privilege escalation?
Ah yes. I looked into putting the users directly into the Assignee
Group field.
However, the maintenance overhead required when say, a new user is
added to a group, or an existing user changes groups, is just
unacceptable.
I think I'm going to have a go at creating the groups on the fly. That
is, we create the computed group when a new ticket is added that
requires a computed group that doesn't already exist. With any luck,
addition of new computed groups will not be a common event, and things
will only slow to a crawl once in a great while.
It still seems incredible to me that there's not something off the
shelf to handle this kind of situation. It seems like it would be such
a common problem that it'd have been solved by now.
I'm pretty new to ARS7, though I have a lot of experience with the 4.5
series (I know, not evident from my last post about filter
permissions).
I see there's this new plugin architecture, where one can write java
code that integrates into your ARS applications (beyond the basic API
layer). Do any listers here know if that architecture is flexible
enough to override ARS's built in group matching? It's a lot of
documentation to sift through, and I'd like to avoid having to do that
if the plugin stuff is a dead end for the problem I'm trying to solve.
thanks everyone,
-Andrew
On Apr 24, 2007, at 3:02 PM, Scott Parrish wrote:
> Andrew,
> This is one of the reasons that I made the suggestion of building the
> list
> of users into field 112 rather than creating groups on the fly. At the
> time,
> I didn't want to go into all of it, but you really do not want to be
> creating Groups on the fly and running into what Axton describes below.
>
> Scott Parrish
> IT Prophets, LLC
> (770) 653-5203
> http://www.itprophets.com
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> Sent: Friday, April 20, 2007 8:58 PM
> To: [email protected]
> Subject: Re: filter privilege escalation?
>
> Filters always run with admin privelages. Be careful creating
> computed groups on the fly, as each time you create or update one, the
> entire user form dataset gets scanned/updated.
>
> Create a computed group manually and watch the cpu on your arserver
> and db server. Also keep in mind that cacheing (group) operations
> will occupy the admin thread until they complete, blocking any other
> admin operations.
>
> Axton Grams
>
> On 4/20/07, Andrew Hicox <[EMAIL PROTECTED]> wrote:
>> Hello all:
>>
>> I'm still working on my issue regarding the assignee group field.
>>
>> I think I've worked out a system where I can create computed groups on
>> the fly as tickets are submitted for various combinations of the
>> regular groups (which are synced from the external database).
>>
>> I'd like to spawn these computed groups with a filter that executes on
>> a ticket submission or modify.
>>
>> However, I believe one would need Admin privileges to submit new group
>> fields, and I'm fairly certain that filters that fire on submit or
>> modify operations execute with the permissions of the user who
>> triggered them. Obviously all of my users can't be Admins.
>>
>> Is there a way to specify a filter to always run as admin?
>>
>> my other option seems to be setting up flags in the tickets so that
>> they're picked up by escalations which would do the dirty work as the
>> admin user.
>>
>> so ... is there something like that?
>> am I completely wrong about filters firing with user permissions?
>> if I'm right about that, is there a way to escalate privs for just one
>> filter ?
>>
>> 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"
>>
>
> _______________________________________________________________________
> _____
> ___
> 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"
>
>
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"
