Hello,
I have a situation where I need two cascading reactions to a state change.
If ticket changes from state A to state B, certain database changes will happen. This is handled by module 1.
If ticket changes from state A to state B, ticket will revert back to state A. This is handled by module 2, which accesses $OldTicketData and then calls TicketStateUpdate().
If I enable module 2 (which is set to run *after* module 1, in the configuration) it does what it's supposed, BUT I don't see the effect of module 1.
Any hints on what could be the problem with this?
Thanks.
Problem cascading state update event
-
- Znuny newbie
- Posts: 62
- Joined: 03 Dec 2014, 18:49
- Znuny Version: OTRS 4
- Location: Portugal
- Contact:
Problem cascading state update event
Linux (Ubuntu 14.04.1 LTS) | MySQL 5.5.40 | OTRS 4.0.7
-
- Znuny expert
- Posts: 213
- Joined: 04 Nov 2012, 23:58
- Znuny Version: OTRS 4.x
- Real Name: Esteban
- Company: NORTON DE COLOMBIA
Re: Problem cascading state update event
Well, maybe start showing us the code of your Module 1 and how you registered it in your OTRS
And when you say
do you modify the OTRS DB directly or using OTRS API?
by the way, to do this
You dont need a custom module.. you can do it using generic agent
And when you say
Code: Select all
certain database changes will happen
by the way, to do this
Code: Select all
If ticket changes from state A to state B, ticket will revert back to state A.
-
- Znuny newbie
- Posts: 62
- Joined: 03 Dec 2014, 18:49
- Znuny Version: OTRS 4
- Location: Portugal
- Contact:
Re: Problem cascading state update event
Hi,
I skipped some details, Module 1 is actually from a complex xxx extension for escalation management. So everything it does is, I assume, completely proper. Changing anything in that extension is out of the question. It's registered with Name="Ticket::EventModulePost###901-EscalationIndex", and Transaction key value is 1.
My module is registered like this:
You say I don't need a module for the other function, can you give me more details? I explored that, and I really don't see how to make GenericAgent switch to previous state.
tks.
I skipped some details, Module 1 is actually from a complex xxx extension for escalation management. So everything it does is, I assume, completely proper. Changing anything in that extension is out of the question. It's registered with Name="Ticket::EventModulePost###901-EscalationIndex", and Transaction key value is 1.
My module is registered like this:
Code: Select all
<otrs_config version="1.0" init="Changes">
<ConfigItem Name="Ticket::EventModulePost###99999-ResetStateFromWorkaround" Required="0" Valid="0">
<Description Lang="en"></Description>
<Description Lang="de"></Description>
<Group>EventModulePostTemplate</Group>
<SubGroup>EventModule</SubGroup>
<Setting>
<Hash>
<Item Key="Module">Kernel::System::Ticket::Event::ResetStateFromWorkaround</Item>
<Item Key="Event">TicketStateUpdate</Item>
<Item Key="Transaction">0</Item>
</Hash>
</Setting>
</ConfigItem>
</otrs_config>
tks.
Linux (Ubuntu 14.04.1 LTS) | MySQL 5.5.40 | OTRS 4.0.7
-
- Znuny expert
- Posts: 213
- Joined: 04 Nov 2012, 23:58
- Znuny Version: OTRS 4.x
- Real Name: Esteban
- Company: NORTON DE COLOMBIA
Re: Problem cascading state update event
Hi,
So you say that Module 1 is provided by xxx. My question is, it stops working after you enable your custom "Module 2" or if it doesnt work at all? if it doesnt work at all, your best bet is asking them directly for support.
On the other hand, if it stops working right after you enable your module, probably your module is being execute first which changes the ticket itself and therefore *conditions* of the module 1 never match.
About the generic agent, it maybe tedious depending of your needs. If there is only one state which you want to revert whenever it is changed, it is quite easy:
In the generic agent, in the filter section, select the state you want to revert whenever a ticket is set to it (for example closed succesful), after that, in ticket action, select the "old" state the ticket is supposed to be (for example open).
From the examples above, whenever a ticket changes to state "closed succesful" it is being changed againt to "open"..
if i understood you correclty, that should do the trick
So you say that Module 1 is provided by xxx. My question is, it stops working after you enable your custom "Module 2" or if it doesnt work at all? if it doesnt work at all, your best bet is asking them directly for support.
On the other hand, if it stops working right after you enable your module, probably your module is being execute first which changes the ticket itself and therefore *conditions* of the module 1 never match.
About the generic agent, it maybe tedious depending of your needs. If there is only one state which you want to revert whenever it is changed, it is quite easy:
In the generic agent, in the filter section, select the state you want to revert whenever a ticket is set to it (for example closed succesful), after that, in ticket action, select the "old" state the ticket is supposed to be (for example open).
From the examples above, whenever a ticket changes to state "closed succesful" it is being changed againt to "open"..
if i understood you correclty, that should do the trick
-
- Znuny newbie
- Posts: 62
- Joined: 03 Dec 2014, 18:49
- Znuny Version: OTRS 4
- Location: Portugal
- Contact:
Re: Problem cascading state update event
Hi,
It stops working only when I enable my module. I considered the possibility that my module prevents the other of observing the first state change, as I change it back, but I was also under the impression that event processing happened in parallel, and for that reason it would allow this to work as I imagined.
As for the generic agent, there's multiple origin "a" states, and multiple "b" states (which share a common prefix). So I can't configure a GA job covering it all, due to lack of 1to1 relationship on the state transition.
I tried calling custom module via GA to avoid that interference, but I don't know how to access $OldTicketData in there, because the module only receives ticket Id I think. Then again, just occurred, I can probably get that info from the ticket history..
It stops working only when I enable my module. I considered the possibility that my module prevents the other of observing the first state change, as I change it back, but I was also under the impression that event processing happened in parallel, and for that reason it would allow this to work as I imagined.
As for the generic agent, there's multiple origin "a" states, and multiple "b" states (which share a common prefix). So I can't configure a GA job covering it all, due to lack of 1to1 relationship on the state transition.
I tried calling custom module via GA to avoid that interference, but I don't know how to access $OldTicketData in there, because the module only receives ticket Id I think. Then again, just occurred, I can probably get that info from the ticket history..
Linux (Ubuntu 14.04.1 LTS) | MySQL 5.5.40 | OTRS 4.0.7
-
- Znuny expert
- Posts: 213
- Joined: 04 Nov 2012, 23:58
- Znuny Version: OTRS 4.x
- Real Name: Esteban
- Company: NORTON DE COLOMBIA
Re: Problem cascading state update event
Kinda weird what you are expecting.. and without source code it gets a bit harder to help you.. what I'd do in your case,would be edit Module 1 and from there Invoke your module 2..
if Module1 fires on events, it should hold the old ticket data you are looking for
so I'd do something like this
Module 1:
If you go that way, copy your "Module 1" to "Custom" folder (conserving directory structure)
if Module1 fires on events, it should hold the old ticket data you are looking for
so I'd do something like this
Module 1:
Code: Select all
..
use Kernel::System::...::Module2;
sub new{
..
$Self->{MyModule2Object} = Kernel::System::...::Module2->new( %{$Self} );
return $Self;
}
..
sub Run {
..
$Self->{MyModule2Object}->Run( %Param );
return 1; ## or whatever
}