major refactoring to move apps up one level

- I looked up some best practices for how apps should be structured, and the
  overwhelming suggestion was to decouple apps from your site. This will become
  especially important when multiple sites are running side-by-side (one per
  dorm, using the sites module) and all need access to the same shared apps.

- While I was refactoring, I deleted and/or commented out some
  non-mission-critical parts (eg, Haystack search) that I couldn't easily get
  working in the newly refactored system. Sorry.
remove Room objects from schema

(Our new schema doesn't use this because we assume all room numbers come from
some external source, like an uploaded file or the data warehouse, and don't
keep additional info about rooms in the db.)
remove robotic_mailman and related tables

This doesn't work and isn't a feature I'm aiming to fix, so let's just get it
out of our way. When it becomes relevant much later down the roadmap, we can
always revive it from git history.
removing data directory

The only function in here is just a test for functionality that exists for real
in laundry.views
remove AbstractResident

If we're only going to have one subclass, there's no point in having the
abstract parent class. The fields from both have been merged together to
coexist in Resident.
remove Guest and associated files

This one actually should stay, but... basically, due to a botched
rebase, the easiest thing for me to do is to remove it. It'll be back
later, I promise.
simplify Package model

I'll add more fields later, but for now, I wanted to eliminate all the cruft.
simplify Resident model

Likewise, eliminating cruft for now.
move logic into properties of Resident model

Eg, we should never be calculating a user's email from their email address in
view code. This belongs in model logic!
upgrade to the latest Django, v. 1.6

Dormbase was previously using Django 1.4, and it wasn't too hard to switch.
(The main problem was a difference in the url function in views, but a quick
sed fixed that.)

I'm not entirely sure what the benefit of upgrading is because I'm new to
Django, but I think it's better to upgrade now (before we have a giant
codebase) than later.
reset the settings.py file

The settings file was a mess; I didn't understand what most of it meant, and I
wasn't sure if upgrading to Django 1.6 required us to change anything, so I
created a brand-new 1.6 project, copied the settings.py from that, and added
the Dormbase-specific modifications back in. The new file is much cleaner,
though admittedly has slightly less functionality (eg, no logging instructions)
-- but I'm pretty sure all functionality I removed are parts we weren't using.
remove movies feature

The IMDB integration was really shiny, but it also really hinders development
(the populate feature is just so slow). I'm downgrading IMDB integration to
low-pri and will make a generic "desk items" feature (eg, movies, games, vacuum
cleaner) that you can later on subclass to add back the cool movie-specific
features.
remove all search functionality

As I'm constantly updating model code, it doesn't make sense to have hard-coded
in search indices. We can reconsider later whether we want to add Haystack
back, though I'm skeptical -- all the use cases I can think of for search are a
permissions-restricted (ie, to just one site) search on a single model, for
which a simple HTML form with a Django model filter suffices.
update Residents model

-greatly expands the Residents model
-conforms to the object model diagram I created
-ensures every field is validated
add django-extensions

I really want to be able to use shell_plus :)
add ValidateOnSaveMixin

I just got burned by the fact that you can write validators all you
want, but they're only checked (by default) on ModelForm submissions and
not every time you call save. Applying this mixin to a model class will
cause that model to validate every time you save an instance.

Caveat: remember to handle ValidationErrors when you save. This should
hopefully never come up because you're always either doing things
programatically (in which case a ValidationError almost certainly is
indicative of a different bug) or getting potentially dirty input from a
user (in which case you have a ModelForm, which already validated). So
*ideally* this will help us catch logical programming bugs without
actually causing any new problems.
add django-guardian

We're going to want site-based permissions (eg, User is a deskworker *for this
one dorm* only), and it seems like the easiest way to do so is django-guardian,
which lets you specify permissions for a specific instance of an object. We'll
use the convention whereby the only objects we pass to guardian are site
objects, so effectively this lets us use permissions on a site-by-site basis.
remove architecture.txt

It's already out of date, and I have something else (my object model
diagram) to refer to so I won't bother to keep this up-to-date.
Adds helper functions for dealing with user-dorm permissions

Uses django-guardian and permissions attached to Site objects
Use South and fixtures to add Resident permissions

Wow. This is ugly, but I really can't find a better way.

We need some sort of permission system. Furthermore, we need to attach
permissions to dorms. (Eg, an AD whose job covers two dorms should have
certain permissions on those two dorms but none others. So immediately,
we can't just check in code where they live because a user might have
permissions for multiple dorms.)

Permissions do seems like the right route to take. I've decided to use
django-guardian to couple permissions to Site objects. We can then
assign permissions to users by creating groups (eg, Random Hall
deskworkers), putting users in groups, and assigning permissions to
these groups. This lets each dorm individually (via the admin console)
decide what deskworkers should be able to do, rather than enforcing a
universal set of rules in code.

The biggest catch is that django-guardian requires us to associate the
permissions with the site app name, but (1) we can't edit the Site class
directly, and (2) even if we could it violates modularity to have a list
of all permissions in Site. The list of permissions for each app must
live in that app.

With that in mind, the best solution I found was to create a fixture for
each app with the permissions it needs to create, and then to set up
South to install these fixtures.

As an example I created a can_modify_residents permission living in the
residents app. Apparently the South datamigration has JSON in it
describing the Resident table and all joined tables. If the schema
changes before this code goes into production, we may want to
re-generate these migrations.