[rt-users] Catch all ticket changes in one scrip

2014-08-22 Thread andriusk
Hello, I'm trying to figure out, how can I catch all the changes made to ticket fields in one scrip. It would be like OnUpdateTicket script, which will gather all the changes made, and sync them with DB outside trought REST. Is there any solution, or maybe code example doing all of that in RT its

Re: [rt-users] Catch all ticket changes in one scrip

2014-08-22 Thread k...@rice.edu
On Fri, Aug 22, 2014 at 05:49:29AM -0700, andriusk wrote: > Hello, > > I'm trying to figure out, how can I catch all the changes made to ticket > fields in one scrip. > It would be like OnUpdateTicket script, which will gather all the changes > made, and sync them with DB outside trought REST. >

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-16 Thread andriusk
How should I make my TransactionBatch scrip run after all changes inducing scrip? Is it enought if it is the only scrip in batch mode? Because now I get this batch scrip run after every different type transaction (3 changes - status, subject, customfield - 3 times ran scrip in batch mode. Also I do

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-16 Thread Alex Peters
TransactionBatch scrips always run after TransactionCreate scrips. If it's running three times, it's quite possibly still applied to a queue (or globally) in Create mode. I test whether a scrip is running in batch mode using: if (my @txns = @{ $self->TicketObj->TransactionBatch }) { # batch

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-18 Thread andriusk
The last two transactions is because of SLA was changed and the due and priority must be changed accordingly. How can I get my scrip run after these two last transactions, because now it is ran first (Found 1 scrips for TransactionBatch stage with applicable type(s) Status,Set,SetWatcher,Cust

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-18 Thread Alex Peters
It sounds like the SLA extension is performing its work after all scrips run instead of before TransactionBatch scrips. I would be inclined to suggest that this is an SLA bug/oversight, as its current design doesn't seem to permit proper execution of TransactionBatch scrips and its documentation d

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread andriusk
I would try to explain my situation again. I want to make "AfterAllTicketChanges" scrip, which will work in TransactionBatch mode, and fire after all changes to the ticket was made on update off any ticket information. Now, when I change the SLA field, it changes the the Due and the priority of t

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread Alex Peters
Scenario #2 is the expected behaviour according to all scrip documentation included with RT. The SLA extension appears to be contradicting this. Therefore, I still believe that the SLA extension is at fault and that a bug report for the SLA extension should be submitted via the URL given in my pre

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread andriusk
I think that the Due and Priority may be the problem. Here I changed Subject, Status, Due, Priority (SLA not changed), and still I get separate TransactionBatch run for each (Subject,Status), (Due), (Priority). The last two fires two separate Batch Scrip commits. -- View this message in conte

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread Alex Peters
Please supply a debug log covering the above updates. Is it possible that the scrip is not applied to the relevant queue in batch mode? On 20/09/2014 12:54 am, "andriusk" wrote: > > > I think that the Due and Priority may be the problem. Here I changed > Subject, Status, Due, Priority (SLA not c

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread Kevin Falcone
On Sat, Sep 20, 2014 at 12:44:46AM +1000, Alex Peters wrote: > When you change a ticket's subject and status in a single update, two > transactions are created.  A TransactionBatch scrip should run only once for > both transactions.  The SLA extension seems to be interfering with this > expected be

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread andriusk
There is only one scrip in TransactionBatch mode applied to my test Queue. -- View this message in context: http://requesttracker.8502.n7.nabble.com/Catch-all-ticket-changes-in-one-scrip-tp58372p58586.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Traini

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-19 Thread Alex Peters
I still suspect that the SLA extension is interfering, but without a debug log it's almost impossible to offer any further suggestions. On 20/09/2014 1:10 am, "andriusk" wrote: > > > > There is only one scrip in TransactionBatch mode applied to my test Queue. > > > > -- > View this message in con

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-22 Thread andriusk
I made a new installation. This is the log, which I got from changing tickets /*Subject, Status, Priority and Due*/ on queue */General/* with /*1 scrip in TransactionBatch*/ mode (CustomCondition: 1; Custom action preparation code: 1; Custom action commit code: 1;), no extensions installed. [1029

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-22 Thread Alex Peters
You have established beyond doubt that the SLA extension is breaking core scrip logic. Please file a bug report against the SLA extension. On 22/09/2014 6:41 pm, "andriusk" wrote: > I made a new installation. > This is the log, which I got from changing tickets /*Subject, Status, > Priority and

Re: [rt-users] Catch all ticket changes in one scrip

2014-09-24 Thread andriusk
Another question. Are the transactions of changes to a ticket made by web UI (fields selected in web ui) and by scrips, that change some other value because one of values was changed by UI, assigned to the same TransactionBatch? 2014-09-23 02:24, Alex Peters [via RequestTracker] rašė: > > You h