You can check when they were supposed to run, and put that on a timeline 

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Barber, David
Sent: Wednesday, May 13, 2009 8:44 AM
To: [email protected]
Subject: Re: Escalation Timeline

Doh!

You're right - timestamp is the create date or last modified date of the
escalation.

So unless there is another metatable hidden in there somewhere, then I can't
go any further on this.  If the last executed is stored internally within
the servers memory, then you possible can't check the timeline of
escalations without delving into the server logs?

Regards

Dave

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]]on Behalf Of Grooms, Frederick W
Sent: 13 May 2009 15:35
To: [email protected]
Subject: Re: Escalation Timeline


I thought timestamp was the create date of the escalation.  The last
executed is only in the server's memory

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Barber, David
Sent: Wednesday, May 13, 2009 9:25 AM
To: [email protected]
Subject: Re: Escalation Timeline

Hi Rick,
 
I should have posted - found it after a quick google.
 
All I'd really is the escalation name (stored in the "NAME" field) and the
time last run.  Its the latter that appears to be dubious - on our live
(load balanced) system, put the "timestamp" field into an epoch date
convertor, and it seemed to give dates  implying that the escalations hadn't
run since yesterday.  Checked the log files, and the escalations were
running just fine.  Didn't have this problem on our test systems though.
 
It is handy to have it available via a quick bit of SQL - select name,
timestamp from escalation order by timestamp .... find when last run.  But
as I said above, this only seems to work correctly on our test systems.
 
Regards

Dave

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]]on Behalf Of Rick Cook
Sent: 13 May 2009 15:19
To: [email protected]
Subject: Re: Escalation Timeline
 
David,
 
It's just called 'escalation' - always has been.  Note that you will have to
massage/parse some data and map some bitmasks to turn those into human
readable values, etc., so it's not as simple as I might have made it sound. 
But as long as the translations go both ways, it should work.
 
One thing of note is that neither the form name nor schemaId are in the
escalation table.  You have to map the escalation.escalationId field to the
escal_mapping.escalationId field, and then use the schemaId column in
escal_mapping to get the Form Name from arschema.  That makes it tricky in
non-7.5 versions, because you'll have to do the joins in SQL.  In 7.5,
you can just join the view forms.  But you could probably accomplish the
same thing in any 7.x version by adding character fields to the escalations
view form for the schemaId and name, and then using workflow to pull the
data in.  As is usually the case in AR System, there are multiple ways to
skin that cat.
 
The tables and data appear to be named and formatted the same in all 7.x
versions, so it should migrate just fine.
 
Rick
On Wed, May 13, 2009 at 2:58 AM, Barber, David <[email protected]> wrote:
**
I'm interested about this - what is the relevant metatable to setup a view
over?
 
Ta
 
Dave

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]]on Behalf Of Rick Cook
Sent: 12 May 2009 16:33
To: [email protected]
Subject: Re: Escalation Timeline
** That would make sense. A view form over the metatable would be a great
way of managing that data from the UT. You could set workflow against it to
change them and everything. 

I love everything about that idea except that I didn't have it a year ago. 

Rick
Sent from my Verizon Wireless BlackBerry

________________________________________
From: "Grooms, Frederick W" 
Date: Tue, 12 May 2009 10:24:57 -0500
To: <[email protected]>
Subject: Re: Escalation Timeline
I did it with a query against the Escalation table in the database. 
Unfortunately it was a good while ago so I don't have the details right at
hand.
 
Fred
 
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Pruitt, Christopher J
Sent: Tuesday, May 12, 2009 10:18 AM
To: [email protected]
Subject: Re: Escalation Timeline
 
ARInside would have been great for this, we still use it but that product is
no longer available or supported. I am hoping some new product comes along
soon. I am holding out for ARSmarts, but so far I have not seen one.
 
Christopher Pruitt
Consultant Specialist
EDS, an HP Company
mailto: [email protected]
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Rick Cook
Sent: Tuesday, May 12, 2009 10:00 AM
To: [email protected]
Subject: Re: Escalation Timeline
 
Unless ARSmarts, Abydos, or some other tool does that, I don't know of a
way, either. I tried to think of one last year when looking at how to
multithread the escalations, and ended up just doing it manually. 

Rick
Sent from my Verizon Wireless BlackBerry

________________________________________
From: "Schryver, Curt" 
Date: Tue, 12 May 2009 10:52:33 -0400
To: <[email protected]>
Subject: Re: Escalation Timeline
I started tinkering with something just last week to do this exact thing. 
Didn't get too far, but will continue to play with it.  (Unless someone
comes forward with an already-functioning application)
 
Curt A. Schryver
717-810-2109 tel
[email protected]

________________________________________
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of O'Brien, Keith KOB. (Citco)
Sent: Tuesday, May 12, 2009 8:46 AM
To: [email protected]
Subject: Escalation Timeline
 
Hi,
Just wondering if there is a tool or process available to document the
timeline of all active escalations on a system.
 
Regards,
Keith.
 

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:[email protected] ARSlist: "Where the Answers Are"

This e-mail has been scanned for viruses by the Cable & Wireless e-mail
security system - powered by MessageLabs. For more information on a
proactive managed e-mail security service, visit
http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be
subject to legal privilege. It is intended only for the recipient(s) named
above. If you are not named above as a recipient, you must not read, copy,
disclose, forward or otherwise use the information contained in this email.
If you have received this e-mail in error, please notify the sender (whose
contact details are above) immediately by reply e-mail and delete the
message and any attachments without retaining any copies.
 
Cable and Wireless plc
Registered in England and Wales.Company Number 238525 Registered office: 3rd
Floor, 26 Red Lion Square, London WC1R 4HQ

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:[email protected] ARSlist: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"

Reply via email to