Authors can now upload manuscripts from URLs. For example, they can provide a URL for the file located on their personal web server, a shareable Dropbox or Google Drive URL or another archival site. Dropbox and Google Drive provide shareable links that open web pages; EDAS rewrites those links to download the actual PDF or Word file. Other document sharing sites like box.com or Microsoft OneDrive may have their own mechanisms, so we will add these sites as user demands warrants and as we can figure out their URL schemes. The usage of ftp for uploading files has decreased dramatically in the past few years. Most ftp upload attempts fail since authors apparently do not understand that EDAS is unable to guess what paper number corresponds to some random file name like "mypaper.pdf" rather than the paper number. Other ftp upload attempts seem to be attempts to bypass format checks or conference deadlines. Since ftp is asynchronous and the ftp directory is scanned periodically,

Based on a suggestion by Mark Porter, the List & Export function for papers now saves the report settings, including selectors, fields and format, for the conference and person. Reports can be named for later retrieval. Reports are currently only visible to the same person. To edit a report, run a report from the saved list and then go the regular List & Export page, where the last settings are always shown and can be updated as needed.

Instead of defining a pre-defined list of paper status values such as "accepted" or "minor revision", EDAS now allows conferences to create new paper status values. These can be used for special handling or, say, distinguishing posters from oral presentations. (However, in many cases, paper categories and tracks are likely to be better choices.) New paper status options can be defined in Conference:Configure . Each can define its own background color and long text label. Each status value defines the paper as being active (i.e., under submission or review), accepted, rejected or withdrawn. By default, new EDAS conferences start with the common status values of pending, active, withdrawn, accepted and rejected that are used for almost every conference or journal. Paper status values were embedded in many of the hundreds of EDAS functions, so there may be some odd behaviors until all the corner cases have been generalized to handle conference-defined status values.

Based on a suggestion by Muhammad Ramadhan, event registrations can now have registration codes. Attendees can add a code when they register, and then see any registration options protected by the code. This can be used, for example, to offer reduced or complimentary registrations to keynote speakers or conference staff.

Based on a suggestion by Kai Zeng, we implemented "do-not-invite" TPC members. This category of TPC members is used to keep track of individuals who should not be invited to serve on the TPC. This is particularly useful if authors can volunteer for the TPC or if track chairs can add TPC members.

Zip files can now be encrypted with a password, using zipcloak, using the same access password that's used for reading the manuscript files for online proceedings.

Based on a suggestion by Chris Dyer, there is now a sub-menu in the TPC section to, I hope, make it easier to find various pages related to managing the TPC. Depending on feedback, we may also make similar changes to other pages that lead to multiple other pages, such as sessions and people.

Templates (e.g., for accepted papers) and email messages sent via People:Send Email can now have file attachments. Simply upload the file to Conference:Files as an attachment and then select the appropriate file when setting up the template or sending the email. You may also find " markdown " formatting helpful, so that email messages are rendered as "rich text", with bold, italics and other mark-up.

Over time, the EDAS permissions model had grown into a set of special cases, each motivated by a specific conference or journal request. (Each conference, for example, has different ideas of whether reviewers should see other reviews or reviewer identities, whether track chairs can accept or reject papers, whether authors are allowed to modify paper information after submission, or whether session chairs should be able to see reviews.) We implemented a new permission model that defines roles such as chair, track chair or reviewer, and created a single configuration location, in Conference:Configure (" Permissions ") to modify these permissions. There are a few special cases that can't be fit into that model, such as who can read papers or the conference program, but almost every other permission is now located there. As part of the change, the role of webmaster has gone away, as it was essentially the same as the publication chair.