What is stage under creating scrips?

RT Users
1

When one creates a scrip for a queue, there is a dropdown field for
Stage which contains TransactionCreate and TransactionBatch. What are
they, and how does one choose which on to use?

Thanks,

-jeff

2

Jeff Minelli wrote:

When one creates a scrip for a queue, there is a dropdown field for
Stage which contains TransactionCreate and TransactionBatch. What are
they, and how does one choose which on to use?
Wow.
If I understand right it’s most impressive feature in last version.
One request to WebUI can create more then one transaction.
Eg: Resolve = Status change + Reply or Comment + …

In some case it’s very hard to write complex scrip because RT execute
each scrip just after each triggered transaction creation.

If it’s true then it’s wonderful.
Best regards. Ruslan.

3

Ruslan U. Zakirov a écrit :

Jeff Minelli wrote:

When one creates a scrip for a queue, there is a dropdown field for
Stage which contains TransactionCreate and TransactionBatch. What are
they, and how does one choose which on to use?

The response is “TransactionCreate” which is original RT behaviour.

Wow.
If I understand right it’s most impressive feature in last version.
One request to WebUI can create more then one transaction.
Eg: Resolve = Status change + Reply or Comment + …

From what I read from sources, I think the following events happen in
this order (based on your sample) :

During request :

  1. “Status change” triggers scrips at TransactionCreate stage,
  2. “Reply” triggers scripts at TransactionCreate stage.

At end of Ticket object lifetime :

  1. “Status change” triggers scrips at TransactionBatch stage,
  2. “Reply” triggers scrips at TransactionBatch stage.

The tricky point is “end of Ticket object lifetime” that sounds to me
like “at random” but I may be wrong.

Except this point, it seems to be a very interesting feature.

I also heard about separating actions’ “prepare” and “commit” phases to
prepare all actions then to commit them all instead of preparing then
commiting each action before the next one. What about this for now ?

Best regards,

Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

4

Guillaume Perr�al wrote:

Ruslan U. Zakirov a �crit :

Jeff Minelli wrote:

When one creates a scrip for a queue, there is a dropdown field for
Stage which contains TransactionCreate and TransactionBatch. What are
they, and how does one choose which on to use?

The response is “TransactionCreate” which is original RT behaviour.

Wow.
If I understand right it’s most impressive feature in last version.
One request to WebUI can create more then one transaction.
Eg: Resolve = Status change + Reply or Comment + …

From what I read from sources, I think the following events happen in
this order (based on your sample) :

During request :

  1. “Status change” triggers scrips at TransactionCreate stage,
  2. “Reply” triggers scripts at TransactionCreate stage.

At end of Ticket object lifetime :

  1. “Status change” triggers scrips at TransactionBatch stage,
  2. “Reply” triggers scrips at TransactionBatch stage.

The tricky point is “end of Ticket object lifetime” that sounds to me
like “at random” but I may be wrong.
I didn’t look at sources yet, but I think lifetime == apache request
circle. As I know main code and SearchBuilder cache system all instances
drop after respond was sent to user back.

Except this point, it seems to be a very interesting feature.

I also heard about separating actions’ “prepare” and “commit” phases to
prepare all actions then to commit them all instead of preparing then
commiting each action before the next one. What about this for now ?
Didn’t track all RT changes in last releases and skip this feature also.
Anounce is silent about it too. Thanks Jeff for bringing to light.
:slight_smile:

I’m going to upgrade ASAP. I need this feature.

5

The tricky point is “end of Ticket object lifetime” that sounds to me
like “at random” but I may be wrong.
I didn’t look at sources yet, but I think lifetime == apache request
circle. As I know main code and SearchBuilder cache system all instances
drop after respond was sent to user back.

Ruslan, you’ve got it right.

Didn’t track all RT changes in last releases and skip this feature also.
Anounce is silent about it too. Thanks Jeff for bringing to light.
:slight_smile:

Sorry about that. There’s a small bug in that It was only supposed to
appear if you’d set a flag in the config file. But I guess there isn’t
much point in that now :wink:

Best
Jesse

I’m going to upgrade ASAP. I need this feature.

Best regards,

rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.