The internal handling for templates for email and web pages has been changed. This makes it possible to define custom subject lines for each conference, as well as to have more control over what messages get copied to whom. For example, track chairs, web masters and publication chairs can now be copied easily on selected messages. The only user-visible change is that the configuration for setting up cc's for templates has moved to the template definition, rather than the conference email configuration.

Conferences often use EDAS to generate PDF visa letters for authors, confirming the acceptance of a paper. Until now, these visa letters had to be in a small subset of HTML. We have added the ability to use Wiki mark-up, i.e., plain text with a few symbols to denote basic formatting. For example, in Wiki mark-up, bold is indicated by a double-underscore, as in __ bold __, and italics by a two pairs of single quotes, as in '' italic ''. The system automatically detects whether a conference uses HTML or Wiki format. Wiki markup works best for letters with minimal formatting, while HTML markup is better suited for letters where you want to place multiple logos or have more fine-grained control over positioning of elements. Chairs should read the documentation for more details.

If you are using a registration system outside of EDAS, you can now limit the number of papers that can be associated with one registration code. The limit is defined in the track configuration.

Track chairs are now included in the chair email copies, e.g., when papers are submitted. See Conference:Configure under "Email".

For journals and some conferences, it is customary to let reviewers know whether the paper they have reviewed has been accepted or not by blind-copying (bcc'ing) them on the notification email. You can now configure this option in Reviews:Configure under "Who can see what?": Reviewers for a paper   are not   bcc'ed on the author notification for the papers they have reviewed.

In the past, conferences were restricted to having two review forms - the basic review and a so-called meta review, i.e., a review or summary of the other reviews. This worked for most conferences, but some conferences do post-conference reviews and the old approach proved to be an awkward fit for the two-stage model. It also required a fair amount of special case handling. Thus, we have generalized the review model so that a conference can now have any number of review forms, each with different due dates, questions and email templates. You can now also inherit (re-use) review form from other conferences more easily. This change has moved a few review-related configuration options, such as review deadlines and templates, to Reviews:Review Forms . To create new review forms, such as a meta review, use the link at the bottom of that page. This is a fairly major change, so it will take a bit for all functions to deal well with that generalization. As always, suggestions for how to