[taler-docs] 01/02: whitespace

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository docs.

commit c68cb55278b9e1d6ce5cfebb5f948ccbf56be41e
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sat Apr 8 17:14:27 2023 +0200

    whitespace
---
 .../037-wallet-transactions-lifecycle.rst          | 38 +++++++++++-----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst 
b/design-documents/037-wallet-transactions-lifecycle.rst
index 3cc807e..8a8df2e 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -21,8 +21,8 @@ Common States
 The following states apply to multiple different transactions.  Only pending
 and aborting have transaction-specific sub-states, denoted by 
``state(substate)``.
 
-``initial``: The initial state is the result a user interaction. A transaction 
-may have more than one initial state (if it is started in multiple ways) or 
none 
+``initial``: The initial state is the result a user interaction. A transaction
+may have more than one initial state (if it is started in multiple ways) or 
none
 (if it's the result of another process)
 
 ``pending``: A pending transaction waits for some external event/service.
@@ -48,9 +48,9 @@ complete the transaction, the wallet is taking active steps 
to abort it. The ``l
 indicates errors the wallet experienced while taking active steps to abort the 
transaction.
 
 ``aborted``: Similar to a ``done`` transaction, but the transaction was 
successfully aborted
-instead of successfully finished. It will have the information of when 
(timestamp) it was 
+instead of successfully finished. It will have the information of when 
(timestamp) it was
 aborted and in which pending sub-state the abort action was initiated. Also, 
we can
-include more information information relevant to the transaction in 
`abortReason` 
+include more information information relevant to the transaction in 
`abortReason`
 
 ``suspended``: Similar to a ``aborted`` transaction, but the transaction was 
could be
 resumed and may then still succeed.
@@ -83,12 +83,12 @@ states: ``pending(*)`` and ``aborting(*)``.
 
    Should we show the retry timeout in the UI somewhere?  Should we show it in 
dev mode?
 
-   SEBASJM: Since the wallet will retry anyway, maybe is better if we replace 
the "retry" 
+   SEBASJM: Since the wallet will retry anyway, maybe is better if we replace 
the "retry"
    button with a "try now" button and a side text "retrying in xxx seconds"
 
-``[action:abort]``: Aborting a transaction either directly stops processing 
for the 
-transaction and puts it in an ``aborted`` state or starts the necessary steps 
to 
-actively abort the transaction (e.g. to avoid losing money) and puts it in an 
+``[action:abort]``: Aborting a transaction either directly stops processing 
for the
+transaction and puts it in an ``aborted`` state or starts the necessary steps 
to
+actively abort the transaction (e.g. to avoid losing money) and puts it in an
 ``aborting`` state.
 
 ``[action:suspend]``: Suspends a pending transaction, stopping any associated 
network activities, but with a chance of trying
@@ -115,15 +115,15 @@ Common pending sub-states
 ---------------------------------
 
 During the pending state the transaction can go through several sub-states 
before
-reaching a final state. Some of this sub-states are shared between different 
+reaching a final state. Some of this sub-states are shared between different
 transaction types:
 
 ``kyc-required``: The transaction can't proceed because the user needs to 
actively
-finish a KYC process. Part of a withdrawal process or peer-to-peer push 
credit. 
+finish a KYC process. Part of a withdrawal process or peer-to-peer push credit.
 
 ``aml-required``: The transaction can't proceed because the user needs to wait 
for
-the exchange operator to conclude an AML investigation by the staff at the 
exchange. 
-The user is not expected to take any action and should just wait for the 
investigation 
+the exchange operator to conclude an AML investigation by the staff at the 
exchange.
+The user is not expected to take any action and should just wait for the 
investigation
 to conclude. Part of a withdrawal process or peer-to-peer push credit.
 
 ``aml-frozen``: The staff at the exchange decided that the account needed to 
be frozen.
@@ -162,7 +162,7 @@ user. So special-casing this and testing this is IMO just 
not worth it.
   exchange.
 
   (??) is this needed? let say that the money is wired but the signal
-  never of the bank confirmation reached the wallet, what should happen? 
+  never of the bank confirmation reached the wallet, what should happen?
 
   * ``[poll-success] => pending(exchange-wait-reserve)``
   * ``[action:abort] => aborting(wallet-to-bank)``
@@ -205,7 +205,7 @@ user. So special-casing this and testing this is IMO just 
not worth it.
 * ``aborted(partially-withdrawn)``:
 
   In this state, the wallet should show how much money arrived into the wallet
-  and the rest of the money will be sent back to the originating bank account 
+  and the rest of the money will be sent back to the originating bank account
   after ``$closing_delay``.
 
 * ``done``
@@ -254,7 +254,7 @@ instructedAmount, effectiveAmount and the affectedAmount 
(partially effective am
   of transitioning the UI into a ``pending(repurchase-session-reset)``
   on a different transaction (which before was in ``done``).
 
-  (??) should not reset another transaction? 
+  (??) should not reset another transaction?
 
 * ``pending(proposed)``
 
@@ -284,7 +284,7 @@ Submit coin by coin (or in bulk groups) until payment is 
complete.
 
 * ``pending(refundable)``
 
-The payment succeed but if auto-refund-check is active it will be checking for 
refunds 
+The payment succeed but if auto-refund-check is active it will be checking for 
refunds
 
   * ``[auto-refund-timeout] => done``
 
@@ -334,7 +334,7 @@ A refund is a pseudo-transaction that is always associated 
with a merchant payme
 
   A failed refund can technically still transition to ``done``, because the 
wallet
   doesn't query some refund resource, but the purchase for refunds.  Thus, a 
previously
-  failed refund can suddenly transition to ``done``. 
+  failed refund can suddenly transition to ``done``.
 
   (??) separate transient error vs permanent error ?
 
@@ -409,7 +409,7 @@ Submit coin by coin (or in bulk groups) until deposit is 
completed.
 
   * ``[action:abort] => aborting(refund)``
   * ``[processed-success] => pending(track)``
-  * ``[processed-error] => aborting(refresh)`` 
+  * ``[processed-error] => aborting(refresh)``
 
 * ``pending(track)``
 
@@ -605,7 +605,7 @@ Wallet read the taler:// URI
 
 * ``pending(refundable)``
 
-The payment succeed but if auto-refund-check is active it will be checking for 
refunds 
+The payment succeed but if auto-refund-check is active it will be checking for 
refunds
 
   * ``[auto-refund-timeout] => done``
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.