Not terribly necessary here, because inputs are short, but it's a
good practice. I wish there was a way to just disable backtracking for
the entire regex since this kind of pattern doesn't need any of it.
I can't imagine this to be important but throughout the years it's been
expected by users that "abort" can be quoted and passed to a plugin like
one that prints barcodes.
It's still not possible to pass a literal string `abort` to a follow-up
prompt, leaving this feature only available to advanced users who (hope
to) know what they're doing.
There's a slight mismatch between what users experience as a command,
and how commands are defined in RevBank. Specifically, the common input
"<productid> <username>" is two separate commands: the first adds the
product to the cart, the second finalizes the transaction. This also
means that "<productid> <username> <productid> <username>" was four
separate commands, resulting in TWO transactions.
That's all fine and useful, but when using this advanced input method,
where input is split on whitespace, it lead to unexpected results if
there are insufficient arguments for the follow-up questions of a
command. For example, "take jantje 10 take pietje 10" will interpret the
second "take" as the description, then "pietje" als the first command of
a new transaction, and finally, "10" which is typically not a valid
command. It is much more likely that the user intended two separate
"take" commands and just forgot to provide the description argument, but
RevBank had no way of inferring that intent.
From this commit on, whenever the user intends to enter further input
words beyond the one that finalizes a transaction ($cart->checkout), a
';' is required. If trailing input is present, the checkout is refused
and the user gets a retry prompt.
Similarly, if the user indicates the intention of having finished a
command by inserting a ';' while there are insufficient words in the
command line to satisfy all follow-up prompts (command arguments), the
rest of the command line is rejected with a retry prompt.
There is, however, still no specific requirement for a ';' separator
after a command that does not finalize a transaction (e.g. "<productid>
<username>" or even "<productid> x2 <productid> <username>" remains
valid), or for a command that precedes a ';' to finalize a transaction
(e.g. "<productid>; <username>;" is also valid).
This change catches many, but not all, mistakes.
Was already implicitly required (since 59387ddb) because RevBank::Amount
uses the "isa" feature, which was introduced in Perl 5.32 (but no longer
experimental since 5.36, not 5.32 as the old comment said).
Perl 5.32 was released in June 2020, and ships with Debian bullseye
("oldstable") which was released in August 2021.
A space had a custom plugin that died during hook_checkout, which caused
the CHECKOUT lines to be logged without the corresponding BALANCE, and
indeed no account balances were updated. While the plugin had a bug, it
should not cause a half transaction in RevBank.
After some hesitation, I went with ON ERROR RESUME NEXT because if a
hook throws an exception, that should not interfere with other plugins
(the hook can return ABORT if this it was intentional), including the
calling plugin. An error message is printed (but not logged... TODO: add
hook_plugin_fail to plugins/log) but the show must go on.
During hook_checkout_prepare, however, nothing is set in stone yet, so
this could be used for something that might die, and this instance of
call_hooks() is now the one place where a failing hook should result in
the transaction getting aborted. For this, call_hooks() now returns a
success status boolean. Maybe it would make sense in more places, but I
didn't identify any such calls yet.
RevBank::Cart->checkout used to return a success status boolean, but it
could just as well just die (indirectly, to abort the transaction) since
it can't be called a second time within the same transaction anyway
(because ->set_user must be called exactly once), so continuing with the
same transaction can't result in anything useful anyway.
In some places, error messages were slightly improved to contain a bit
more information.
The cursor was placed after the rejected input, both to indicate where
the mistake was, and to make it easy to <backspace> it out. But since
"retry" is only used when there are trailing words, that means the
cursor would be placed on the space between the mistake and the trailing
input. By putting it at the first character of the rejected input, it
is less visually ambiguous. The user can now use <delete> instead of
<backspace>.
When there were several matches that shared the same common prefix, but
with a different case, readline would eat the input from the case
sensitive longest common prefix up to where the case began to differ.
e.g. when "ibutton" and "iButton-touwtje" were available, typing
"ibu<tab>" would truncate the input to just "i" and on second tab show
both matches, but without ever completing beyond the "i".
(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.
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.
Next input would not be split.
> withdraw 1
Pending:
1.00 Withdrawal
Enter username to deduct 1.00 from your account; type 'abort' to abort.
> undo
Undo is not available mid-transaction. Enter 'abort' to abort.
> undo 123
undo 123: No such product, user, or command.
Of course, "undo 123" as top-level input should have been split on
whitespace.
Top-level input is handled by the 'command' method, so that should be a
reliable way to detect that the prompt is a top-level prompt, rather
than a follow-up prompt. Keeping an additional global boolean was a dumb
approach anyway.
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.
Bug:
> 2x unlisted 6
Please provide a short description: bar foo
foo: No such product, user, or command.
Fixed:
> 2x unlisted 6
Please provide a short description: bar foo
Pending:
2x {
6.00 bar foo
}
Enter username to pay 12.00; type 'abort' to abort.
This shifts the reader's focus to the messages from plugins, such as the
instruction to enter your username to pay.
It also looks nicer next to the new cleaner transaction overviews.
