TODO

- Still need some way to filter queries by weird stuff (i.e. EffectivelyDatedAssociation, or to filter AttendanceRecords by the dates on the Sessions that they belong_to)
- Replace all the TODOs and FIXMEs with whatever they're asking for (additional checks, use of ordered indifferent hashes instead of arrays of hashes, etc.)
- If there is more than one association from model A to model B and they're both focusable, pick the one with no conditions. If all the associations have conditions, complain and require that the correct association be manually specified (where "correct" might mean none of them should be valid)
  - Alternately, always ignore conditional associations unless they're specifically provided to Mochigome by the model
- Named subsets of different fields on a single model
- Some kind of single-page preview on the edit screen would be cool. Maybe use FOP with fake data and the PNG output option? Slow, tho...
- Automatically set default to 0 on sum and count aggregation
- Better handling of nil in subgroup fields
- Handle has_and_belongs_to_many correctly
- Deal with ignore_assoc properly in both directions and when we see :through assocs
- Refuse to do huge reports (ids_table more than a few thousand rows) beacuse user probably just screwed up the grouping
- Allow row counts that skip layers (i.e. a school count report on School$region, SchoolDetail$comp_shelter should have a top-level box that summarizes the # of schools that do and do not have competency shelters)
- Some kind of on-write caching feature for records that would be expensive to fully re-aggregate every time (i.e. AttendanceRecord)
- Some cancan joins must be allowed to double-back over already-joined tables (i.e. the troublesome SchoolStudent ability)
- Don't take aggregations deeper than focus model layer unless appropriate
  - How to determine "appropriate"? Maybe if the path from data to lower layer adds
    additional restrictions? For example, on Student->Class, it makes sense
    to aggregate Student::AttendanceRecord on the Class layer
    but it wouldn't make sense to aggregate Student::AttendanceRecord all the
    way down on Student->Assignment because Assignment results would
    just be a copy of the Student layer results.