TODO
====

Template multiplexing with action hooks
---------------------------------------

* Add a hook that simply reads information from a configuration file section ``[template variables]`` and adds it to the entry data.

* Add a hook that changes what template to use based on other entry data.  (This needs more specification.)
  OR, should this be a hook that just adds more entry data, and trusts the Ledger entry template to use it?

Bug fixes
---------

* Parsing open date ranges raises an exception

New importers
-------------

* Stripe import via API
  * This is going to require giving importer objects the configuration so they can read things like API keys.
* YourCause
* Network for Good

Other feature requests
----------------------

* Some way of preventing re-imports

User niceties
-------------

These haven't been requested yet but it's easy to imagine how they make the program more user-friendly.

* ``load_hooks`` and ``skip_hooks`` configuration options to limit what hooks are used.
  Setting ``load_hooks`` means "skip everything not in this list."
  Not setting ``load_hooks`` means "only skip what's listed in ``skip_hooks``."
  If neither setting is set, ``skip_hooks`` should default to a list of hooks that have business-specific logic (currently just ``add_entity``).
  If a hook is listed in both, it's either skipped or a configuration error (TBD).
* Try all importers even after one fails
* Clean up error reporting on bad configuration file syntax.

Code infrastructure
-------------------

* Open files for import in binary mode; add a text-wrapping importer base
* Write a utility dict transformer.  Given a source dictionary, it returns something like ``{new_key: transform(source[old_key]) for old_key, transform, new_key in configuration}``.
  A lot of the CSV importers are doing this ad hoc now, so refactoring out a common way to do it could help speed up development of future importers.