1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
=head1 UPGRADING FROM BEFORE 4.0.0
=head2 Common issues
RT now defaults to a database name of rt4 and an installation root of
/opt/rt4.
If you are upgrading, you will likely want to specify that your database is
still named rt3 (or import a backup of your database as rt4 so that you can
feel more confident making the upgrade).
You really shouldn't install RT4 into your RT3 source tree (/opt/rt3) and
instead should be using make install to set up a clean environment. This will
allow you to evaluate your local modifications and configuration changes as
you migrate to 4.0.
If you choose to force RT to install into /opt/rt3, or another existing RT 3.x
install location, you will encounter issues because we removed the _Overlay
files (such as Ticket_Overlay.pm) and relocated other files. You will need to
manually remove these files after the upgrade or RT will fail. After making a
complete backup of your /opt/rt3 install, you might use a command like the
following to remove the _Overlay files:
find /opt/rt3/lib/ -type f -name '*_Overlay*' -delete
RT has also changed how web deployment works; you will need to review
docs/web_deployment.pod for current instructions. The old `fastcgi_server`,
`webmux.pl`, and `mason_handler.*` files will not work with RT 4.0, and should
be removed to reduce confusion.
=head2 RT_SiteConfig.pm
You will need to carefully review your local settings when moving from 3.8 to
4.0.
If you were adding your own custom statuses in earlier versions of RT, using
ActiveStatus or InactiveStatus you will need to port these to use the new
Lifecycles functionality. You can read more about it in RT_Config.pm. In
most cases, you can do this by extending the default active and inactive
lists.
=head2 Upgrading sessions on MySQL
In 4.0.0rc2, RT began shipping an updated schema for the sesions table that
specificies a character set as well as making the table InnoDB. As part of
the upgrade process, your sessions table will be dropped and recreated with
the new schema.
=head2 Upgrading from installs with RTFM
RT4 now includes an Articles functionality, merged from RTFM. You should not
install and enable the RT::FM plugin separately on RT 4. If you have existing
data in RTFM, you can use the etc/upgrade/upgrade-articles script to upgrade
that data.
When running normal upgrade scripts, RT will warn if it finds existing RTFM
tables that contain data and point you to the upgrade-articles script.
This script should be run from your RT tarball. It will immediately begin
populating your new RT4 tables with data from RTFM. If you have browsed in
the RT4 UI and created new classes and articles, this script will fail
spectacularly. Do *not* run this except on a fresh upgrade of RT.
You can run this as
etc/upgrade/upgrade-articles
It will ouput a lot of data about what it is changing. You should review this
for errors.
If you are running RTFM 2.0 with a release of RT, there isn't currently an
upgrade script that can port RTFM's internal CustomField and Transaction data
to RT4.
You must also remove RT::FM from your @Plugins line in RT_SiteConfig.pm.
=head2 Removals and updates
The deprecated classes RT::Action::Generic, RT::Condition::Generic and
RT::Search::Generic have been removed, but you shouldn't have been using them
anyway. You should have been using RT::Action, RT::Condition and RT::Search,
respectively.
=over
=item *
The "Rights Delegation" and "Personal Groups" features have been removed.
=item *
Replace the following code in templates:
[{$Ticket->QueueObj->SubjectTag || $rtname} #{$Ticket->id}]
with
{ $Ticket->SubjectTag }
=item *
Unique names are now enforced for user defined groups. New groups cannot be
created with a duplicate name and existing groups cannot be renamed to an
in-use name. The admin interface will warn about existing groups with
duplicate names. Although the groups will still function, some parts of the
interface (rights management, subgroup membership) may not work as expected
with duplicate names. Running
/opt/rt4/sbin/rt-validator --check
will report duplicate group names, and running it with --resolve will fix
duplicates by appending the group id to the name.
Nota Bene: As a result of differing indexes in the schema files, Postgres and
SQLite RT databases have enforced group name uniqueness for many years at the
database level.
=back
=head1 UPGRADING FROM 4.0.5 AND EARLIER
=head2 Schema updates
The fix for an attribute truncation bug on MySQL requires a small ALTER TABLE.
Be sure you run `make upgrade-database` to apply this change automatically.
The bug primarily manifested when uploading large logos in the theme editor on
MySQL. Refer to etc/upgrade/4.0.6/schema.mysql for the actual ALTER TABLE
that will be run.
=head2 Query Builder
The web-based query builder now uses Queue limits to restrict the set of
displayed statuses and owners. As part of this change, the %cfqueues
parameter was renamed to %Queues; if you have local modifications to any of
the following Mason templates, this feature will not function correctly:
share/html/Elements/SelectOwner
share/html/Elements/SelectStatus
share/html/Prefs/Search.html
share/html/Search/Build.html
share/html/Search/Elements/BuildFormatString
share/html/Search/Elements/PickCFs
share/html/Search/Elements/PickCriteria
|
