When a repeat payment is detected to soon be eligable for sending, but
the user has not approve it yet, we show a notification from the
background process to entice the users to go and approve it.
This popup now also carries a 'disable' text which disables the repeat
payment, effectively shutting up this and further notifications.
The tricky part to make this work is that the notification is showing
while the application is (likely) not actually active.
This takes the strategy that the notification carries some extra
details. Among others a newly introduced unique id for a notification
itself, and also some text to show on actually processing the disable
action.
The processing just writes a file, to avoid complexity and side-effects.
The file will then be read on start up (either foreground of background)
to action on the lines in there. So the item will be disabled on first
load.
This shows more details, like the target address.
This also made the screen able to handle multiple outputs in a payment,
though that is a bit tricky with regards to which values we allow
editing.
When the user manually pastes an address, this would also be a payment
object and that makes no sense to save. So make it configurable
and have external payment protocols (i.e. 3rd party invoices) as well as
repeated payments get saved.
The Wallet object used to have a guarenteed lifetime longer than the App
singleton, but then we started allowing people to delete their wallet
(argh!).
Also "external" modules, especially living outside of the main tree,
would be much more stable if they can avoid using raw pointers for core
concepts like the Wallet.
Repeat payments are handled in the background process and issues and
indeed successes need to be shared to the user via notifications.
We now have notifications for:
∙ successfully sending a repeat payment
∙ when a payment is due soon, but not approved.
∙ when a payment is due soon, but not enough funds are in wallet.
The tx-broadcast was tied completely to a 'payment' object, this is now
more made into individual parts that can be reused outside of the
'payment' usecase.
The Payment specific methods paymentAmount and paymentAmountFiat are now
made to return the data from the first output and no longer required
there to be exactly one.
This allows these methods to still give useful info in the case of
payment protocol based creation of more complex payment objects.
This takes the concept added some 5 years ago to Electron-Cash and adds
this to Flowee Pay as well.
In a nutshell, it allows a bip21 style payment request to include a
'comment' with the argument op_return_raw
This comment is expected to be a hex-encoded data payload that then will
be added as a single output to the transaction we build to fullfill the
payment request.
As a natural consequence of how uri's work, adding the argument multiple
times will cause multiple outputs to be generated. We check that this
does not exceed the expected max sizing for op-return.
This changes two implementations of the BroadcastTxData baseclass
to now use one which is a lot more robust and thread-safe as
well as fixing various smaller issues.
This specifically allows pasting and scanning of bitcoincash addresses
without the 'bitcoincash' prefix.
Additionally this cleans up the QRScanner API a little and merges two
methods.
Last, at popular request, this makes showing the address on the
confirmation screen default to be on.
This allows people to actually verify the address they pay to.
Except when paying to a BIP70 payment because that is practically
speaking a system that avoids talking about addresses in the first
place. No point in trying to verify the actual address THERE.
For desktop we now properly support starting a payment when
the user clicks on a bitcoincash link in a browser.
For Android the activation logic _should_ work, except that the
Android specific way has yet to be tied to our app.
Squash of 12 commits, this makes the UX actually useful and
we detect errors and show errors and warnings to the user.
This also adds an 'editable' bool to OutputDetail in order to
disable editing of a payment request address.
Additionally, this introduces the ability for a Payment to carry
a raw script instead of an address. So op-return or more complex
payment requests will be sent just fine.
Fun fact is that our broadcast is INV/SendData, which is two
roundtrips and thus slow, which is needed to be sure we get proper
rejection messages.
The sending of the transaction via BIP70 causes the network to
already know about the tx because the server we send it to has
likely much better Internet than we do.
So confirmation from the payment provider is used to show success
instead of the normal way.
This adds the basic support of bip70 style payments.
Some todos are left which are mostly about interaction with
other parts of the app and require bigger changes to make
it work smoothly.
This is a long overdue cleanup around the ideas of entering
numbers in Flowee Pay.
The core dataclass BitcoinValue now keeps track where the number
came from, either user input or some calculation. This allows
us to have the Fiat and the Coin price stay in sync without weird
problems.
The one we type uses a string, the price field that we are not typing in
is then a slave and we follow the auto-generated number as the
source.
This solves a host of known issues:
* Editing of value objects is much more consistnnt and predictable now.
* Switching to a different fiat type now properly re-calculates the
values that are slaved. So if the primary is a BCH value then the fiat
value gets the new exhange rate instantly applied.
* Switching to a different fiat type properly applies having a separator
So if you go from euro to Japanese yen, we now remove the separator
and the numbers behind it.
* Changing the app setting from BCH to mBCH now properly updates all
amounts. Notice that the user-typed string wins, if you typed 2 and
then change to mBCH we assume you wanted 2, not 2000.
* Paste now works more logcally.
* Cursor is no longer sometimes invisible, requiring backspace to make
it show up.
And last we now protect against too large numbers. It is seen as an
error to type a number above 21 million BCH.
Fixes#19
A payment request, for instance a QR code, which includes an amount to
be paid is expected to not change the to-be-paid amount, uses being
dropped
in the price editing UI is therefore a bit weird. Almost an
anti-pattern.
This honors that concept and when the price is included in the scanned
QR, we change the UI layout to removed the editing widgets and show
static display widgets instead.
This also adds a header menu item to edit the amount to be paid and
get back to the old UI.
Additionally, a new UI is added to show the address we are about to pay
to, likewise reachable from the header menu.
The basic usecases of instapay is that the payment request is filled in
one go (from QR for instance) and thus we try to send.
If that fails (not enough funds or whatever), we disable instapay in
order to avoid 'magic happens' user experiences.
This merges the paymentAmount and effectiveBchAmount methods because they
did 99% the same.
Same with the paymentAmountFiat and effectiveFiatAmount.
This removes the 'effective*' set of properties.
to reset the payment removes all user set properties, giving you a clean
payment object.
Since the exchange rate is both not user-set and also not something that
is expected to change between one payment and the next, it is now no
longer cleared on reset().
For the payment object it now is possible to insta-commit to changes and
as such always prepare a transaction ready to be sent with the latest of
the settings.
This is enabled with a boolean property 'autoPrepare' (default off).
Move the signals to the right class and remove an include from the
header file.
Also provide a context object in QTimer::singleShot. Useful to avoid
dangling pointers being dereferenced on shutdown.
Slowly the amount of cpp sources has been growing to the point
where its just too much to store in the root of the project.
I think they are more happy in a subdir as well, getting an elevated
position for themselves.
tomFlowee