Firing on every get entry is definitely something to take into consideration and was one of my concerns. I figured since it is not a query to the db it wasn't too much of a performance hit for my situation (it is still an API call to the server each time you view a record but there are going to be other various API calls anyways when you view a record). Plus I didn't know about the Disable-Client-Operations option.
Thanks for the "Disable-Client-Operation". This looks like an awesome feature that I will play with. You could actually get to the user level by creating a computed group and specify login names (or a mix of login names and groups). Depending on the size of your system and the way you have your groups setup it could become a maintenance burden to make sure all new users are properly restricted.
I guess this is were the get entry filter option has a bit more flexibility because you can disable everybody as a baseline and enable ODBC operations for a group with a NOT statement (i.e. NOT $GROUPS$ LIKE "%" + "Administrator" + "%" versus having to disable each group individually using the config file. But even then you could have a computed group with all groups except the Admin group to use with the Disable-Client-Operation. Many ways to do it (I love ARS).
Jason
On 9/6/06, Carey Matthew Black <[EMAIL PROTECTED]> wrote:
All,
ConfigGuide-630.pdf Page: 287:
"
Disable-Client-Operation: <tag_number_to_disable> [[<start_time>]-
[<stop_time>]] [<group_ID_list>]
Restricts time-consuming operations (such as reporting) during busy times,
improving the overall performance. This option can be set to certain times
the day. It can also exclude users of specific groups so that they are not
blocked from performing the specified operation. For example, you can
allow only the administrator to perform reporting during busy hours.
"
So ... I think the config file option is the best bet. It would allow
any specified groups to be _excluded_ from the restriction.
Jason's Get Entry filter option does go to one level more granular (to
the user not a group) and has the added performance expense of being
evaluated for every data row returned from the form. (Even for the
users listed in the Run If.)
I wonder if the config option will (or was) similarly expanded like
the Assignee Group values were but BMC failed to document that
feature? (Maybe you can be user specific in the config file? if not,
then it would be a good REF idea IMHO.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
__20060125_______________________This posting was submitted with HTML in it___
