DD37 tweaks (refund / payment diagrams)

2 files changed, 23 insertions, 42 deletions

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst
index abc6c131..0b6e2b13 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -14,6 +14,13 @@ Motivation
 The transactions in wallet-core all should have an associated state machine.  All transactions
 should have some common actions that work uniformly across all transactions.
 
+Requirements
+============
+
+The underlying state machine should make it obvious what interactions
+are possible for the user.  The number of possible user interactions
+in any state should be small.
+
 Proposed Solution
 =================
 
@@ -43,6 +50,8 @@ There are some other distinctions for pending transactions:
 ``done``: A transaction that is done does not require any more processing.  It also
 never has a ``lastError`` but is considered successful.
 
+``dialog``: A transaction requires input from the user.
+
 ``aborting``: Similar to a pending transaction, but instead of taking active steps to
 complete the transaction, the wallet is taking active steps to abort it. The ``lastError``
 indicates errors the wallet experienced while taking active steps to abort the transaction.
@@ -62,6 +71,8 @@ to abort a transaction is paused.
 possibly not even be aborted properly.  The user may have lost money.  In some
 cases, a report to the auditor would make sense in this state.
 
+``expired``: Similar to ``failed``, but the failure was caused by a timeout.
+
 ``deleted``: A ``deleted`` state is always a final state.  We only use this
 state for illustrative purposes. In the implementation, the data associated
 with the transaction would be literally deleted.
@@ -107,7 +118,7 @@ transaction and puts it in an ``aborted`` state, or starts the necessary steps t
 actively abort the transaction (e.g. to avoid losing money) and puts it in an
 ``aborting`` state.
 
-``[action:force-abort]``: Directly puts an ``aborting`` transaction into a
+``[action:cancel-aborting]``: Directly puts an ``aborting`` transaction into a
 ``failed`` state. May result in an ultimate loss of funds (beyond fees) to the
 user and thus requires additional consent.
 
@@ -118,11 +129,6 @@ example, deleting a withdrawal transaction does not delete already
 successfully withdrawn coins. Deleting is only safe (no money lost) on initial
 and final states (failed, aborted, done).
 
-``[action:force-delete]``: Directly puts a transaction into a ``deleted``
-state. May result in an ultimate loss of funds (beyond fees) to the user and
-thus requires additional consent.
-
-
 Whether aborting, deleting or suspending are possible depends on
 the transaction type, and usually only one of the four choices should be
 offered.
@@ -161,9 +167,6 @@ the account needed to be frozen.  The user should contact the exchange
 provider's customer service department and seek resolution (possibly through
 the courts) to avoid loosing the funds for good.
 
-``user`` / ``user-*``: The user needs to do some interaction
-for the transaction to proceed.
-
 
 Transaction Type: Withdrawal
 ----------------------------
@@ -465,40 +468,12 @@ Transaction Type: Refund
 A refund is a pseudo-transaction that is always associated with a merchant
 payment transaction.
 
-* ``pending(merchant)``
+* ``pending(accept)``
 
   Initial state for a refund.
 
-  A refund is pending in this state while we are waiting for the merchant to
-  get a successful response from the exchange (and relaying that error response
-  to the wallet).
-
-  * ``[action:suspend] => suspended(merchant)``
-  * ``[processed-success] => pending(refresh)``
   * ``[processed-error] => failed``: we received a permanent failure (such as money already wired to the merchant)
 
-* ``suspended(merchant)``
-
-  Refund processing was suspended while waiting for the merchant.
-
-  * ``[action:resume] => pending(merchant)``
-  * ``[action:force-delete] => deleted``
-
-* ``pending(refresh)``
-
-  The wallet is now refreshing the coins.
-
-  * ``[processed-success] => done``
-  * ``[action:suspend] => suspended(refresh)``
-  * ``[processed-error] => failed``: we received a permanent failure.
-
-* ``suspended(refresh)``
-
-  Refund processing was suspended while waiting for the refresh to complete.
-
-  * ``[action:resume] => pending(refresh)``
-  * ``[action:force-delete] => deleted``
-
 * ``failed``
 
   The refund failed permanently.
diff --git a/design-documents/043-managing-prebuilt-artifacts.rst b/design-documents/043-managing-prebuilt-artifacts.rst
index 00821392..3d0debc8 100644
--- a/design-documents/043-managing-prebuilt-artifacts.rst
+++ b/design-documents/043-managing-prebuilt-artifacts.rst
@@ -1,12 +1,12 @@
-DD 43: Managing Prebuilt Artifacts
-##################################
+DD 43: Managing Prebuilt Artifacts and Source-Level Dependencies
+################################################################
 
 Summary
 =======
 
 This design document defines how the GNU Taler project manages prebuilt
-artifacts that are used as source-level dependencies in source code
-repositories.
+artifacts and other source-level dependencies in repositories
+that are part of project.
 
 Motivation
 ==========
@@ -23,6 +23,12 @@ Examples are:
 * (formerly): The ``taler-wallet-core-embedded.js`` file used
   by the Android repo.
 
+Another type of source-level dependency is on other **source** files.
+Examples for this are:
+
+* The ``build-common.git`` repository that contains common build-time helpers
+* The ``gana.git`` repository 
+
 Requirements
 ============