Files @ db59d2fc8ceb
Branch filter:

Location: NPO-Accounting/import2ledger/TODO.rst

Brett Smith
hooks.ledger_entry: Look up templates dynamically.

If there's a 'ledger entry' key in the entry data, use that value as the
name of the template to load. Thanks to this, nbpy2017 could collapse
multiple importers into one.

Otherwise, build a default template name based on the importer source, and
try to use that.

All the configuration names now end with "ledger entry" instead of starting
with "template". This makes it clearer what they're for, in case we
support other kinds of output templates in the future.

I ended up changing the names of some of the importers so the default
template name was nice, rather than specifying template names for all of
them, to reduce the amount of name discrepancies across the codebase.
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?

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

* Stripe import via API
* 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.