The eof check has to read a character. It happened to work, but it
was not the right way to check this.
Also added a warning for when someone does "ssh $host revbank" instead
of "ssh -t $host revbank".
This is weird. I'm sure I did test valueless tags. But apparently
between that and committing, the `?` quantifier in the regex got lost,
and I don't know how that happened.
Rationale in UPGRADING.md
It's a big change technically, but converting the format won't be hard
for admins.
There's a compatibility mode with loud warnings in case the file isn't
converted.
It's too buggy; in some edge cases it results in an infinite input loop
with 100% cpu. If you want to restart, use 'restart' instead of eof'ing
the input with ^D.
Wanted to move split_input() to a package for unit testing, thought I'd
move prompt() too since the main executable has become messy, and this
would be a good first step in resolving that.
This won't be relevant for a few years. It's default disabled from Perl
v5.38 which hasn't landed in current Debian stable yet, and since I
intend to support Debian oldstable and stable, there are still many
years ahead of us before this becomes relevant!
Originally, this command didn't have a description parameter. Foo would
use `give xyzzy 10 foo`. Then, a description parameter was added. For
backwards compatibility, if you would enter a username (like `foo` in
this example) in the place of the description, it would finalize the
transaction using that.
However, as the user base grows, several reasonable descriptions exist as
user account names, and that would finalize the transaction under the
wrong user.
It's time to break backward compatibility. If you don't want to leave a
message (it's still optional), that can be done with `x` (like the
`donate` command), or in advanced mode, with `""`.
Because it's likely that people are still very much used to just leaving
the description out, if you enter something that happens to match an
existing username, the input will be rejected.
The current equivalent command line would be `give xyzzy 10 ""; foo` or
`give xyzzy 10 x; foo`. If the `;` (new since v5.0.0) is left out, the
trailing `foo` has to be confirmed with a second press of the enter key.
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.
The ancient decision to let undo perform the checkout by itself still
makes sense from a UX perspective, but keeps requiring specific handling
of edge cases.
In this case, the easiest way to deal with trailing input is to just
abort entirely.
Also: updated lib/RevBank/Plugins.pm to import 'isa' and get up to 5.32
level.
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.
