Backdating transactions

We have had a few cases where it would be useful to change the date on
a transaction. Transaction->SetCreated doesn’t appear to change the
value - is this a bug and/or is there a cleaner way to do this other
than updating the database directly?

Chris

It’s no bug that RT doesn’t let you change the past. I would hit the DB
directly.On Thu, Feb 12, 2009 at 12:28 PM, Chris Adams chris@improbable.org wrote:

We have had a few cases where it would be useful to change the date on
a transaction. Transaction->SetCreated doesn’t appear to change the
value - is this a bug and/or is there a cleaner way to do this other
than updating the database directly?

Chris


List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

It’s no bug that RT doesn’t let you change the past. I would hit the
DB directly.

Bug was definitely too strong - I guess I was just thinking that it
seems like this ended up being surprisingly invasive. Here’s what the
final code ended up looking like - one curiosity which this exposed is
that on my 3.8.2 install simply displaying Update.html will create a
transaction.

Chris

Interface/Web_Local.pm

ProcessUpdateMessage: copied & added to the %message_args
initialization:
if ($args{ARGSRef}->{‘Created’}) {
$message_args{‘Created’} = $args{ARGSRef}->{‘Created’};
}

RT/Ticket_Local.pm:

_RecordNote: copied and added after _NewTransaction call:

if ( $args{'Created'} ) {
  RT::Logger->warning("Updating transaction #" . $TransObj->id .  

": setting created date to " . $args{‘Created’} );
$TransObj->_Handle->UpdateRecordValue( Table => ‘Transactions’,
Column => ‘Created’, Value => $args{‘Created’}, PrimaryKeys => { id =>
$TransObj->id } );
}

Ticket/Update.html - forked to add the date select since there’s not a
callback for it and running the field through RT::date:

+

$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, results =>
@results, CallbackName => ‘Initial’ );

+if ( $ARGS{‘Created’} ) {

  •   my $created_date = RT::Date->new( $TicketObj->CurrentUser );
    
  •   $created_date->Set( Format => 'Unknown', Value =>  
    

$ARGS{‘Created’}, Timezone => “user” );

  •   $ARGS{'Created'} = $created_date->ISO;
    

+}

smime.p7s (2.37 KB)

<&|/l&>Date: <& /Elements/ SelectDate, Name => "Created", Default => undef &>

Displaying Update.html prepares a transaction so it can tell you who would
be emailed, but the transaction isn’t committed.2009/2/12 Chris Adams chris@improbable.org

On Feb 12, 2009, at 3:19 PM, Todd Chapman wrote:

It’s no bug that RT doesn’t let you change the past. I would hit the DB
directly.

Bug was definitely too strong - I guess I was just thinking that it seems
like this ended up being surprisingly invasive. Here’s what the final code
ended up looking like - one curiosity which this exposed is that on my 3.8.2
install simply displaying Update.html will create a transaction.

Chris

Interface/Web_Local.pm

ProcessUpdateMessage: copied & added to the %message_args initialization:
if ($args{ARGSRef}->{‘Created’}) {
$message_args{‘Created’} = $args{ARGSRef}->{‘Created’};
}

RT/Ticket_Local.pm:

_RecordNote: copied and added after _NewTransaction call:

if ( $args{‘Created’} ) {
RT::Logger->warning(“Updating transaction #” . $TransObj->id . ":
setting created date to " . $args{‘Created’} );
$TransObj->_Handle->UpdateRecordValue( Table => ‘Transactions’, Column
=> ‘Created’, Value => $args{‘Created’}, PrimaryKeys => { id =>
$TransObj->id } );
}

Ticket/Update.html - forked to add the date select since there’s not a
callback for it and running the field through RT::date:

+

$m->callback( Ticket => $TicketObj, ARGSRef => %ARGS, results =>
@results, CallbackName => ‘Initial’ );

+if ( $ARGS{‘Created’} ) {

  •   my $created_date = RT::Date->new( $TicketObj->CurrentUser );
    
  •   $created_date->Set( Format => 'Unknown', Value => $ARGS{'Created'},
    

Timezone => “user” );

  •   $ARGS{'Created'} = $created_date->ISO;
    

+}
+


List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

<&|/l&>Date: <& /Elements/SelectDate, Name => "Created", Default => undef &>

Displaying Update.html prepares a transaction so it can tell you who
would be emailed, but the transaction isn’t committed.

What I wasn’t expecting is that it permanently commits an id number -
shouldn’t that require a database commit?

Chris

smime.p7s (2.37 KB)

This sounds a lot like
http://www.gossamer-threads.com/lists/rt/users/63718#63718

Chris Adams wrote:

Displaying Update.html prepares a transaction so it can tell you who
would be emailed, but the transaction isn’t committed.

What I wasn’t expecting is that it permanently commits an id number -
shouldn’t that require a database commit?

Chris


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati

This sounds a lot like http://www.gossamer-threads.com/lists/rt/users/63718#63718

It sounds somewhat similar but I’m using Postgres (which is always
transactional). The empty transaction isn’t displayed but it
definitely ends up in the database:

rt3=> SELECT * FROM Transactions ORDER BY id DESC LIMIT 5;
id | objecttype | objectid | timetaken | type | field |
oldvalue | newvalue | referencetype | oldreference | newreference |
data | creator | created
4807 | RT::Ticket | 194 | 0 | Comment |
| | | | | |
No Subject | 30 | 2009-02-12 18:37:00

Chris

smime.p7s (2.37 KB)