When we send checks, we don't have a check document anywhere (for
security reasons), we just note the check number. Update the
validation to match. RT#10507.
The main impetus of this change is to rename accounts that were outside
Beancount's accepted five root accounts, to move them into that
structure. This includes:
Accrued:*Payable: → Liabilities:Payable:*
Accrued:*Receivable: → Assets:Receivable:*
UneanedIncome:* → Liabilities:UnearnedIncome:*
Note the last change did inspire in a change to our validation rules. We no
longer require income-type on unearned income, because it's no longer
considered income at all. Once it's earned and converted to an Income
account, that has an income-type of course.
This did inspire another rename that was not required, but
provided more consistency with the other account names above:
Assets:Prepaid* → Assets:Prepaid:*
Where applicable, I have generally extended tests to make sure one of each
of the five account types is tested. (This mostly meant adding an Equity
account to the tests.) I also added tests for key parts of the hierarchy,
like Assets:Receivable and Liabilities:Payable, where applicable.
As part of this change, Account.is_real_asset() got renamed to
Account.is_cash_equivalent(), to better self-document its purpose.
The main motivation for this change is to make sure that higher-level
code deals with the fact that self.units.number can be None, and has
an easy way to do so.
I'm not sure all our code is *currently* doing the right thing for this
case, because I'm not sure it will ever actually come up. It's possible
that earlier Beancount plugins fill in decimal amounts for postings
that are originally loaded with self.units.number=None. I'll have to see
later whether this case comes up in reality, and then deal with it if so.
For now the safest strategy seems to be that most code should operate
when self.units.number is None.
I'm getting to ready to extend this hook to deal with income receipts as
well as expense receipts. These changes let me write the tests in a more
declarative style, so I don't have to duplicate them all again to test
credits as well as debits.
Note that we're only testing debits right now, just like the existing tests,
because the default check_type for check() is PostType.DEBIT. Part of making
the changes will be changing that to PostType.BOTH.
This just returns a constant for now, but we know it may need to be
configurable in the future. Other code can start using this now
to be configurable in the future.
I wasn't too worried about this earlier because the cache mainly stores
a bunch of numbers, but there's a little more than that: the generated
URLs also include original attachment filenames, which might be sensitive
(referencing people's names, bank names, etc.). Tighten security
accordingly.
This returns a cached version of the new rtutil.RT class,
so that a single process can easily grab references to one
instance with one cache of ticket/attachment data, etc.
For now, this is basically the Python version of
ledger-tag-convert.plx. It knows how to create RT web links from
ticket and attachment IDs. It confirms that those objects actually
exist too. It may grow to encompass other functionality in the
future.
This loads settings from the same environment variables and ~/.rtrc
file as the rt CLI.
Note that it does *not* support RTCONFIG and the config file
searching, because right now that seems like more work for more
trouble to me.
As we start reading more sensitive user configuration (like RT credentials),
this fixture makes it simpler to ensure that the tests never read the user's
real configuration, which could lead to problems like passwords in tracebacks.
As I'm pushing to reimplement payment-report/income-report, I see query and
reporting tools will want easy access to these kinds of views, so here it
starts.
* Rename _typing to beancount_types to better reflect what it is.
* LessComparable isn't a Beancount type, so move that to
plugin.core with its dependent helper classes.
* Errors are a core Beancount concept, so move that module to the
top level and have it include appropriate type definitions.
I feel like posting hooks a case of premature optimization in early
development. This approach reduces the number of special cases in
the code and allows us to more strongly reason about hooks in the
type system.
This is the layer that keeps track of the different groups of hooks and
can filter them before runtime. The idea here is that you'll be able
to do things like skip hooks that require network access when you don't
have it, or skip CPU-intensive hooks when you don't need them, etc.
This is the simplest version of a common validation we're going to do:
make sure that a particular piece of metadata has one of a set of
values.
This checker needs some bounds checking but I wanted to err on the
side of committing this early because it introduces so much base
infrastructure.
