* New visual style (web2).
* Rich text mails.
* Email signatures and encryption.
* User settings for:
- Ticket history ordering.
- Timezones.
- Date and time format.
- Username format.
- Default queue.
- Size of message text boxes.
* Charts of ticket relationships.
* Breeze through upgrades with new upgrade tools.
* Subscribe to iCalendar feeds of ticket due dates.
* Bookmark frequently-used tickets.
* Turn off mail from RT when you go on vacation.
* Get your mail from RT as a daily or weekly batch.
* Delete historical or spam tickets with RT::Shredder (only as a superuser).
* Set up more configurable business rules with new Scrip Conditions and
Actions.
* Forward tickets to third-parties from within RT.
* Enable and Disable RT extensions with the new Plugins system.
* Automatically log out inactive users with rt-clean-sessions.
* Run faster with less memory, thanks to numerous performance improvements
and bug fixes.
* Fixed a potential HTML injection attck via user's properties.
* Better support for installation on Solaris and FreeBSD (non-GNU make).
* Updates to documentation and scripts for upgrading from MySQL 4.0
* Updated upgrade documentation for the new Queue Tag and bookmarks features.
* Multiple bugs in iCal support fixed.
* Backwards compatibility fixes for extensions developed against 3.6
* Added support for external links in tabs and targets.
* Addition of a new callback before ticket creation so you can implement
custom validation or stop creation for another reason.
* Missing documentation to external authentication configuration variable
in bin/rt and make it possible to set it via ENV.
* Merged method in RT::Ticket.
XML::Simple. Hence add a dependency on p5-XML-Simple package.
While here ensure that PREFIX/{bin,sbin} are created during install phase.
Bump PKGREVISION to 4.
changes are apparently minor to a end user (but not for the site
administrator).
It'd very hard and very long to provide a full list of changes. The main
changes in RT 3.4 are a complete rework of how Custom Fields are handled,
which means there is a lot more flexibility in that area now (including
Custom Fields for users, per-queue, per-transaction). RT 3.4 is also
supposed to be faster, which certainly is no bad news.
Another bonus of RT 3.4 are the availability of extensions, and I will
commit RTx::Shredder and RTx::RightsMatrix very soon.
Updating RT is not an easy task, be sure to backup your database, and don't
forget to grant the new rights to relevant people.
In pkgsrc, rt3 is also seeing a few changes. The main one is the situation
of the "local" path, which is now set to /var/rt3, which seems less lame to
me than the previous value. It could be debated, though.
INSTALL/DEINSTALL script creation within pkgsrc.
If an INSTALL or DEINSTALL script is found in the package directory,
it is automatically used as a template for the pkginstall-generated
scripts. If instead, they should be used simply as the full scripts,
then the package Makefile should set INSTALL_SRC or DEINSTALL_SRC
explicitly, e.g.:
INSTALL_SRC= ${PKGDIR}/INSTALL
DEINSTALL_SRC= # emtpy
As part of the restructuring of the pkginstall framework internals,
we now *always* generate temporary INSTALL or DEINSTALL scripts. By
comparing these temporary scripts with minimal INSTALL/DEINSTALL
scripts formed from only the base templates, we determine whether or
not the INSTALL/DEINSTALL scripts are actually needed by the package
(see the generate-install-scripts target in bsd.pkginstall.mk).
In addition, more variables in the framework have been made private.
The *_EXTRA_TMPL variables have been renamed to *_TEMPLATE, which are
more sensible names given the very few exported variables in this
framework. The only public variables relating to the templates are:
INSTALL_SRC INSTALL_TEMPLATE
DEINSTALL_SRC DEINSTALL_TEMPLATE
HEADER_TEMPLATE
The packages in pkgsrc have been modified to reflect the changes in
the pkginstall framework.
Collection.
This package is based on the work of Dieter Roelants in pkgsrc-wip, with
a lot of changes to make it proper WRT pkgsrc.
RT is an industrial-grade ticketing system. It lets a group of
people intelligently and efficiently manage requests submitted by
a community of users. RT is used by systems administrators, customer
support staffs, NOCs, developers and even marketing departments at
over a thousand sites around the world.
