Well your way presents a problem for a different set of 'others'--different
strokes for different folks.
Regardless, I think the per-device status field would still be useful.
Something that techs and mgrs can put notes into regarding the current
status of a particular device.
--Rick
"Jonathan A. Zdziarski" wrote:
>
> this is why a graphical interface with collaspseable menus will be
> really useful. If you are trying to keep track of events like this, it
> presents a problem for others unless we do something client-specific
>
> On
> Mon,
> 18 Oct 1999, Rick Beebe wrote:
>
> > Good point, but it depends on how you use it. We, the network operations
> > staff, hide devices so that our help desk doesn't see them. Usually it's
> > because we've verified that the device is still alive even though it's not
> > answering pings, or it's something that's temporarily down. Obviously we
> > can't go around and put cookies on everyone's machines.
> >
> > If you want to see all the devices, just look at the 'error' view instead of
> > the 'critical' view.
> >
> > "Jonathan A. Zdziarski" wrote:
> > >
> > > the problem with a 'hidden' field in the database is that it's not the
> > > place for it...if one person wants to hide a view and another doesn't,
> > > it automatically makes the field obsolite. i think the 'hidden'
> > > information should be kept in either a cookie, /tmp file, or whatever
> > > type of file a view process initializes to store its variables.
> > >
> > > On Mon, 18
> > > Oct 1999, Rick Beebe wrote:
> > >
> > > > "Jonathan A. Zdziarski" wrote:
> > > > >
> > > > > All involved, please let me know what you think of this below. I believe
> > > > > it will be the optimal level of multiple dependency logic for our
> > > > > application allowing you to form complex AND and OR routines, rather than
> > > > > just OR routines.
> > > >
> > > > One of the things I added to the web interface, that doesn't exist in
> > > > netconsole, was a status field and a 'hidden' field. I had to use the
> > > > somewhat kludgy etc/updates file to do that. Since we're talking about a
> > > > redesign, how about adding those to the database to make it easy to add that
> > > > functionality to any of the interfaces.
> >
--
_______________________________________________________________________
Rick Beebe (203) 785-6416
Manager, Systems & Network Engineering FAX: (203) 785-3978
ITS-Med Client & Technology Services Richard.Beebe@yale.edu
Yale University School of Medicine
P.O. Box 208078, New Haven, CT 06520-8078
_______________________________________________________________________
|