taler-docs

Documentation for GNU Taler components, APIs and protocols
Log | Files | Refs | README | LICENSE

commit 07536c458b521c6a6afc25e96eeb9ea001e4747e
parent 0fd1ff58aa3771943164285c1143eebfa3a753d4
Author: Christian Grothoff <christian@grothoff.org>
Date:   Sat,  3 Apr 2021 23:21:33 +0200

fix typo

Diffstat:
Manastasis.rst | 18+++---------------
Mcore/api-merchant.rst | 2+-
2 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/anastasis.rst b/anastasis.rst @@ -1573,7 +1573,6 @@ for presentation to the user: "backup_state": "POLICIES_REVIEWING", "policies": [ { - "recovery_cost": "TESTKUDOS:0", "methods": [ { "authentication_method": 0, @@ -1590,7 +1589,6 @@ for presentation to the user: ] }, { - "recovery_cost": "TESTKUDOS:0", "methods": [ { "authentication_method": 0, @@ -1609,9 +1607,7 @@ for presentation to the user: ] } -For each recovery policy, the state includes the ``recovery_cost`` (which is -the sum of the costs to solve all challenges associated with the policy with -the respective providers), as well as the specific details of which +For each recovery policy, the state includes the specific details of which authentication ``methods`` must be solved to recovery the secret using this policy. The ``methods`` array specifies the index of the ``authentication_method`` in the ``authentication_methods`` array, as well as @@ -1624,9 +1620,8 @@ ERROR state instead of suggesting policies. **add_policy**: Using this transition, the user can add an additional recovery policy to the -state. The argument format is the same that is used in the existing state, -except that the ``recovery_cost`` should be omitted (as the reducer will -calculate it). An example for a possible argument would thus be: +state. The argument format is the same that is used in the existing state. +An example for a possible argument would thus be: .. code-block:: javascript @@ -1654,7 +1649,6 @@ the "policies" array, returning an updated state: "backup_state": "POLICIES_REVIEWING", "policies": [ { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 0, @@ -1667,7 +1661,6 @@ the "policies" array, returning an updated state: ] }, { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 0, @@ -1680,7 +1673,6 @@ the "policies" array, returning an updated state: ] }, { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 1, @@ -1693,7 +1685,6 @@ the "policies" array, returning an updated state: ] }, { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 1, @@ -1734,7 +1725,6 @@ be: "backup_state": "POLICIES_REVIEWING", "policies": [ { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 0, @@ -1747,7 +1737,6 @@ be: ] }, { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 0, @@ -1760,7 +1749,6 @@ be: ] }, { - "recovery_cost": "EUR:0", "methods": [ { "authentication_method": 1, diff --git a/core/api-merchant.rst b/core/api-merchant.rst @@ -1441,7 +1441,7 @@ Reserving inventory Unlocking by using a ``quantity`` of zero is optional but recommended if customers remove products from the shopping cart. Note that actually POSTing to ``/orders`` with set - ``manage_inventory`` and using ``lock_uuid`` will **transition** the + ``inventory_products`` and using ``lock_uuids`` will **transition** the lock to the newly created order (which may have a different ``duration`` and ``quantity`` than what was requested in the lock operation). If an order is for fewer items than originally locked, the difference