For simplicity sake, let's consider taking a Ticket Event and make it happen via Generic Agent.
Why would you do that?
Well, let's say you have made a new Ticket Event, but you want to apply its affects retroactively to tickets already in your database.
More or less, you'll copy the ticket event and rename it inside Kernel/System/GenericAgent
Make sure you update the package name, in the code, too.
Sometimes GenericAgent doesn't have all the Objects you need, so you'll need to
Code: Select all
use Kernel::System::State
Code: Select all
# get needed objects
for (
qw( ConfigObject DBObject LogObject MainObject TicketObject TimeObject EncodeObject)
)
Code: Select all
$Self->{StateObject} = Kernel::System::State->new( %{$Self} );
Code: Select all
create an object
use Kernel::Config;
use Kernel::System::Encode;
use Kernel::System::Log;
use Kernel::System::Main;
use Kernel::System::DB;
use Kernel::System::Time;
use Kernel::System::Queue;
use Kernel::System::Ticket;
use Kernel::System::GenericAgent;
If you have code in the Event that says, "Do _this_ if the Event is TicketUpdate, and do _this_ if the Event is TicketCreate", you may decide to change that logic to reflect the state of the ticket as it exists at run of the generic agent.
When you get down to it, the sub new and sub Run are otherwise the same. Of course, that's what an API is all about.
Then, you'll need to add an entry into Kernel/Config/GenericAgent.pm or, optionally, your own config file:
This is rather straight forward, and you'll add an entry like this before the }; end of config options :
Code: Select all
# --
# [name of job] -> A job to run on a bunch of tickets.
# --
'TicketEventAsGenericAgent' => {
#closed tickets are unlocked.
#you always need a filter. Locks => ['unlock', 'lock'] is/should be all tickets.
Locks => ['unlock'],
New => {
Module => 'Kernel::System::GenericAgent::TicketEventAsGenericAgent',
},
},
Since this is not in the db, it will need to either be run from the command line or via cron.
By default, otrs/var/cron/generic_agent.dist is in, but needs to have .dist removed if you want to run the job via cron. If the entr[y|ies] [is|are] in GenericAgent.pm, just run otrs/bin/otrs.GenericAgent.pl to run it manually, but if you need a specific config file, use the
Code: Select all
-c "Kernel::Config::GenericAgentYourInfoHere"
Note that there's also a generic_agent-database.dist, which when the .dist is removed will run GenericAgent every 10 minutes against the valid GenericAgent entries in the database. This appears to supersede the per-entry timing stored in the db.
Note: to be clear, when otrs.GenericAgent.pl runs, all of the entries in the config file it references will be run. If you want to separate times for a specific entry, you will want to separate the config for that entry.
Update: If you're going to apply an API to closed tickets, note that the ticket_history will be adjusted with the last closed state and timestamped with the action that was applied. This will hurt your reporting because closed times affected by API calls that leave history will now be set to the timestamp of when Generic Agent was run.
example:
Ticket was closed on 1/1/2010.
You run a ticket set action that affects closed tickets (Here, retroactively on closed tickets).
Ticket now is "closed" at time of run of Generic Agent.
To fix that may require removal of that/those ticket history action via SQL or other means.
Questions directly related to this tutorial (especially, I don't understand ...) will be answered here. Questions for *your* GenericAgent should be made in the forums.