Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Devel

Backdating transactions

 

 

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded


chris at improbable

Feb 12, 2009, 9:28 AM

Post #1 of 7 (1265 views)
Permalink
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
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


todd at chaka

Feb 12, 2009, 12:19 PM

Post #2 of 7 (1211 views)
Permalink
Re: Backdating transactions [In reply to]

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 [at] improbable> 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
>


chris at improbable

Feb 12, 2009, 7:02 PM

Post #3 of 7 (1212 views)
Permalink
Re: Backdating transactions [In reply to]

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:
<table width="100%" border="0">
+<tr><td class="label"><&|/l&>Date</&>:</td><td><& /Elements/
SelectDate, Name => "Created", Default => undef &></td></tr>

...

$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;
+}
+
Attachments: smime.p7s (2.37 KB)


todd at chaka

Feb 12, 2009, 8:58 PM

Post #4 of 7 (1199 views)
Permalink
Re: Backdating transactions [In reply to]

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 [at] improbable>

>
> 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:
> <table width="100%" border="0">
> +<tr><td class="label"><&|/l&>Date</&>:</td><td><& /Elements/SelectDate,
> Name => "Created", Default => undef &></td></tr>
>
> ...
>
> $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
>
>


chris at improbable

Feb 13, 2009, 7:26 AM

Post #5 of 7 (1194 views)
Permalink
Re: Backdating transactions [In reply to]

On Feb 12, 2009, at 11:58 PM, Todd Chapman 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
Attachments: smime.p7s (2.37 KB)


barnesaw at ucrwcu

Feb 13, 2009, 7:33 AM

Post #6 of 7 (1204 views)
Permalink
Re: Backdating transactions [In reply to]

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

Chris Adams wrote:
>
> On Feb 12, 2009, at 11:58 PM, Todd Chapman 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

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


chris at improbable

Feb 13, 2009, 8:16 AM

Post #7 of 7 (1198 views)
Permalink
Re: Backdating transactions [In reply to]

On Feb 13, 2009, at 10:33 AM, Drew Barnes wrote:
> 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
Attachments: smime.p7s (2.37 KB)

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.