* Provide dedicated formatting for more Beancount types.
* Improve code to determine when we're looking up link metadata
and should format output as links.
query-report was heading to a place where it was going to bifurcate. You
could structure input with its own special input switches, and with ODS
output, it would have its own dedicated grouping logic and use that.
But those things shouldn't be tied together for users. Instead, add
functions to BQL to be able to do the kind of grouping we want. This commit
adds those. Next we'll extend the ODS output to detect and format these
groups correctly.
This provides more flexibility in repository setup while remaining backwards
compatible.
The changes to test_reports_query are just to accommodate the new
transaction in 2020-expenses.beancount.
Ultimately this is going to be a tool that can generate nicely-formatted
spreadsheets from arbitrary bean-queries. This initial version doesn't
generate spreadsheets yet, but it does integrate our usual books-loading
tools and rewrite rules into existing bean-query functionality, so it's a
start. It also has some of the query building and parsing that higher-level
spreadsheets will need.
Now that we have richer exceptions, this is the easiest way to refactor out
rewrite rule error handling from the various main functions where it
currenly lives.
This functionality already existed in the code three times, and it's about
to get more important for the ledger report, so now was the time to abstract
it.
We've long supported skipping documentation checks by flagging the
transaction. We haven't done the same for enumerated metadata because we
need it less often, and bad values tend to do more damage to reports.
However, occasionally when something very off-process happens, we do need it
as a matter of expediency. So support it.
In order to skip validation of these fields, the plugin requires that the
value start with the string "FIXME". This helps ensure that reports have a
consistent way to detect and warn about unfilled values in flagged
transactions.
This is friendlier to the YAML input and consistent with FieldFlags.
Less consistent with the rest of the codebase, but local consistency matters
more IMO.
Next steps:
* A tool to fill the PDF form based on values written to that YAML.
* An extension to fill some of those values with numbers queried from the
books (which is why we need something more involved than FDF).
Where assertions are removed from individual tests, I believe that
functionality is covered by other tests (although probably not to the extent
of checking multiple splits).
A few motivations for this:
* This makes the fund report more maintainable, because the data structure
is better suited to the task at hand, making it easier to follow what's
going on.
* This helps put Balances through a little more testing with a high-level
report.
* This makes the fund report a little faster, since totals are usually
calculated from a smaller number of Balance objects rather than all
Postings over a period.
This is less "future-proof," but the thing is, it's premature to try
to anticipate what other link formats will be in the future. See
discussion in comments.
