Adding a per queue template to a scrip in the Perl API

I’ve been doing a spot of hacking using the RT Perl API to manage/munge scrips and templates (hopefully to allow Ansible to deploy updated scrips/templates from one RT instance to another eventually).

However, when using the RT::Scrip->AddToObject() method, it seems to blow up if I specify a Template (a string identifying the template) in the parameter hash. I was thinking this was how a scrip is tied to a queue specific template. The code fragment looks like this:

my ($ret, $msg) = $scrip->AddToObject(
            ObjectId  => $queueObj->id,
            Template  => 'Blank',
);

From the error tracing his appears to die because that method ends up trying to run:

INSERT INTO ObjectScrips (LastUpdatedBy, Template, Stage, Created, Creator, ObjectId, SortOrder, Scrip, LastUpdated) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)

and there isn’t a Template column in the ObjectScrips table.

This is with a 5.0.7 RT (upgraded from 5.0.5), and the RT documentation seems to say that Template is a valid parameter to that method. If I remove the Template parameter and then add in other parameters given in the documentation such as Stage or SortOrder the call works OK.

So am I doing something stupid, or is there a bug in either the documentation or the RT code? Do I even need to specify the template I want to use per queue, or should it just be the same template name in the RT::Scrip object and RT’s logic will find the per queue version at run time?

Hey,

Looking in RT::Scrip::AddToObject it has:

    my $tname = $self->Template;
    my $template = RT::Template->new( $self->CurrentUser );
    $template->LoadByName( Queue => $queue? $queue->id : 0, Name => $tname );

So you need to set the Template on the Scrip object first, before calling AddToObject.

Probably with $scrip->SetTemplate($tname);

Cheers,
Andrew

Thanks for that. Unfortunately adding a $script->SetTemplate() call just before the AddToObject() call doesn’t seem to help - I still get the errors about an unknown column ‘Template’ in the field list. I even tried experimentally setting the template to 'Blank' which should always be there and it still errors.

FWIW, here the extract of the relevant calls from my script (with the template name set to always be Blank):

        ($ret, $msg) = $scrip->SetTemplate('Blank');
        if(!$ret && $msg ne 'That is already the current value') {
            print "Could not set the template: $msg\n";
        }
        ($ret, $msg) = $scrip->AddToObject(
            ObjectId  => $queueInfo->{'queue-name'},
            Stage     => $queueInfo->{'stage'} || 'TransactionCreate',
            SortOrder => $queueInfo->{'sort-order'} || undef,
            Template  => 'Blank',
            );
        if(!$ret && $msg ne 'Is already added to the object') {
            print "Could not add scrip '" . $scrip->Description .
                "' to queue '" . $queueInfo->{'queue-name'} . "': $msg\n";
       }

The $queueInfo is just a Perl hash reference that contains the queue name and potentially a few other things such as the scrip stage, the sort order and the template name. That last conditional print statement triggers and I get the output on STDOUT:

Could not add scrip 'New Test Scrip in the MALS queue' to queue 'MALS': Internal Error: Couldn't execute the query 'INSERT INTO ObjectScrips (SortOrder, Created, Template, LastUpdated, Scrip, Creator, ObjectId, LastUpdatedBy, Stage) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)'Unknown column 'Template' in 'field list'

If I remove the Template parameter from the AddToObject() call it doesn’t error, but I’m not sure if I’m missing some aspect of adding a per-queue template now that will come back to bite me later.

Ah, I think you need to not pass in Template when you call AddToObject. That function passes the args directly to RT::ObjectScrip, and that module doesn’t store the Template in the database. When looked at the ObjectScrip table there is no Template field.

Yes, that’s the conclusion I’m coming to. But the documentation says that there is a Template parameter to pass in, which I think is a bug. I think I’ll file a bug report with Best Practical and see what they say.

Reported to BP as a bug. Thanks for confirming I’m not going potty Andrew (well, no more potty than normal at least!)