Backdating transactions

Chris_Adams · February 12, 2009, 5:28pm

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

Todd_Chapman1 · February 12, 2009, 8:19pm

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:
The rt-devel Archives

Chris_Adams · February 13, 2009, 3:02am

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:

+

…

$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 &>

Todd_Chapman1 · February 13, 2009, 4:58am

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:
+
…
$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:
The rt-devel Archives
<&|/l&>Date: <& /Elements/SelectDate, Name => "Created", Default => undef &>

Chris_Adams · February 13, 2009, 3:26pm

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)

Drew_Barnes · February 13, 2009, 3:33pm

This sounds a lot like

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: The rt-devel Archives

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

Chris_Adams · February 13, 2009, 4:16pm

This sounds a lot like Carbon60: Managed Cloud Services

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:

Chris

smime.p7s (2.37 KB)