This is a list of issues that we need to fix before making a Mephisto
release based on Rails 2.2.

  Drop TZInfo completely--see app/models/site.rb (fix docs, too)
  Handle inactive users with named scopes, not acts_as_versioned
  SECURITY: Don't ship :session_key in environment.rb!
  Try to upgrade to gem version of coderay
  We need to review our TODO comments
  Clean out the issue tracker: http://ar-code.lighthouseapp.com/projects/34-mephisto
  rake rails:update:javascripts => complicated because mephisto/application.js depends on older versions.

== Other issues

When running the unit tests, we need theme directories in themes/site-$ID.
But this namespace is also used by the development and production
databases.  Are the test suites clobbering user themes accidentally?  See
spec/models/membership_spec.rb for one quick-and-dirty workaround.  Perhaps
for all non-production environments, we should prepend RAILS-ENV to the
theme name, giving us themes/test-site-$ID?

This is a list of issues that we need to fix before making a Mephisto
release based on Rails 2.2.

  Drop TZInfo completely--see app/models/site.rb (fix docs, too)
  Handle inactive users with named scopes, not acts_as_versioned
  SECURITY: Don't ship :session_key in environment.rb!
  Try to upgrade to gem version of coderay
  We need to review our TODO comments
  Clean out the issue tracker: http://ar-code.lighthouseapp.com/projects/34-mephisto
  rake rails:update:javascripts => complicated because mephisto/application.js depends on older versions.

== Other issues

When running the unit tests, we need theme directories in themes/site-$ID.
But this namespace is also used by the development and production
databases.  Are the test suites clobbering user themes accidentally?  See
spec/models/membership_spec.rb for one quick-and-dirty workaround.  Perhaps
for all non-production environments, we should prepend RAILS-ENV to the
theme name, giving us themes/test-site-$ID?

== Security

We need to do a basic security audit.

  Cookies
    Make sure cookies are HTTP-only whenever possible
    Can we restrict admin cookies to /admin ?
    Make sure logging out clears all relevant cookies and tokens
  Cross-site scripting
    Check all fields in comments
    Check macro:* bodies and parameters
      filtered_column_code_macro
      filtered_column_flikr_macro
    Do we have trackback support to check?
    Do we need to upgrade to an industrial-strength HTML sanitizer?
    For now, we'll assume that users with access to /admin don't try XSS
  Everything else
    Review http://guides.rubyonrails.org/security.html

Add notes for a security audit
Add notes for a security audit

There's a bunch of stuff we need to check.  Most of it should go very
quickly, but one or two issues may require some work.
