- Promote to public function since it's used in other plugins anyway
- Move resolving of addons to read_products (print errors immediately)
- Cache product list based on mtime; mostly to reduce the amount of spam
from errors as performance was never an issue.
- Cache product object in cart entry, so statiegeld_tokens plugin
doesn't have to do the lookup all over again.
In hindsight, it was a bad idea to allow manipulating the cart (entries)
in hook_checkout, because that hook is used by the `log` plugin. You now
get unused entries in the log.
Although that plugin should maybe have used hook_checkout_done, existing
log file readers (including scripts) and custom plugins may depend on
the CHECKOUT items in the log being before the BALANCE items.
Fixes deadlock if hook_checkout returns ABORT.
One of these days I want to implement the abort mechanism through
exceptions, even though that means handling it explicitly in more
places. Or maybe *because* that means handling it explicitly in more
places.
Apparently nobody uses "return ABORT;" in a hook, because it emitted an
ugly warning. main::abort() takes a list, so destructuring the message
to a scalar was wrong.
add_info was a thing that grew organically to account for hidden
contras, but just wasn't right. The assumption was that if the
contra account is hidden, the contra itself should be hidden from
view - the sign of the amount would be wrong anyway.
The correct approach, however, would of course to flip the sign so it
matches the user's perspective, and to add a separate description string
to display to the user.
One more character so values >= 100.00 don't mess up the columns, at
least up to 999.99. I hope nobody's actually parsing the logs with fixed
character offsets.
It stored the old content, so effectively not changing the file.
I don't really understand why *this* was the version I committed,
because I was sure I tested it and it worked :)
Now implemented via a hidden user called '-cash'.
This also introduces the concept of hidden accounts, that begin with '+' or
'-', for result accounts and balance accounts. Future versions can further
use this for more detailed bookkeeping. The idea behind the sign is that
'-' accounts should be inverted to get the intuitive value. So if the account
'-cash' has -13.37, that means there should be +13.37 in the cash box (or,
well, once the rest of this is implemented and the initial values are then set
correctly.)
This should have been done much earlier, but wasn't done for nostalgic reasons.
To new users, it didn't make sense that you could just enter an amount, and
revbank would just accept that as "withdrawal or unlisted product". It existed
for backwards compatibility with the very first revbank version, which didn't
have a product list, and which was not yet used with a barcode scanner. You
would simply enter the amount and your name, and there were no further
statistics.
Nowadays, there are statistics that are messed up if you don't use the product
codes. And some people were looking for a withdrawal command, and try 'take' as
that seems closest to it, but which instead transfers money to another account.
Additionally, some texts were changed for improved clarity. ("Enter username to
pay", when withdrawing, was confusing: one expects money back, not to pay more.)
The signatures feature has been "experimental" since Perl 5.20 (May 2014), but
expected to stay. After 8 years I'm ready to take the risk :)
Have added Perl v5.28 (June 2018) as the minimum requirement, even though the
current revbank should work with 5.20, to see if this bothers any users. Perl
v5.28 is in Debian "buster", which is now oldstable.
