For a slightly better experience for new installations. Admins of
existing revbank installations should read UPGRADING.md for information
on how to update the revbank.plugins file.
- withdraw is now under the specific commands
- more non-commands things moved to the first category
- some plugins added, defaults changed
(Bumps version to 3.8 because admins should update the plugin list.)
Deduplication didn't work on quantified additions, i.e. if you added
"20x clubmate" when there was already clubmate in the cart, it would add
just ONE item, and have a lingering message that the next thing would be
multiplied by 20.
This old bug was especially annoying if there is a barcode "20x
clubmate" to scan 20 bottles (which is the size of a crate), and this is
repeated.
The fix also uncovered another bug: newly added entries were selected
too early. There are two hooks, hook_add_entry and hook_added_entry, and
of course the selection should happen in between, not before the former.
No entry in UPGRADING.md, because I think it is extremely unlikely that
any plugin author will have used the selection feature yet, which is
very new.
Experimental code (never committed) had ANSI escape sequences there, and
required manual padding. Those were gone, but I forgot to change the
manual padding into normal sprintf padding.
This also makes it explicit that the left alignment is actually intended
here. (Actually looks better here.)
As a side effect of a7a5f14e, "123 x <product>" (with a space between the
number and the operator) is no longer supported. Breaking that was
unintentional, but since it was an undocumented feature and unintuitive
hack anyway, the feature won't come back.
When it still worked, it was implemented by *converting* a raw amount
(withdrawal or unlisted product, which you could still enter as just a
number -- since the aforementioned commit you need to be explicit and
use `withdraw` or `unlisted`) into a stub that would finally apply a
repetition when adding something else.
Done in the _write routine, which means tokens will not expire the exact
moment they should, but the first transaction after that. And if that
transaction is done by the user, they're in luck as expiry checking
happens after using them tokens.
- 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.
Since that logic was factored into its own sub and is basically the same
as what was used here, let's use it here too.
This is still somewhat duplicated functionality from products::command.
Should adding addons be done in _read_products instead?
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.
Activating statiegeld_tokens will limit the use of the statiegeld plugin
for container deposit refunds to what was bought at this venue.
Still needs documentation.
Changes to 'statiegeld' and 'undo' were made to support the new
plugin, specifically:
- metadata (attributes) added in $cart->add, for the statiegeld_tokens
plugin to use.
- statiegeld plugin now shares a global variable (configuration).
- undo can now be rolled back during hook_checkout.
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.
