gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[taler-docs] branch master updated: add svg


From: gnunet
Subject: [taler-docs] branch master updated: add svg
Date: Mon, 27 Mar 2023 20:13:06 +0200

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

sebasjm pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 7ac70df  add svg
7ac70df is described below

commit 7ac70df76f72d1105af802c0d1beddb02666c06d
Author: Sebastian <sebasjm@gmail.com>
AuthorDate: Mon Mar 27 15:13:00 2023 -0300

    add svg
---
 .../037-wallet-transactions-lifecycle.rst             | 19 ++++++++++++++-----
 transaction-common-states.svg                         | 16 ++++++++++++++++
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/design-documents/037-wallet-transactions-lifecycle.rst 
b/design-documents/037-wallet-transactions-lifecycle.rst
index 992c737..56ddda9 100644
--- a/design-documents/037-wallet-transactions-lifecycle.rst
+++ b/design-documents/037-wallet-transactions-lifecycle.rst
@@ -45,6 +45,10 @@ indicates errors the wallet experienced while taking active 
steps to abort the t
 .. attention::
   Should there be an abortReason for aborted transactions?
 
+  sebasjm: yes, although it doesn't mean that the user need to add this 
information
+  manually. The information we save in the abort operation can help the user 
to know 
+  how and when the operation was aborted.
+
 ``aborted``: Similar to a ``done`` transaction, but the transaction was 
successfully aborted
 instead of successfully finished.
 
@@ -93,6 +97,9 @@ states: ``pending(*)``, ``kyc-required(*)``, ``updating(*)``, 
``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" 
+   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 ``aborting`` state.
 
@@ -104,15 +111,17 @@ to take longer (such as a backup, recovery or very large 
withdrawal operation).
 
 ``[action:abort-force]``: Directly puts an ``aborting`` transaction into the 
``failed`` state.
 
-``[action:retry]``: Reset the retry timeout / reset long-polling
-for a pending transaction and immediately try processing the transaction again.
-We usually don't explicitly document this self-transition.
-
 
 Whether aborting or resuming is possible depends on the transaction type, and 
usually only one
 of the two choices should be offered.
 
 
+.. image:: ../transaction-common-states.svg
+  :width: 800
+
+Red label means end state, where it is safe to delete the transaction record 
since no work is due.
+Blue label means that the transaction will not change the state unless is 
resumed. Safe to cache.
+
 Transaction Type: Withdrawal
 ----------------------------
 
@@ -124,7 +133,7 @@ the longest available withdraw durations). So in 99.9% of 
all cases, this will j
 as a sane exchange will have a reasonable duration overlap, and in the 0.1% of 
cases it's
 really the user's fault for going offline in the middle of the operation. 
Plus, even in those
 0.1% of cases, it is highly unlikely that the fee would actually change: again 
99% of key
-roatations can be expected to be there to rotate the key, and not to adjust 
the withdraw fee.
+rotations can be expected to be there to rotate the key, and not to adjust the 
withdraw fee.
 And in the 1:1M case that the fee does *increase*, it's again unlikely to 
matter much to the
 user. So special-casing this and testing this is IMO just not worth it.
 
diff --git a/transaction-common-states.svg b/transaction-common-states.svg
new file mode 100644
index 0000000..bc510a3
--- /dev/null
+++ b/transaction-common-states.svg
@@ -0,0 +1,16 @@
+<svg version="1.1" xmlns="http://www.w3.org/2000/svg"; viewBox="0 0 420.75 
443.25" width="420.75" height="443.25">
+  <!-- svg-source:excalidraw -->
+  
+  <defs>
+    <style>
+      @font-face {
+        font-family: "Virgil";
+        src: url("https://excalidraw.com/Virgil.woff2";);
+      }
+      @font-face {
+        font-family: "Cascadia";
+        src: url("https://excalidraw.com/Cascadia.woff2";);
+      }
+    </style>
+  </defs>
+  <rect x="0" y="0" width="420.75" height="443.25" fill="#ffffff"></rect><g 
stroke-linecap="round" transform="translate(10 257.75) rotate(0 8.75 
8.75)"><path d="M17.5 8.75 C17.5 9.26, 17.46 9.77, 17.37 10.27 C17.28 10.77, 
17.15 11.27, 16.97 11.74 C16.8 12.22, 16.58 12.69, 16.33 13.13 C16.07 13.56, 
15.78 13.99, 15.45 14.37 C15.13 14.76, 14.76 15.13, 14.37 15.45 C13.99 15.78, 
13.56 16.07, 13.13 16.33 C12.69 16.58, 12.22 16.8, 11.74 16.97 C11.27 17.15, 
10.77 17.28, 10.27 17.37 C9.77 17.46,  [...]
\ No newline at end of file

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]