The hook gets fired for each product individually, so a single mtime
update is not good enough.
The timestamp needs to be recorded per product or tag. Meh.
RevBank reads the new products file on every interaction (e.g. pressing
enter), and then fires hooks like `product_changed`. Every running
instance gets those hooks, but the price tage should be generated only
once.
There was a bug with the example product defined as:
+smk,matekrat 1.50@+statiegeld "..."
Only the id `+smk` was considered, and no total price was calculated. This
broke the accessible id `matekrat`. The fix is to consider the keys of
the products in the hash, instead of the `id` field.
- Adds price tag calculation. Addons tagged #OPAQUE are excluded from the
price tag.
- BREAKING CHANGE: instead of abusing $product->{price} for a percent,
$product->{percent} is no longer a boolean but the actual percent, so
$product->{price} is the calculated amount.
The total price of a product is now calculated in two places, once when
reading the product list, and once as the result of adding the entry and
its contras when adding the product. Although this involves some
duplication and the sums are calculated in different ways, it hinges on
the existing assertion to make sure that the entry is balanced to ensure
that both sums are the same. Because of that, this code duplication
actually strengthens the integrity.
Prevents (parts of) transactions if a user does not have sufficient
money.
The default configuration allows negative balances for buying products
and for multi-user takes.
When the transaction is still pending, the past tense is incorrect.
This is not relevant for the contras, because those descriptions are
only displayed in logs, after the fact.
RevBank uses atomic file replacement by creating a new file and renaming
it over the old one. The newly created file is always in cwd, and
for the atomic rename() to work it must reside on the same filesystem as
the file it's replacing. Since File::Temp does the right thing and
creates files in /tmp by default, and /tmp is usually on a different
filesystem, these unit tests didn't actually work.
I don't know why they did work in the past. There doesn't seem to have
been any relevant change (or any at all, for that matter) to File::Temp,
which has had this behavior for ages. But I can't imagine that my /tmp
has only recently become a tmpfs mount either.
In any case, the issue is fixed by making File::Temp do the wrong thing,
which is to create its files in the cwd.
A sufficiently big number, i.e. longer than a long long, had interesting
effects. Perl would promote it to a float, and format it as -1 in
sprintf, which RevBank::Amount didn't handle correctly. In extreme cases
the number got rounded to Inf and would no longer round-trip.
As a result, numbers returned by RevBank::Amount are now Math::BigInt
and Math::BigFloat objects. Those should be transparent to all existing
code. It's amazing to see the unit tests pass.
I don't think there is any actual use case in RevBank for numbers this
large and I don't think anyone will have actually encountered the
aforementioned weird effects. Mostly, the input would be parsed with
parse_amount which refuses any number greater than 99900 anyway. Only
where parse_string was used directly, such large numbers could actually
have been used, but in stock RevBank that is only done when reading the
accounts file.
This change also introduces a new global function parse_any_amount that
is like parse_amount but doesn't complain about negative or large
numbers, to further improve the adduser plugin (see previous commit) in
insane edge cases. It differs from RevBank::Amount->parse_string in that
it does support addition and subtraction operators.
Old message was not as intended:
> Name for the new account: 123123123123
> That's way too much money. Enter 'abort' to abort.
Fixed:
> Name for the new account: 123123123123
Sorry, that's too numeric to be a user name. Enter 'abort' to abort.
Since the first versions of RevBank, negative and huge amounts are
handled centrally, and since v2 (2013) they've been implemented through
an exception that caused the pending transaction to be aborted. Since v3
(2019), RevBank has had a retry mechanism for rejected input to improve
the user experience, but it required a REJECT return message from a
plugin, not an exception. Now there's an exception class to trigger the
same semantics.
Commit 52749df5 added more information to error messages to aid
debugging, but most plugin follow-up questions are code references, not
method names, and they would result in an ugly CODE(0x...) in the error
message.
This change adds the fully qualified name of plugin methods. Not sure if
I like that, I might drop the RevBank::Plugin:: prefix at some point.
This somehow escaped change with the introduction of RevBank::Amount in
v3.2 in 2021, which only now became relevant due to the recent change in
v6.1.0 which turns invalid account balances into a feature.
