summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2021-08-08 20:33:41 +0200
committerChristian Grothoff <christian@grothoff.org>2021-08-08 20:33:41 +0200
commit7d9643064442d0c7c1c695b69fc56b2322a4213d (patch)
tree5dd1c60c03aef6f4a9bd3169b4338c32c05280cf
parent40ad8425d0359845b4e14a91f83b8c91ed5d1a3d (diff)
downloaddocs-7d9643064442d0c7c1c695b69fc56b2322a4213d.tar.gz
docs-7d9643064442d0c7c1c695b69fc56b2322a4213d.tar.bz2
docs-7d9643064442d0c7c1c695b69fc56b2322a4213d.zip
-fix misc warnings
-rw-r--r--core/api-exchange.rst20
-rw-r--r--core/api-merchant.rst4
-rw-r--r--design-documents/016-backoffice-order-management.rst44
-rw-r--r--design-documents/018-contract-json.rst6
-rw-r--r--taler-auditor-manual.rst4
-rw-r--r--taler-mcig.rst24
-rw-r--r--taler-merchant-manual.rst7
7 files changed, 55 insertions, 54 deletions
diff --git a/core/api-exchange.rst b/core/api-exchange.rst
index e427e42..3d8d8b7 100644
--- a/core/api-exchange.rst
+++ b/core/api-exchange.rst
@@ -991,7 +991,7 @@ This part of the API is for the use by auditors interacting with the exchange.
The auditor signature is invalid.
:http:statuscode:`404 Not found`:
The denomination key for which the auditor is providing a signature is unknown.
- The response will be a `DenominationUnkownMessage`.
+ The response will be a `DenominationUnknownMessage`.
:http:statuscode:`410 Gone`:
This auditor is no longer supported by the exchange.
:http:statuscode:`412 Precondition failed`:
@@ -1389,7 +1389,7 @@ exchange.
The denomination key or the reserve are not known to the exchange. If the
denomination key is unknown, this suggests a bug in the wallet as the
wallet should have used current denomination keys from ``/keys``.
- In this case, the response will be a `DenominationUnkownMessage`.
+ In this case, the response will be a `DenominationUnknownMessage`.
If the reserve is unknown, the wallet should not report a hard error yet, but
instead simply wait for up to a day, as the wire transaction might simply
not yet have completed and might be known to the exchange in the near future.
@@ -1434,7 +1434,7 @@ exchange.
// What kind of operation was requested that now
// failed?
- oper: String;
+ oper: string;
}
@@ -1580,7 +1580,7 @@ denomination.
Either the denomination key is not recognized (expired or invalid),
or the wire type is not recognized.
If the denomination key is unknown, the response will be
- a `DenominationUnkownMessage`.
+ a `DenominationUnknownMessage`.
:http:statuscode:`409 Conflict`:
The deposit operation has either failed because the coin has insufficient
residual value, or because the same public key of the coin has been
@@ -1975,7 +1975,7 @@ denomination.
purse_pub: EddsaPublicKey;
// Signature by the exchange over a
- // `TALER_CoinPurseRefundConfirmationPS`
+ // ``TALER_CoinPurseRefundConfirmationPS``
// of purpose ``TALER_SIGNATURE_EXCHANGE_CONFIRM_PURSE_REFUND``.
exchange_sig: EddsaSignature;
@@ -2022,7 +2022,7 @@ the API during normal operation.
The exchange does not recognize the denomination key as belonging to the exchange,
or it has expired.
If the denomination key is unknown, the response will be
- a `DenominationUnkownMessage`.
+ a `DenominationUnknownMessage`.
:http:statuscode:`409 Conflict`:
The operation is not allowed as the coin has insufficient
residual value, or because the same public key of the coin has been
@@ -2315,14 +2315,14 @@ in using this API.
The denomination key is unknown, or the blinded
coin is not known to have been withdrawn.
If the denomination key is unknown, the response will be
- a `DenominationUnkownMessage`.
+ a `DenominationUnknownMessage`.
:http:statuscode:`409 Conflict`:
The operation is not allowed as the coin has insufficient
residual value, or because the same public key of the coin has been
previously used with a different denomination. Which case it is
can be decided by looking at the error code
(``TALER_EC_EXCHANGE_RECOUP_COIN_BALANCE_ZERO`` or
- ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``).
+ ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``).
The response is a `DepositDoubleSpendError`.
:http:statuscode:`410 Gone`:
The requested denomination key is not yet or no longer valid.
@@ -2490,7 +2490,7 @@ typically also view the balance.)
**Request:**
- :query merchant_sig: EdDSA signature of the merchant made with purpose ``TALER_SIGNATURE_MERCHANT_TRACK_TRANSACTION`` over a `TALER_DepositTrackPS`, affirming that it is really the merchant who requires obtaining the wire transfer identifier.
+ :query merchant_sig: EdDSA signature of the merchant made with purpose ``TALER_SIGNATURE_MERCHANT_TRACK_TRANSACTION`` over a ``TALER_DepositTrackPS``, affirming that it is really the merchant who requires obtaining the wire transfer identifier.
**Response:**
@@ -2773,7 +2773,7 @@ Wallet-to-wallet transfers
previously used with a different denomination. Which case it is
can be decided by looking at the error code
(``TALER_EC_EXCHANGE_DEPOSIT_INSUFFICIENT_FUNDS`` or
- ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``).
+ ``TALER_EC_EXCHANGE_GENERIC_COIN_CONFLICTING_DENOMINATION_KEY``).
The fields of the response are the same in both cases.
The request should not be repeated again with this coin.
In this case, the response is a `PurseDepositDoubleSpendError`.
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index cb59314..ea2ca0b 100644
--- a/core/api-merchant.rst
+++ b/core/api-merchant.rst
@@ -1478,7 +1478,7 @@ Reserving inventory
// UUID that identifies the frontend performing the lock
// Must be unique for the lifetime of the lock.
- lock_uuid: String;
+ lock_uuid: string;
// How long does the frontend intend to hold the lock?
duration: RelativeTime;
@@ -1602,7 +1602,7 @@ Creating orders
// be used in case different UUIDs were used for different
// products (i.e. in case the user started with multiple
// shopping sessions that were combined during checkout).
- lock_uuids: String[];
+ lock_uuids: string[];
// Should a token for claiming the order be generated?
// False can make sense if the ORDER_ID is sufficiently
diff --git a/design-documents/016-backoffice-order-management.rst b/design-documents/016-backoffice-order-management.rst
index 583661c..00250cd 100644
--- a/design-documents/016-backoffice-order-management.rst
+++ b/design-documents/016-backoffice-order-management.rst
@@ -38,7 +38,7 @@ Listing orders
4 tabs will be show for a easy access to common filter, click on any of this and
search will reset all filter except date
-* paid (default)
+* paid (default)
* refunded
* not wired
* all (empty filter box)
@@ -78,7 +78,7 @@ this form is divided into 4 sections
* ``payment``: where some default of the payment processing can be changed
* ``extra``: where the merchant can add extra information in JSON format
-
+
Create order: Product section
.............................
@@ -95,7 +95,7 @@ The first part will add/remove product from the current stock.
The second part will add non inventory product. To add a product a :ref:`create
product <backoffice-create-product>` form will be shown. The product in the list
-can be edited or deleted from the list.
+can be edited or deleted from the list.
In both cases, the total unit and price of the products will be calculated and
shown in the bottom of the section. If the merchant collapse one of the product
@@ -107,7 +107,7 @@ list a line with a resume of the total price and units will be shown.
Create order: Price section
...........................
-This section has 2 scenarios.
+This section has 2 scenarios.
The fist one is without products being added: the ``order price`` and
``summary`` inputs will be shown.
@@ -115,7 +115,7 @@ The fist one is without products being added: the ``order price`` and
If there is at least one product added, the ``total products price`` as the sum
of all products prices will be shown. The ``order price`` will default to
``total products price``. The ``products taxes`` and ``profit`` will be shown
-since ``order price`` cannot be less that ``product taxes``.
+since ``order price`` cannot be less that ``product taxes``.
.. image:: ../backoffice-order-create.price-section.svg
:width: 800
@@ -126,7 +126,7 @@ Create order: Payment section
This section show optional values that can be overwritten by the merchant
* ``refund deadline``: calendar type of input. default from instance
-
+
* ``pay deadline``: calendar type of input. default from instance
* ``auto refund deadline``: calendar type of input. default empty, optional.
@@ -155,12 +155,12 @@ An example of how all section in a page will be shown.
Creation order success
-**********************
+......................
A success message showing the amount, summary and the order id. Additionally the
-taler_pay_uri can be shown to be copied to send to the customer.
+taler_pay_uri can be shown to be copied to send to the customer.
-action buttons that allow the following:
+action buttons that allow the following:
* create another payment: go to the create payment page again
* view details: show details of the payment (see page)
@@ -177,11 +177,11 @@ indicated:
* refunded: red
Header
-^^^^^^
+......
This is a resume of most important information
-* big status with color
+* big status with color
* date
* total
@@ -194,9 +194,9 @@ This is a resume of most important information
* actions: refund (if not refunded), add note, copy order_status_url
Timeline of events
-^^^^^^^^^^^^^^^^^^
+..................
-Event of status changed over time describe vertically.
+Event of status changed over time describe vertically.
Sorted from newest to oldest.
On line per status updated, with datetime and a short description.
@@ -216,7 +216,7 @@ Info taken from:
Error status
-^^^^^^^^^^^^
+............
This section is not going to be shown if there is no error
@@ -227,7 +227,7 @@ This section is not going to be shown if there is no error
and exchange_hc
Payment details
-^^^^^^^^^^^^^^^
+...............
If the order was claimed
@@ -238,9 +238,9 @@ If the order was claimed
* net (deposit_total - refund_amount)
* current status
-
+
Contract Terms
-^^^^^^^^^^^^^^
+..............
collapsed as default. show disabled if unpaid
@@ -271,7 +271,7 @@ collapsed as default. show disabled if unpaid
refund popup
-------------
+............
If there is any refund:
@@ -284,7 +284,7 @@ Warn if there is a pending refund when ``refund_pending`` is true
Ask for:
* amount: default 0, show max amount refundable (order amount - already
- refunded)
+ refunded)
* reason: concatenation of the next values
@@ -320,7 +320,7 @@ Alternatives
pagination
------------
+----------
order list was originally thought with pagination footer
.. image:: ../backoffice-order-list.pagination.svg
@@ -363,11 +363,11 @@ Discussion / Q&A
Is there any other case? Is this taking into account auto_refund?
* Field left out in the order creation:
-
+
* contractTerm.summary_i18n: it makes the UI complex
* contractTerm.order_id: should be created by the backend
* contractTerm.timestamp: defined by backend
* contractTerm.merchant_pub: filled by the backend
* contractTerm.merchant_base_url: filled by the backend
* contractTerm.h_wire: defined by the backend
- * contractTerm.nonce: not used \ No newline at end of file
+ * contractTerm.nonce: not used
diff --git a/design-documents/018-contract-json.rst b/design-documents/018-contract-json.rst
index 2162d6e..d7f7825 100644
--- a/design-documents/018-contract-json.rst
+++ b/design-documents/018-contract-json.rst
@@ -63,7 +63,7 @@ parent object.
.. code-block:: json
{
- "delivery_address": ...,
+ "delivery_address": "...",
"$forgettable": {
"delivery_address": "<salt>"
},
@@ -96,7 +96,7 @@ member of the parent object.
{
...props,
- "delivery_address": ...,
+ "delivery_address": "...",
"$forgettable": {
"delivery_address": "<memb_salt>"
},
@@ -174,7 +174,7 @@ a minimal interoperability test:
Hashing the above contract results in the following Crockford base32 encoded
hash
-``287VXK8T6PXKD05W8Y94QJNEFCMRXBC9S7KNKTWGH2G2J2D7RYKPSHNH1HG9NT1K2HRHGC67W6QM6GEC4BSN1DPNEBCS0AVDT2DBP5G''.
+``287VXK8T6PXKD05W8Y94QJNEFCMRXBC9S7KNKTWGH2G2J2D7RYKPSHNH1HG9NT1K2HRHGC67W6QM6GEC4BSN1DPNEBCS0AVDT2DBP5G``.
Note that typically the salt values must be chosen at random, only for this test we use static salt values.
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index 6a7a302..58dc946 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -332,7 +332,7 @@ The ``helper`` user that is used to download information from the exchange
needs to know details about the exchange. Similarly, the ``offline`` user
needs to check signatures signed with the exchange's offline key. Hence, you
need to obtain the ``MASTER_PUBLIC_KEY`` from the exchange operator (they need
-to run `taler-exchange-offline setup`) and the REST endpoint of the exchange
+to run ``taler-exchange-offline setup``) and the REST endpoint of the exchange
and configure these:
.. code-block:: console
@@ -370,7 +370,7 @@ is to extract the public key:
This public key must then be provided in the configuration file
of the ``auditor`` user in the ``[auditor]]`` configuration section:
-- ``PUBLIC_KEY``: Public key of the auditor, in Base32 encoding.
+- ``PUBLIC_KEY``: Public key of the auditor, in Base32 encoding.
Set from value printed by ``taler-auditor-offline setup``.
You can set this configuration value using:
diff --git a/taler-mcig.rst b/taler-mcig.rst
index e7c89a6..d1247ae 100644
--- a/taler-mcig.rst
+++ b/taler-mcig.rst
@@ -67,20 +67,21 @@ This guide assumes you and the customer agree to use the Taler payment system.
At this point, you generate a *contract* and present it to the customer for
authorization.
The contract includes:
+
- the total amount due;
- a short summary;
- a *fulfillment URI*;
-- the *duration* of the offer
- (how long the customer has to authorize before timeout);
-- (optional) an itemized product list, with
+- the *duration* of the offer (how long the customer has to authorize before timeout);
+- (optional) an itemized product list, with:
+
- (optional) some kind of identification for the selected product(s);
+
- (optional) applicable taxes and fee limits;
- (optional) an order ID (if omitted, the backend will auto-generate one);
- (optional) information which details are *forgettable*;
- (optional) a *claim token* that the customer can use later;
- (optional) information on the *refund deadline*;
-- (optional) information on the the *auto-refund period* (how long does
- the wallet check for refunds without user prompting for it).
+- (optional) information on the the *auto-refund period* (how long does the wallet check for refunds without user prompting for it).
If the customer does nothing (timeout / the contract expires),
the merchant backend automatically *unlocks* the product(s),
@@ -400,12 +401,11 @@ M: :http:post:`/instances/default/private/orders`
}
Notes:
+
- There is no ``refund_delay`` field (no refunds possible).
-- We show the ``create_token`` field with value ``true`` even though
- that is the default (for illustrative purposes).
+- We show the ``create_token`` field with value ``true`` even though that is the default (for illustrative purposes).
- The ``order`` value is actually a ``MinimalOrderDetail`` object.
-- The ``fulfillment_URI`` value includes the product ID and the literal
- string ``${ORDER_ID}``, to be replaced by the backend-generated order ID.
+- The ``fulfillment_URI`` value includes the product ID and the literal string ``${ORDER_ID}``, to be replaced by the backend-generated order ID.
The backend returns ``200 OK`` with the body:
@@ -436,10 +436,10 @@ W: :http:post:`/orders/G93420934823/claim`
}
Notes:
+
- The ``nonce`` value is a randomly-generated string.
- The POST endpoint includes the order ID ``G93420934823``.
-- The ``token`` value is the claim token ``TEUFHEFBQALK``
- received in the ``PostOrderResponse``.
+- The ``token`` value is the claim token ``TEUFHEFBQALK`` received in the ``PostOrderResponse``.
The backend returns ``200 OK`` with body:
@@ -483,6 +483,7 @@ The backend returns ``200 OK`` with body:
}
Notes:
+
- The backend determined both fees to be 0.015 KUDOS.
Because the amortization is 1 (one), both fees (processing and wire
transfer) are included in full.
@@ -535,6 +536,7 @@ W: :http:post:`/orders/G93420934823/pay`
}
Notes:
+
- There is no session ID in the ``PayRequest`` object.
- The total of the contribution is 8.0 + 2.0 = 10.0 KUDOS,
which is enough to cover the purchase price (9.900 KUDOS
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 9a3c94f..5301cc2 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -806,7 +806,7 @@ Setup
------
With the knowledge of the ``payto://``-URI, instances can be configured by POSTing
-a request to :http:post:`/management/instances`. To create a first instance,
+a request to ``/management/instances``. To create a first instance,
create a file ``instance.json`` with an `InstanceConfigurationMessage`
.. code-block:: json
@@ -1241,8 +1241,7 @@ Authorize a tip
When your frontend has reached the point where a client is supposed to receive
a tip, it needs to first authorize the tip. For this, the frontend must use
-the :http:post:`/private/reserves/$RESERVE_PUB/authorize-tip`
-API of the backend. To authorize a
+a POST to ``/private/reserves/$RESERVE_PUB/authorize-tip``. To authorize a
tip, the frontend has to provide the following information in the body of the
POST request:
@@ -1272,7 +1271,7 @@ Picking up of the tip
---------------------
The wallet will POST a JSON object to the shop’s
-:http:post:`/tips/$TIP_ID/pickup` handler.
+``/tips/$TIP_ID/pickup`` handler.
The frontend must then forward this request to the backend. The response
generated by the backend can then be forwarded directly to the wallet.