Make class documents show up in catalog preview.

This way, teachers who try to add class documents don't get confused
when said class documents don't show up in the preview.

ClassSubject.objects.catalog is kind of magical and selects a bunch of
related data in one giant query. Our catalog-rendering code assumes
the presence of said data, so wherever we invoke it we should pass it
classes fetched via ClassSubject.objects.catalog.

We could use catalog_cached instead of catalog since correctness of
student counts (if they even appear) isn't important in the catalog
preview. However, the performance hit is tiny since few people even
look at catalog previews--and whatever comes out of render_class_core
*needs* to be correct because that will be cached and reused in the
actual catalog.

(Said observation about caching also implies that student confusion is
a relevant motivation for this fix.)
Make render_class_core depend on qsdmedia.Media.

This is in case teachers upload class documents and then immediately
check the catalog preview to see whether they show up.

Some remarks to the future:

1. This will likely require adjustment when the schema simplification
   project gets merged.

2. Using depend_on_row instead of depend_on_model implies we won't
   catch when a document moves from one class to another. However, I'd
   bet that almost never happens; and I think it's worth not having to
   regenerate the whole catalog every time a teacher uploads a file.

3. This silently fails to empty the right cache if it hits a DataTree
   node with more than one ClassSubject on it. I suspect such DataTree
   errors have enough other symptoms that we can pretend they never
   happen. Also, in a few months, remark 1 will make this irrelevant.
Merge pull request #393 from pteromys/stable-jul12-bugfixes

Catalog preview and class documents
Added 'School' Field to onsite reg.

Added 'school' field to onsite student registration as per issue #495.
Field inputs data into 'school' field of studentinfo, but doesn't
fill in 'k12school' field or include the related autocomplete
capabilities. Field is optional.
Merge branch 'main' into issue406
Merge branch 'main' into issue406
Cleans up some user types code

There were previously many places in the code where lists of the
different user types were defined. Improves this by making everything
reference either ESPUser.getAllUserTypes() or ESPUser.getTypes() (the
latter of which now correctly queries the former).

There were also previously some places in the code where hard-coded
lists of the user types with ProgramModule user list functions (e.g.
students(), teachers(), volunteers()). Improves this by making class
variables USER_TYPES_WITH_LIST_FUNCS and USER_TYPE_LIST_FUNCS which
store this list, and making everything else reference these constants.

Finally, use these different lists to automatically generate the
students(), teachers(), volunteers() and num_students(), num_teachers(),
num_volunteers() functions, rather than manually generating these
separately from the list of such user types.

(Reworked the way that isStudent(), isTeacher(), etc. are generated to
be in a similar style to the way students(), teachers(), etc. are now
generated. The old method no longer works under this scheme, because
having the old create_membership_methods() class function (which was
called at the module level) call getTypes() was causing Django
validation errors, since getTypes() calls getAllUserTypes() which calls
a method on the Tag model, which is apparently not allowed at the module
level.)
Fixes commpanel bug with e-mailing parents

Because there is no Program.parents() method, the commpanel filters for
Guardians and Educators was failing. Refactored the UserSearchController
to always use the user type name (Student, Teacher, etc.) rather than
the filter method names (students, teachers, etc.), and separated
Guardians and Educators into their own categories (rather than grouping
them under parents) to avoid this problem.
Fixes bug in previous commit
Merge branch 'main' into parent_comm_panel_fix
Fixes student schedule during lottery

d592d67 / Github pull request #434 (the fix for Github Issue #429)
changed StudentClassRegModule.deadline_met() to check for FCFS _or_ LSR
being open. This was a correct behavior for that particular use case of
deadline_met() (to control the display of the "Student registration no
longer open" message on the studentreg main page), but turns out to not
be the correct behavior for all use cases. The change from d592d67 was
causing "add class" links to show up on the studentreg main page during
the lottery phase, which is incorrect behavior.

This change reverts StudentClassRegModule.deadline_met() back to its
original functionality, adds a new method deadline_met_or_lottery_open()
that checks for FCFS or LSR being open, and uses this new method to
control the "Student registration no longer open" message.
Increased speed of manage class (fixes issue 68).

Changes taken from suggestions in the issue #68. groupedClassrooms call is replaced by faster call that only does what is needed.
Switch ESPUser.getTypes() and .getAllUserTypes() to caching API
Merge branch 'main' of github.com:learning-unlimited/ESP-Website into main
Remove broken, now unnecessary import from dbmail_cron.py
Disable context processors when rendering e-mail

In recent versions of Django, Context includes a RequestContext.  A
RequestContext passes your context through the context processor functions
defined in settings.TEMPLATE_CONTEXT_PROCESSORS before rendering.  This is
normally very helpful, but in the case of rendering previews for e-mail
messages it causes a problem.  The 'esp_user' context processor sets the
'user' variable in the context to the user of the current request (e.g.
the admin), overwriting the 'user' variable (ActionHandler object) set by
the comm panel code.  As a result, any smart text placeholders of the form
{{ user.* }} will show the current user, rather than the recipient user.

This commit works around the problem by disabling all of the context
processors while rendering the e-mail preview.
I also added this to the code we use to generate actual e-mail messages
(separately from the comm panel preview), although this may not be
necessary since I don't think the RequestContext is active
Make cancelling a class unschedule it by default

It's unusual for a class to be reinstated after it's been cancelled.
Hence it makes sense to unschedule the class and free up the room[s] and
timeslot[s] for potentially scheduling other classes.
Add control over which students are e-mailed when a class is cancelled

During first-come first-served registration or close to a program, you may
want to only e-mail enrolled students when you cancel a class.  Earlier
on, you may want to e-mail lottery students as well so they can change
their preferences accordingly.  Rather than having the Web site make this
decision for you, it now lets you choose which group should receive the
e-mail announcing that the class is cancelled.
Updated to use database to handle getting what we want.
Added duration, grade range to the Status on the program dashboard.