[Rt-commit] rt branch, 4.0/upgrading-docs, updated. rt-4.0.0rc6-42-gaf8ae55
Alex Vandiver
alexmv at bestpractical.com
Wed Mar 16 16:42:17 EDT 2011
The branch, 4.0/upgrading-docs has been updated
via af8ae55ef8bbf0e66b52950e4b6b010a5cfb8ae3 (commit)
from 1b0da4ee35397b5e092c50cef4c823c2a6d1c1d3 (commit)
Summary of changes:
docs/UPGRADING-3.8 | 159 ++++++++++++++++++++++++++--------------------------
1 files changed, 80 insertions(+), 79 deletions(-)
- Log -----------------------------------------------------------------
commit af8ae55ef8bbf0e66b52950e4b6b010a5cfb8ae3
Author: Alex Vandiver <alexmv at bestpractical.com>
Date: Wed Mar 16 13:42:08 2011 -0700
Reformat and reword for better english
diff --git a/docs/UPGRADING-3.8 b/docs/UPGRADING-3.8
index 55d5540..a25c04b 100644
--- a/docs/UPGRADING-3.8
+++ b/docs/UPGRADING-3.8
@@ -1,70 +1,65 @@
UPGRADING FROM 3.8.8 and earlier - Changes:
Previous versions of RT used a password hashing scheme which was too
-easy to reverse, which could allow attackers with read access to the
-RT database to possibly compromise users' passwords. Even if RT does
-no password authentication itself, it may still store these weak
-password hashes -- using ExternalAuth does not guarantee that you are
-not vulnerable! To upgrade stored passwords to a stronger hash, run:
+easy to reverse, which could allow attackers with read access to the RT
+database to possibly compromise users' passwords. Even if RT does no
+password authentication itself, it may still store these weak password
+hashes -- using ExternalAuth does not guarantee that you are not
+vulnerable! To upgrade stored passwords to a stronger hash, run:
perl etc/upgrade/vulnerable-passwords
-
-We've proved that it's possible to delete set of records
-from Transactions table without losing functionality. To delete
-records run the following script:
+We have also proved that it's possible to delete a notable set of
+records from Transactions table without losing functionality. To delete
+these records, run the following script:
perl -I /opt/rt4/local/lib -I /opt/rt4/lib etc/upgrade/shrink_transactions_table.pl
-If you chose not to run the shrink_cgm_table.pl script when you upgraded to 3.8,
-you should read more about it below and run it at this point.
+If you chose not to run the shrink_cgm_table.pl script when you upgraded
+to 3.8, you should read more about it below and run it at this point.
+
+The default for $MessageBoxWrap is now SOFT and $MessageBoxWidth is now
+unset by default. This means the message box will expand to fill all
+the available width. $MessageBoxWrap is also overridable by the user
+now. These changes accommodate the new default two column layout for
+ticket create and update pages. You may turn this layout off by setting
+$UseSideBySideLayout to 0. To retain the original behavior, set
+$MessageBoxWrap to HARD and $MessageBoxWidth to 72.
-The default for $MessageBoxWrap is now SOFT and $MessageBoxWidth is now unset
-by default. This means the message box will expand to fill all the available
-width. $MessageBoxWrap is also overridable by the user now. These changes
-accommodate the new default two column layout for ticket create and update
-pages. You may turn this layout off by setting $UseSideBySideLayout to 0. To
-retain the original behavior, set $MessageBoxWrap to HARD and $MessageBoxWidth
-to 72.
UPGRADING FROM 3.8.7 and earlier - Changes:
RT's ChartFont option has been changed from a string to a hash which
lets you specify per-language fonts. RT now comes with a better default
-font for charts, too.
-
-You should either update your 'ChartFont' option to match the new format
-or consider trying the new default
-
-RT now gives you more precise control over the order in which custom fields
-are displayed. This change requires some small changes to your currently saved
-custom field orders.
-
-RT will automatically clean up your existing custom fields when you run:
+font for charts, too. You should either update your 'ChartFont' option
+to match the new format, or consider trying the new default.
+RT now gives you more precise control over the order in which custom
+fields are displayed. This change requires some small changes to your
+currently saved custom field orders. RT will automatically clean up
+your existing custom fields when you run the standard database upgrade
+steps. After that cleanup, you should make sure that custom fields are
+ordered in a way that you and your users find pleasing.
- /opt/rt4/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade
-
-After that cleanup, you should make sure that custom fields are ordered in
-a way that you and your users find pleasing.
UPGRADING FROM 3.8.6 and earlier - Changes:
For MySQL and Oracle users:
-If you upgraded from a version of RT earlier than 3.7.81 you should
-already have a CachedGroupMembers3 index on your CachedGroupMembers table.
-If you did a clean install of RT somewhere in the 3.8 release series, you
-most likely don't have this index. You can add it manually with
+If you upgraded from a version of RT earlier than 3.7.81, you should
+already have a CachedGroupMembers3 index on your CachedGroupMembers
+table. If you did a clean install of RT somewhere in the 3.8 release
+series, you most likely don't have this index. You can add it manually
+with:
CREATE INDEX CachedGroupMembers3 on CachedGroupMembers (MemberId, ImmediateParentId);
-UPGRADING FROM 3.8.5 and earlier - Changes:
-You can now forward an entire Ticket history (in addition to specific transactions)
-but this requires a new Template called forward ticket. This template will be added
-when you run.
+UPGRADING FROM 3.8.5 and earlier - Changes:
-/opt/rt4/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade
+You can now forward an entire Ticket history (in addition to specific
+transactions) but this requires a new Template called "Forward Ticket".
+This template will be added as part of the standard database upgrade
+step.
Custom fields with categories can optionally be split out into
hierarchical custom fields. If you wish to convert your old
@@ -72,36 +67,44 @@ category-based custom fields, run:
perl etc/upgrade/split-out-cf-categories
-It will prompt you for each custom field with categories that it
-finds, and the name of the custom field to create to store the
-categories.
+It will prompt you for each custom field with categories that it finds,
+and the name of the custom field to create to store the categories.
-If you were using the LocalizedDateTime RT::Date formatter from code
-and passing a DateFormat or TimeFormat argument, you need to switch from
-the strftime methods to the cldr methods (ie full_date_format becomes date_format_full)
-You may have done this from your RT_SiteConfig.pm by using
-Set($DateTimeFormat, { Format => 'LocalizedDateTime', DateFormat => 'medium_date_format' );
+If you were using the LocalizedDateTime RT::Date formatter from custom
+code, and passing a DateFormat or TimeFormat argument, you need to
+switch from the strftime methods to the cldr methods; that is,
+'full_date_format' becomes 'date_format_full'.
+
+You may also have done this from your RT_SiteConfig.pm, using:
+ Set($DateTimeFormat, {
+ Format => 'LocalizedDateTime',
+ DateFormat => 'medium_date_format',
+ );
+Which would need to be changed to:
+ Set($DateTimeFormat, {
+ Format => 'LocalizedDateTime',
+ DateFormat => 'date_format_medium',
+ );
-UPGRADING FROM 3.8.3 and earlier - Changes:
-Arguments to the NotifyGroup Scrip Action need
-to be corrected in the database using
+UPGRADING FROM 3.8.3 and earlier - Changes:
-/opt/rt4/sbin/rt-setup-database --dba root --prompt-for-dba-password --action upgrade
+Arguments to the NotifyGroup Scrip Action will be updated as part of the
+standard database upgrade process.
UPGRADING FROM 3.8.2 and earlier - Changes:
-New scrip condition 'On Reject'.
+A new scrip condition, 'On Reject', has been added.
-UPGRADING FROM 3.8.1 and earlier - Changes:
-= Oracle configuration =
+UPGRADING FROM 3.8.1 and earlier - Changes:
-$DatabaseName is used as SID, so RT can connect without environment variables
-or tnsnames.ora file. Because of this change your RT instance may loose ability
-to connect to your DB, you have to update options and restart your web server.
-Example configuration:
+When using Oracle, $DatabaseName is now used as SID, so RT can connect
+without environment variables or tnsnames.ora file. Because of this
+change, your RT instance may loose its ability to connect to your DB; to
+resolve this, you will need to update RT's configuration and restart
+your web server. Example configuration:
Set($DatabaseType, 'Oracle');
Set($DatabaseHost, '192.168.0.1');
@@ -114,36 +117,35 @@ Example configuration:
# above user's password
Set($DatabasePassword, 'test');
-= Rights changes =
-
-Now, if you want any user to be able to access the Approvals tools (a.k.a. the
+If you want a user to be able to access the Approvals tools (a.k.a. the
Approvals tab), you must grant that user the "ShowApprovalsTab" right.
+
UPGRADING FROM 3.8.0 and earlier - Changes:
-Searches for bookmarked tickets have been reimplemented and syntax has
-been changed a little. Database upgrade script handles global 'Bookmarked Tickets'
-search only. New Ticket SQL "id = '__Bookmarked__'" is more flexible than
-old "__Bookmarks__". Old version is not valid Ticket SQL query, so people
-can not use it in the query builder and as well admins couldn't not edit
-format and other properties of the global saved search. Old version's been
-left for backwards compatibility.
+The TicketSQL syntax for bookmarked tickets has been changed.
+Specifically, the new phrasing is "id = '__Bookmarked__'", rather than
+the old "__Bookmarks__". The old form will remain, for backwards
+compatibility. The standard database upgrade process will only
+automatically change the global 'Bookmarked Tickets' search
+
UPGRADING FROM 3.7.85 and earlier - Changes:
-We've proved that it's possible to delete pretty big set of records
-from CachedGroupMembers table without losing functionality. To delete
-record run the following script. If you don't run this, you may
-occasionally see problems where RT miscounts users, particularly in the
-chart functionality.
+We have proved that it is possible to delete a large set of records from
+the CachedGroupMembers table without losing functionality; in fact,
+failing to do so may result in occasional problems where RT miscounts
+users, particularly in the chart functionality. To delete these records
+run the following script:
perl -I /opt/rt4/local/lib -I /opt/rt4/lib etc/upgrade/shrink_cgm_table.pl
-After you run this, you'll have significantly reduced the number of
-records in your CachedGroupMembers table and may need to tell your
+After you run this, you will have significantly reduced the number of
+records in your CachedGroupMembers table, and may need to tell your
database to refresh indexes/statistics. Please consult your DBA for
specific instructions for your database.
+
UPGRADING FROM 3.7.81 and earlier - Changes:
RT::Extension::BrandedQueues has been integrated into core, so you MUST read
@@ -157,6 +159,7 @@ RT::Extension::iCal has been integrated into core, so you MUST uninstall
it before upgrading. In addition, you must run etc/upgrade/3.8-ical-extension
script to convert old data.
+
UPGRADING FROM 3.7.80 and earlier - Changes:
Added indexes to CachedGroupMembers for MySQL and Oracle.
@@ -165,5 +168,3 @@ have these indexes. You can see the indexes by looking at
etc/upgrade/3.7.81/schema.*
These indexes may take a very long time to create.
-
-
-----------------------------------------------------------------------
More information about the Rt-commit
mailing list