Migration from 2.0.15 to 3.2.0 nearly flawless

RT Developers
1

I just spent a few hours updating RT from 2.0.15 to 3.2.0 (not counting
the ticket migration time, which was considerable…)

There was exactly one major show stopper, described below. The only
other issue was that many of my per-queue scrips are already default
global scrips, so I had to manually delete them from each of the
queues, and the two global scrips migrated were also already existing
and needed to be deleted. Actually, one more issue: I had to
explicitly add DeleteTicket right to my service reps whereas that was
not necessary before.

The show stopper:

None of the sequences in Postgres was initialized after the dumpfile
was imported. The most immediately visible result is that no
correspondence can be recorded since attachments keep hitting duplicate
id’s. The fix is to run a command like this for every single sequence:

select setval(‘users_id_seq’,max(id)) from users;

the sequences are:

                   List of relations

Schema | Name | Type | Owner
public | acl_id_seq | sequence | postgres
public | attachments_id_seq | sequence | postgres
public | attributes_id_seq | sequence | postgres
public | cachedgroupmembers_id_seq | sequence | postgres
public | customfields_id_seq | sequence | postgres
public | customfieldvalues_id_seq | sequence | postgres
public | groupmembers_id_seq | sequence | postgres
public | groups_id_seq | sequence | postgres
public | links_id_seq | sequence | postgres
public | principals_id_seq | sequence | postgres
public | queues_id_seq | sequence | postgres
public | scripactions_id_seq | sequence | postgres
public | scripconditions_id_seq | sequence | postgres
public | scrips_id_seq | sequence | postgres
public | templates_id_seq | sequence | postgres
public | ticketcustomfieldvalues_id_s | sequence | postgres
public | tickets_id_seq | sequence | postgres
public | transactions_id_seq | sequence | postgres
public | users_id_seq | sequence | postgres

2

The show stopper:

None of the sequences in Postgres was initialized after the dumpfile
was imported.

Yes. That’s documented in the README for the upgrade tool:

If you’re using a database such as Postgres or Oracle that has
explicit sequence support, you may need to set the value of each
table’s sequence to the MAX(id) for that table

3

None of the sequences in Postgres was initialized after the dumpfile
was imported.

Yes. That’s documented in the README for the upgrade tool:

If you’re using a database such as Postgres or Oracle that has
explicit sequence support, you may need to set the value of each
table’s sequence to the MAX(id) for that table

Hmmm. I used 1.21; I guess I missed the announcements of any newer
release. 1.21 doesn’t mention this :frowning:

At least I’m upgraded (finally!) Just need to tweak some permissions
to use the nicer configurations available with 3.2.

smime.p7s (2.42 KB)

4

I did the upgrade 2.0.15 -> 3.20 myself yesterday.

Some notes from me:

  • I had to clear var/mason_data to see the new Search page

  • I had to add the “www” user manually to the “rt” group so
    that the FastCGI handler could find the config file.

  • When playing with the new Query builder I could not build
    up an “OR” condition. The second condition will always be
    added with AND and the “And/Or” button is without function.
    Is this a known bug?

I did never try 3.0.x but 3.2.0 has many nice improvements
over 2.0.15. Great work!

bye
Markus

5
  • When playing with the new Query builder I could not build
    up an “OR” condition. The second condition will always be
    added with AND and the “And/Or” button is without function.
    Is this a known bug?

Yes. It should be fixed sometime this week.