TransactionBatch state rework + scrip code clean up

Hello.

  1. Backward compatibility saved.
  2. Now all transactions checked for Applicability when one is triggered
    it’s used in call to prepare and execute. It allow use RT generic
    actions in batch state. In old code scrips could be skipped cause only
    first trx was checked with condition.

Clean ups:
1) no self caching in scrip object
2) so no direct calls for DESTROY

Waiting for feedback. Ruslan.

batches.patch (7.25 KB)

I haven’t looked into this yet – but your post prompted me to think
about it now. Can I cancel the creation (before it happens) of a new
transaction (for instance, addition of “correspondence”) via a scrip?
(I want to run some custom perl code that will make a "rights"
judgement, partially based on the incoming mail from: address.)

Is this possible with stock RT, or is it something that this patch
adds/fixes?

Thanks!

I haven’t looked into this yet – but your post prompted me to think
about it now. Can I cancel the creation (before it happens) of a new
transaction (for instance, addition of “correspondence”) via a scrip?
(I want to run some custom perl code that will make a “rights”
judgement, partially based on the incoming mail from: address.)

I’m not sure about your particular usage, but this might be easier in
procmail. If you don’t want RT to get the mail, seems like it might be
better to keep it from getting there at all…

seph

Hello.
I don’t know where should I put text. I added few lines to pod and below
text which should be put somewhere.

Scrip stages:
Scrips can be applied in different stages: ‘TransactionCreate’ and
’TransactionBatch’.
In TransactionCreate stage scrip applied right after transaction is
created and can be committed more then once during one request for each
transaction which is applicable.
In TrabsactionBatch stage scrip applied only once during request when
all transactions are created and all scrips in TransactionCreate stage
already applied. Scrip aplied only once even if batch contain more then
one applicable transaction.
For backward compatibilty reasons and to allow using same scrip action
in both stages $ScripActionObj->TransactionObj return first transaction
which is applicable in batch. You can get full batch with
$TicketObj->TransactionBatch call which return array reference. Array
contain transaction objects ordered by create time.

Example:
User’s request creates transactions in next order: a b c d e.
Scrip has condition which trigger b and d transaction.

If scrip in TransactionCreate stage then

  1. scrip’s action will be committed two times.
  2. First time $TicketObj->TransactionBatch will return [a_obj b_obj] and
    $ScripActionObj->TransactionObj will return b_obj.
  3. Second time it’ll be [a_obj b_obj c_obj d_obj] and
    $ScripActionObj->TransactionObj will return d_obj.

If scrip in TransactionBatch stage

  1. scrip’s action will be committed only once.

  2. $TicketObj->TransactionBatch will return [a_obj b_obj c_obj d_obj
    e_obj] and $ScripActionObj->TransactionObj will return b_obj(first
    transaction which triggered condition).

     	Best regards. Ruslan.
    

batches.patch (8.28 KB)