Problem cascading state update event

[voiprodrigo]

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.

[eandrex]

Well, maybe start showing us the code of your Module 1 and how you registered it in your OTRS

And when you say

Code: Select all

certain database changes will happen

do you modify the OTRS DB directly or using OTRS API?

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. 

You dont need a custom module.. you can do it using generic agent

[voiprodrigo]

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:

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>

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.

[eandrex]

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

[voiprodrigo]

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..

[eandrex]

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:

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
}

If you go that way, copy your "Module 1" to "Custom" folder (conserving directory structure)