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>.
Similar to the previous commit to plugins/users, with the additional
change of dynamically sizing the username column.
I believe this is the last place where GAIN/LOSE was displayed to end
users.
Shaves 7 characters off for most lines, and gets rid of infamous
GAIN/LOSE display.
The terms "GAIN" and "LOSE" were originally introduced because having
negative numbers everywhere would look too, er, negative, and having a
"+" for positive numbers would get hard to notice in a right aligned
list. The visibility of the "+" was fixed a while ago, simply by adding
a space between the sign and the number, and now the same style is
applied to the user log view.
Old:
2023-07-05 06:24:54 LOSE 2 1.80 Example [2x 0.90]
2023-07-07 20:55:53 GAIN 1 20.00 Received from someone (example)
New:
2023-07-05 06:24:54 1.80 2x Example [2x 0.90]
2023-07-07 20:55:53 + 20.00 Received from someone (example)
