63dd2eecc973c16aea22ddc86a63cdd9e2d1d663
[usit-rt.git] / docs / UPGRADING-4.0
1 =head1 UPGRADING FROM BEFORE 4.0.0
2
3 =head2 Common issues
4
5 RT now defaults to a database name of rt4 and an installation root of
6 /opt/rt4.
7
8 If you are upgrading, you will likely want to specify that your database is
9 still named rt3 (or import a backup of your database as rt4 so that you can
10 feel more confident making the upgrade).
11
12 You really shouldn't install RT4 into your RT3 source tree (/opt/rt3) and
13 instead should be using make install to set up a clean environment.  This will
14 allow you to evaluate your local modifications and configuration changes as
15 you migrate to 4.0.
16
17 If you choose to force RT to install into /opt/rt3, or another existing RT 3.x
18 install location, you will encounter issues because we removed the _Overlay
19 files (such as Ticket_Overlay.pm) and relocated other files.  You will need to
20 manually remove these files after the upgrade or RT will fail.  After making a
21 complete backup of your /opt/rt3 install, you might use a command like the
22 following to remove the _Overlay files:
23
24     find /opt/rt3/lib/ -type f -name '*_Overlay*' -delete
25
26 RT has also changed how web deployment works; you will need to review
27 F<docs/web_deployment.pod> for current instructions.  The old
28 `fastcgi_server`, `webmux.pl`, and `mason_handler.*` files will not
29 work with RT 4.0, and should be removed to reduce confusion.
30
31 If you deploy RT with mod_perl, Apache will no longer start with C<SetHandler>
32 set to `perl-script`. F<docs/web_deployment.pod> contains the
33 new configuration.
34
35
36 =head2 RT_SiteConfig.pm
37
38 You will need to carefully review your local settings when moving from 3.8 to
39 4.0.
40
41 If you were adding your own custom statuses in earlier versions of RT, using
42 ActiveStatus or InactiveStatus you will need to port these to use the new
43 Lifecycles functionality.  You can read more about it in RT_Config.pm.  In
44 most cases, you can do this by extending the default active and inactive
45 lists.
46
47
48 =head2 Upgrading sessions on MySQL
49
50 In 4.0.0rc2, RT began shipping an updated schema for the sesions table that
51 specificies a character set as well as making the table InnoDB.  As part of
52 the upgrade process, your sessions table will be dropped and recreated with
53 the new schema.
54
55
56 =head2 Upgrading from installs with RTFM
57
58 RT4 now includes an Articles functionality, merged from RTFM.  You should not
59 install and enable the RT::FM plugin separately on RT 4.  If you have existing
60 data in RTFM, you can use the etc/upgrade/upgrade-articles script to upgrade
61 that data.
62
63 When running normal upgrade scripts, RT will warn if it finds existing RTFM
64 tables that contain data and point you to the upgrade-articles script.
65
66 This script should be run from your RT tarball.  It will immediately begin
67 populating your new RT4 tables with data from RTFM.  If you have browsed in
68 the RT4 UI and created new classes and articles, this script will fail
69 spectacularly.  Do *not* run this except on a fresh upgrade of RT.
70
71 You can run this as
72
73   etc/upgrade/upgrade-articles
74
75 It will ouput a lot of data about what it is changing.  You should review this
76 for errors.
77
78 If you are running RTFM 2.0 with a release of RT, there isn't currently an
79 upgrade script that can port RTFM's internal CustomField and Transaction data
80 to RT4.
81
82 You must also remove RT::FM from your @Plugins line in RT_SiteConfig.pm.
83
84
85 =head2 Removals and updates
86
87 The deprecated classes RT::Action::Generic, RT::Condition::Generic and
88 RT::Search::Generic have been removed, but you shouldn't have been using them
89 anyway. You should have been using RT::Action, RT::Condition and RT::Search,
90 respectively.
91
92 =over
93
94 =item *
95
96 The "Rights Delegation" and "Personal Groups" features have been removed.
97
98 =item *
99
100 Replace the following code in templates:
101
102     [{$Ticket->QueueObj->SubjectTag || $rtname} #{$Ticket->id}]
103
104 with
105
106     { $Ticket->SubjectTag }
107
108 =item *
109
110 Unique names are now enforced for user defined groups.  New groups cannot be
111 created with a duplicate name and existing groups cannot be renamed to an
112 in-use name.  The admin interface will warn about existing groups with
113 duplicate names.  Although the groups will still function, some parts of the
114 interface (rights management, subgroup membership) may not work as expected
115 with duplicate names.  Running
116
117     /opt/rt4/sbin/rt-validator --check
118
119 will report duplicate group names, and running it with --resolve will fix
120 duplicates by appending the group id to the name.
121
122 Nota Bene: As a result of differing indexes in the schema files, Postgres and
123 SQLite RT databases have enforced group name uniqueness for many years at the
124 database level.
125
126 =back
127
128
129 =head2 Ticket content searches (full text search)
130
131 Since 4.0.0, RT's ticket content search is disabled by default because of
132 performance issues when used without full text indexing.  For details on how to
133 re-enable it with (or without) full text indexing, see
134 F<docs/full_text_indexing.pod>.
135
136
137
138 =head1 UPGRADING FROM 4.0.5 AND EARLIER
139
140 =head2 Schema updates
141
142 The fix for an attribute truncation bug on MySQL requires a small ALTER TABLE.
143 Be sure you run `make upgrade-database` to apply this change automatically.
144 The bug primarily manifested when uploading large logos in the theme editor on
145 MySQL.  Refer to etc/upgrade/4.0.6/schema.mysql for the actual ALTER TABLE
146 that will be run.
147
148
149 =head2 Query Builder
150
151 The web-based query builder now uses Queue limits to restrict the set of
152 displayed statuses and owners.  As part of this change, the %cfqueues
153 parameter was renamed to %Queues; if you have local modifications to any of
154 the following Mason templates, this feature will not function correctly:
155
156     share/html/Elements/SelectOwner
157     share/html/Elements/SelectStatus
158     share/html/Prefs/Search.html
159     share/html/Search/Build.html
160     share/html/Search/Elements/BuildFormatString
161     share/html/Search/Elements/PickCFs
162     share/html/Search/Elements/PickCriteria
163
164 =head1 UPGRADING FROM 4.0.8 AND EARLIER
165
166 =head2 Data upgrades
167
168 Previously, the default lifecycle was stored in Queues.Lifecycle as
169 NULL. To simplify code, RT now stores the string 'default' to match the
170 name of the Lifecycle.
171
172 The 3.9.2 upgrade step removed all enabled Personal Groups, but missed
173 any disabled groups. We catch and clean up the disabled Personal groups
174 during the 4.0.9 upgrade step.
175
176 =head2 Javascript Changes
177
178 If you have set a custom @JSFiles in RT_SiteConfig.pm, you will need to
179 amend this to include the new jquery.cookie.js file added to
180 RT_Config.pm.  If you are using an extension that requires manually
181 tweaking @JSFiles, please contact the developer and ask them to use
182 RT->AddJavaScript in their extension to avoid these upgrade problems.
183
184 If you have @JSFiles set in your RT_SiteConfig.pm but it appears to be
185 the same as RT_Config.pm (no local js files added) you can safely remove
186 the whole setting from RT_SiteConfig.pm and allow our default to be
187 used.
188
189 =head1 UPGRADING FROM 4.0.11 AND EARLIER
190
191 =head2 Data Upgrades
192
193 Previous versions of RT allowed you to create Tickets with a Type of
194 'Ticket', 'Approval' or 'Reminder' instead of the correct 'ticket'.
195 Existing Types are updated in the database and the RT API now corrects
196 these types before insertion.
197
198 Site-specific custom types (anything but ticket, reminder or approval)
199 are not affected by these changes.
200
201 =head1 UPGRADING FROM 4.0.13 AND EARLIER
202
203 =head2 Outgoing mail From: header
204
205 The "Default" key of the C<$OverrideOutgoingMailFrom> config option now,
206 as previously documented, only applies when no ticket is involved.
207 Previously it was also used when a ticket was involved but the
208 associated queue had no specific correspond address.  In such cases the
209 global correspond address is now used.
210
211 The config option C<$SetOutgoingMailFrom> now accepts an email address
212 as a value which will act as a global default.  This covers the simple
213 case of sending all bounces to a specific address, without the previous
214 solution of resorting to defining all queues in
215 $OverrideOutgoingMailFrom.  Any definitions in the Override option
216 (including Default) still take precedence.  See
217 L<RT_Config/$SetOutgoingMailFrom> for more information.
218
219 =head2 Reminder statuses
220
221 New reminders are now created in the "reminder_on_open" status defined in your
222 lifecycles.  For the default lifecycle, this means reminders will start as
223 "open" instead of "new".  This change is for consistency when a completed
224 reminder is reopened at a later date.  If you use custom lifecycles and added
225 further transition restrictions, you may need to adjust the L<"reminder_on_open"
226 setting|RT_Config/reminder_on_open> in your lifecycles.
227
228 =head2 Bookmarks
229
230 Previously, the list of Bookmarks on your homepage was unlimited (if you
231 had 100 bookmarked tickets, you would see a 100 item list on your RT at
232 a Glance).  'Bookmarked Tickets' now uses the same size limits as any
233 other search on your homepage.  This can be customized using the 'Rows
234 per box' setting on your RT at a Glance configuration page.
235
236 =head2 PostgreSQL 9.2
237
238 If you are upgrading an RT from 3.8 (or earlier) to 4.0 on PostgreSQL
239 9.2, you should make sure that you have installed DBD::Pg 2.19.3 or
240 higher.  If you start your upgrade without installing a recent-enough
241 version of DBD::Pg RT will stop the upgrade during the 3.9.8 step and
242 remind you to upgrade DBD::Pg.  If this happens, you can re-start your
243 upgrade by running:
244
245    ./sbin/rt-setup-database --action insert --datadir etc/upgrade/3.9.8/
246
247 Followed by re-running make upgrade-database and answering 3.9.8 when
248 prompted for which RT version you're upgrading from.