SLA extension with prior Scrip setting SLA CF

We ran into a problem that I think may be solvable with use of TransactionBatch, but may
require changes to the SLA extension. Or perhaps not. Thus this question, which is…

We are using the ExtractCustomFieldValues extension to indicate to RT the initial setting
of some fields, including the SLA field, depending on various factors examined in our
procmail pre-filter. What we found was that the field was set, then the SLA scrip resets
it to the default queue value. It seems that this is because all the conditions run first
telling the SLA scrip to set the default value, which it does even though the value had
been set previously.

So… what would be the recommended solution here to make sure this doesn’t happen? I
could move the ExtractCFValues Scrip to the bottom, which seems like it would work, but it
would be nice if the SLA Scrip realized it doesn’t actually need to set the CF once it was
set. If we change both to TransactionBatch, this could work, but I assume this would
still require some changes to the SLA condition logic.

Thanks,
MarkMark D. Nagel, CCIE #3177 mnagel@willingminds.com
Principal Consultant, Willing Minds LLC (http://www.willingminds.com)
cell: 949-279-5817, desk: 714-495-4001, fax: 714-646-8277

** For faster support response time, please
** email support@willingminds.com or call 714-495-4000

We ran into a problem that I think may be solvable with use of TransactionBatch, but may
require changes to the SLA extension. Or perhaps not. Thus this question, which is…

We are using the ExtractCustomFieldValues extension to indicate to RT the initial setting
of some fields, including the SLA field, depending on various factors examined in our
procmail pre-filter. What we found was that the field was set, then the SLA scrip resets
it to the default queue value. It seems that this is because all the conditions run first
telling the SLA scrip to set the default value, which it does even though the value had
been set previously.

So… what would be the recommended solution here to make sure this doesn’t happen? I
could move the ExtractCFValues Scrip to the bottom, which seems like it would work, but it
would be nice if the SLA Scrip realized it doesn’t actually need to set the CF once it was
set. If we change both to TransactionBatch, this could work, but I assume this would
still require some changes to the SLA condition logic.

Changing both to the transaction batch stage will have the same problem.
You need to put them in different stages, so move the SLA scrip which
assigns the queue default to the TransactionBatch stage. I don’t think
it should negatively affect anything else.

We ran into a problem that I think may be solvable with use of TransactionBatch, but may
require changes to the SLA extension. Or perhaps not. Thus this question, which is…

We are using the ExtractCustomFieldValues extension to indicate to RT the initial setting
of some fields, including the SLA field, depending on various factors examined in our
procmail pre-filter. What we found was that the field was set, then the SLA scrip resets
it to the default queue value. It seems that this is because all the conditions run first
telling the SLA scrip to set the default value, which it does even though the value had
been set previously.

So… what would be the recommended solution here to make sure this doesn’t happen? I
could move the ExtractCFValues Scrip to the bottom, which seems like it would work, but it
would be nice if the SLA Scrip realized it doesn’t actually need to set the CF once it was
set. If we change both to TransactionBatch, this could work, but I assume this would
still require some changes to the SLA condition logic.

Changing both to the transaction batch stage will have the same problem.
You need to put them in different stages, so move the SLA scrip which
assigns the queue default to the TransactionBatch stage. I don’t think
it should negatively affect anything else.

One small problem - you may run into issues if making the SLA Scrip
TransactionBath on RT4 if you’re not running at least 4.0.8 (I fixed an
RT bug when Best Practical made our SLA Scrip TransactionBath).

-kevin