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"
