Third beta release of MailManager 1.0

The Logical Progression crew is delighted once again to announce the
third beta release of MailManager - treating e-mail ever more
seriously.

In a fit of enthusiasm our CEO re-classified several feature requests
as "bugs of omission" and consequently this release features a number
of new features and major improvements. It also includes a couple of
serious bug fixes.

BUG FIXES

Account signatures were never used at all. They now appear at the
bottom of every outgoing message and automatic acknoweldgement, beyond
the control of the agent. User signatures appear above account
signatures. The standard separator "\n-- \n" is automatically
inserted between the message body and the signature(s).

Reply templates and auto replies that were supposed to be in HTML were
being sent out as plain text, with the tags included. The same would
have applied to account signatures if they had been used at all. The
inclusion of HTML signatures or templates now forces the whole message
to be composed in HTML.

OTHER HIGHLIGHTS

The supporter mechanism, by which tickets can be associated with other
tickets, is now fully implemented. The interface, however, need not
be in its final form. Feedback on this feature would be appreciated.

URLs in messages are rendered as hyperlinks. I mention this in
particular because our current stylesheet removes all hints that they
are links, unless you hold your mouse over them!

By popular demand notification messages are now sent to agents at
every new message while the customer only receives acknowledgement of
messages that start a new thread.

Tickets can now be re-opened, either through the Ticket Details box or
by the arrival of a new message.

NOTE ON MIGRATION

Migration was introduced for pre-release versions only at the request
of a valued user. We are taking advantage of this beta period to
experiment with the mechanism and migration should not be regarded as
safe until after the final release (and not entirely so then). The
two migration bugs found in the last release (867863 and 862647)
underline this.

In this release migration took a great stride towards its intended
final form by the introduction of migration version ("mversion")
numbers, distinct from Product version numbers. The intention is that
whenever changes that require migration (technically: changes to
instance dicts rather than class dicts) are committed, at the
same time the migration code should be committed and the mversion
bumped up one.

As ever we are immensely grateful for the feedback from and
encouragement of our user community. Your comments have already
shaped the product to a large extent and we look forward to
implementing your requested features once we have made the final
release.