-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jonathan,
first thx for the work on OTRS-Ticketer plugin. I will try the new
features this
week and can give you a feedback for the current state.
Btw. I think it sounds nice to move the ticketer-stuff into extra
packages. So
you can decide wh
On 10 Nov 2008, at 18:41, jonathan sartin wrote:
>
> On 10 Nov 2008, at 03:10, David Hustace wrote:
>>
>> After thinking about this a while, I wonder if adding a few more
>> ticket states for which the service layer could check would be in
>> order. Such as CREATE_FAILED/UPDATE_FAILED/CLOSE_FAIL
On 10 Nov 2008, at 03:10, David Hustace wrote:
>
> After thinking about this a while, I wonder if adding a few more
> ticket states for which the service layer could check would be in
> order. Such as CREATE_FAILED/UPDATE_FAILED/CLOSE_FAILED states.
> Each of these could generate events->a
On Nov 7, 2008, at 2:35 PM, jonathan sartin wrote:
This results from communications failure with the remote ticketing
system and can leave the alarm in a incorrect state. I intend to add
an exception to the Plugin interface that can be thrown if the
remote connection fails. That way, the s
I would agree to that.
Setting a failure on an alarm, would also enable re-issuing of ticket
opening?
That would fix a short outage on the ticketing side.
On Nov 7, 2008, at 12:35 PM, jonathan sartin wrote:
All,
we've noticed that implementations of
org.opennms.api.integration.ticketing
On Nov 7, 2008, at 2:35 PM, jonathan sartin wrote:
> What do you think?
I like it. Can't think of anything you've missed.
-jeff
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coole
All,
we've noticed that implementations of
org.opennms.api.integration.ticketing.Plugin don't have a way of
telling the service layer that a get, save or update has failed. This
results from communications failure with the remote ticketing system
and can leave the alarm in a incorrect st
