Even though it's customizable by preference, it doesn't address the issue of macros and ad hoc reports being possibly hosed...especially because in this large, decentralized environment across a very large area, it is not possible to know who does or will do ad hoc reporting.
What I'm currently experimenting with is something somewhat crude...I've added a radio button called "Quick Search" on the form in question. The radio button is set to YES by default. When the value is set to YES (or unselected) a search will only yield tickets opened in the past 90 days. For users who want to do ad hoc reporting or pull up older tickets for legacy purposes, they can just set the "Quick Search" to NO. Anyway, it works somewhat well but am hoping for other ideas for a better solution. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Tuesday, July 22, 2008 2:56 PM To: [email protected] Subject: Re: Unqualified Searches in Very Large Enterprises -- Thoughts, Please ** That's the beauty of using the preference values - they can be set differently - and enforced - at the user and/or group level. That way, you can leave the server value unlimited, but limit it dynamically at the user level. Rick On Tue, Jul 22, 2008 at 12:38 PM, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote: Yes...but the "limit the number of requests returned" approach has that nasty tendency of messing up ad-hoc reports and macros, which are done extensively in this environment. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Tuesday, July 22, 2008 2:33 PM To: [email protected] Subject: Re: Unqualified Searches in Very Large Enterprises -- Thoughts, Please Some things that come to mind: - Force the use of a preference server, force the value of max returned entries to 1000 or the likes - Set a hard limit on the server for the max number of entries returned from a get... - Don't give users access to search regular forms (front-end things with display only forms) Axton Grams On Tue, Jul 22, 2008 at 3:25 PM, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote: > ** > > Hi everyone: > > > > I wanted to get everyone's take on this thorny issue...I know this matter has > been discussed many times before, but I wanted to put a new twist on it. > > > > Specifically, I wanted to get anyone and everyone's thoughts on the problem > of unqualified searches in a large enterprise. Specifically, suppose the > following: Suppose you have a custom app being used in a very large > environment. Suppose in that environment you have established a ticket > isolation system by setting hidden fields on the form on SEARCH. Tickets > are isolated by every company within the enterprise. > > > > Now, each company has in excess of 150,000 tickets, and there are 20 > companies. The problem is, techs are accidentally clicking the SEARCH > button without any qualification...kicking off what is *seemingly* an > unqualified search. But the search is not truly unqualified because fields > are getting set on SEARCH to effect the ticket isolation. But the problem > remains - such a search goes out and attempts to fetch 150,000+ tickets. > Several techs accidentally doing this at once (we have 800+ techs, so the > possibility of techs doing this is pretty high) causes the server to slow > way down. > > > > Thoughts on how to minimize this issue? Hopefully I've described the problem > well enough. > > > > TIA, > > Norm > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
