Migration scripts lose keywords and priorities

Hi again!

The migration scripts have imported all the data from the dumps, as before,
but it’s lost some information.

The tickets themselves contain all the priority changes that have been made,
but the listed priority that the tickets are being sorted by on the front
page is the one that the ticket was originally created with. Any way to fix
up the priorities to the most recent set value?

Also, while the tickets themselves still have the names of the Custom Fields
set from the previous install Keywords, they don’t contain any values – the
actual contents of the Keywords table hasn’t been migrated.

e.g. on the Ticket display page, you can see
Custom Fields
OS: (no value)
Host: (no value)
and so on

whereas in RT2 it was:
Keywords
OS: Red Hat 8.0
Host: starboard
and so on.

Recreating the keywords manually isn’t so much a hassle, as there’s only
some 50 of them, but recreating the keywords on all of our tickets is going
to be painful.

jaq@spacepants.org http://spacepants.org/jaq.gpg

What version of the import tool?On Tue, Apr 08, 2003 at 12:16:53PM +1000, Jamie Wilkinson wrote:

Hi again!

The migration scripts have imported all the data from the dumps, as before,
but it’s lost some information.

The tickets themselves contain all the priority changes that have been made,
but the listed priority that the tickets are being sorted by on the front
page is the one that the ticket was originally created with. Any way to fix
up the priorities to the most recent set value?

Also, while the tickets themselves still have the names of the Custom Fields
set from the previous install Keywords, they don’t contain any values – the
actual contents of the Keywords table hasn’t been migrated.

e.g. on the Ticket display page, you can see
Custom Fields
OS: (no value)
Host: (no value)
and so on

whereas in RT2 it was:
Keywords
OS: Red Hat 8.0
Host: starboard
and so on.

Recreating the keywords manually isn’t so much a hassle, as there’s only
some 50 of them, but recreating the keywords on all of our tickets is going
to be painful.


jaq@spacepants.org http://spacepants.org/jaq.gpg


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

This one time, at band camp, Jesse Vincent wrote:

What version of the import tool?

rt2-to-rt3-1.7 as per my email yesterday.

jaq@spacepants.org http://spacepants.org/jaq.gpg

This one time, at band camp, Jamie Wilkinson wrote:

This one time, at band camp, Jesse Vincent wrote:

What version of the import tool?

rt2-to-rt3-1.7 as per my email yesterday.

What I found was that the priority field in the tickets table wasn’t
correct, though the transactions table had the fields listed correctly.

So, here’s some psql crack that fixed up the priorities. Our resident pg
guru sends his apologies for the sql you are about to see :slight_smile:

– first, grab a list of tickets and their latest priorities.

select ticket, (select newvalue from transactions where transactions.ticket
= t.ticket and field = ‘Priority’ order by created desc limit 1) as
newvalue from transactions t group by t.ticket, t.field having field =
‘Priority’ ;

– then in a transaction:

begin transaction;

– 10 points to whoever can decode this
update tickets set priority = (select int4(newvalue) from transactions where
transactions.ticket = tickets.id and field = ‘Priority’ and newvalue
is not null order by created desc limit 1) where tickets.id =
transactions.ticket and (select int4(newvalue) from transactions where
transactions.ticket = tickets.id and field = ‘Priority’ and newvalue
is not null order by created desc limit 1) is not null;

– and compare to your original results
select distinct tickets.id, priority from tickets inner join transactions
on transactions.ticket = tickets.id where transactions.field = ‘Priority’;

– if it’s okay, otherwise rollback
commit;

jaq@spacepants.org http://spacepants.org/jaq.gpg