commit 1db1852238f408684ace0ba94a22e9b819f909de parent ee1e172c77c40b15e2cb77011d1a8daefe860ea9 Author: Florian Dold <dold@taler.net> Date: Fri, 21 Aug 2026 09:25:31 +0200 fix various syntax issues, remove stale docs Diffstat:
50 files changed, 219 insertions(+), 459 deletions(-)
diff --git a/_exts/httpdomain/__init__.py b/_exts/httpdomain/__init__.py @@ -10,5 +10,7 @@ :license: BSD, see LICENSE for details. """ -__import__('pkg_resources').declare_namespace(__name__) +from pkgutil import extend_path + +__path__ = extend_path(__path__, __name__) diff --git a/checklists/checklist-demo-upgrade.rst b/checklists/checklist-demo-upgrade.rst @@ -1,8 +1,8 @@ +:orphan: + GNU Taler Demo Upgrade Checklist ================================ -.. toctree:: - Domains ------- diff --git a/checklists/checklist-gls.rst b/checklists/checklist-gls.rst @@ -1,8 +0,0 @@ -GLS GNU Taler Integration Checklist -=================================== - -.. toctree:: - -.. include:: frags/checklist-wallet.rst - -.. include:: frags/checklist-common.rst -\ No newline at end of file diff --git a/checklists/qa-0.10.rst b/checklists/qa-0.10.rst @@ -1,233 +0,0 @@ -Taler 0.9.4 QA Plan -------------------- - -Wallet Platforms -^^^^^^^^^^^^^^^^ - -Platforms listed here are the officially supported platforms for this release. - -* Overview / Installation Page - - * https://taler.net/en/wallet.html - -* Android - - * Google Play: https://play.google.com/store/apps/details?id=net.taler.wallet - * F-Droid: https://f-droid.org/en/packages/net.taler.wallet.fdroid/ - * APK Download: TBD - -* Browser - - * Chrome: https://chromewebstore.google.com/detail/gnu-taler-wallet/millncjiddlpgdmkklmhfadpacifaonc - * Firefox: https://addons.mozilla.org/en-US/firefox/addon/taler-wallet/ - -* iOS - - -Running Deployments -^^^^^^^^^^^^^^^^^^^ - -These deployments are maintained by us and should work for the release: - -* Sandcastle-based: - - * demo.taler.net - - * test.taler.net - -* Regio-based: - - * regio-taler.fdold.eu - - -Wallet Flows -^^^^^^^^^^^^ - -* Bank-integrated withdrawal - - * webext: "Continue with Mobile Wallet" flow - -* Manual withdrawal - - * ``taler://withdraw-exchange`` flow - - * Currency conversion withdrawal - -* Peer push payments ("Send Money") - -* Peer pull payments ("Receive Money") - -* Deposit into bank account - - * Check that deposit arrived - -* Payment at merchant - - * on blog merchant - * on survey - * directly initiated via merchant SPA - * webext: "Pay with Mobile Wallet" flow - -* Pay templates - - * Payment TOTP codes - -* Exchange management - - * Reloading exchange keys - * Deleting an exchange - -* Offline handling - - * Check error messages for other flows when internet connectivity - is bad or device is completely offline. - - -libeufin-bank Flows -^^^^^^^^^^^^^^^^^^^ - -* Admin functionality - - * Login - - * Credential change - - * Conversion settings - - * Bank account creation - - * Test transfers - -* Normal account functionality - - * Transfers - - * Transfer to the exchange should bounce - - * Withdrawals - - * (conversion-only): Test cash-in - - * (conversion-only): Test cash-out - - * Lower cash-out limit enforced - - * 2FA for withdrawals, cash-out - - -Merchant Backend SPA Flows -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Instance creation - -* Simple bank account setup - -* Order creation - - * Pay order (with short wire transfer deadline) - - * Check that money from order arrive at the bank with the right subject - -* Extended bank account setup - - * Add Taler Bank Revenue API - - * Check bank transfer list (for wire transfer of previously paid+wired order) - - * Check order payment status goes to "final" automatically - -* TOTP Device Management - - * Add device - - * Edit device (set new secret, export new secret as QR code) - - * Delete device - -* Templates - - * Add template - - * Edit template - - * Add TOTP device to template - - * Edit TOTP device associated with template - - * Pay template - - * Check TOTP code matches - - * Remove TOTP device from template - - * Delete template - - - -Regio Deployment -^^^^^^^^^^^^^^^^ - -* Deployment Automation (deployment.git/regional-currency) - - * Test with Debian bookworm - - * Test with Ubuntu mantic - - * Check logs for errors - - * Test with telesign (SMS) - - * Set up EBICS integration - - * Check that ToS is configured - -* Deployment Functionality - - * All flows of the wallet should work (see ``Wallet Flows`` above) - - * All flows of libeufin-bank should work (see ``libeufin-bank Flows`` above) - - * Merchant backend should work (see ``Merchant Backend SPA Flows`` above) - - * Check logs - - -Android Merchant PoS -^^^^^^^^^^^^^^^^^^^^ - -* Test against demo.taler.net - - -Android Cashier App -^^^^^^^^^^^^^^^^^^^ - -* Test against demo.taler.net - - -CI -^^ - -* https://buildbot.taler.net/#/waterfall -* CI should pass - - -Debian Repository -^^^^^^^^^^^^^^^^^ - -* Debian - - * repo at https://deb.taler.net/apt/debian/ - * supported codename(s): bookworm - - -* Ubuntu: - - * repo at https://deb.taler.net/apt/ubuntu/ - * supported codename(s): mantic - - -GNU Release -^^^^^^^^^^^ - -* Release announcement -* FTP upload diff --git a/checklists/qa-1.0.rst b/checklists/qa-1.0.rst @@ -53,7 +53,7 @@ These deployments should work for the release: Check UX Flows ^^^^^^^^^^^^^^ -See the :doc:`demo upgrade checklist <checklist-demo-upgrade>`. +See the :doc:`demo upgrade checklist </checklists/checklist-demo-upgrade>`. Regio Deployment diff --git a/core/api-adapter.rst b/core/api-adapter.rst @@ -33,16 +33,16 @@ Endpoints for Integrated Sub-APIs The endpoints are only available if the adapter is configured to serve the Taler Wire Gateway API. .. http:any:: /taler-prepared-transfer/* - + All endpoints under this prefix are specified by the :doc:`GNU Taler prepared transfer API </core/api-bank-transfer>`. The endpoints are only available if the adapter is configured to serve the Taler Wire Gateway API. - + .. http:any:: /taler-revenue/* All endpoints under this prefix are specified by the :doc:`GNU Taler Revenue API </core/api-bank-revenue>`. - The endpoints are only available if the adapter is configured to serve the Taler Revenue API. -\ No newline at end of file + The endpoints are only available if the adapter is configured to serve the Taler Revenue API. diff --git a/core/api-apns.rst b/core/api-apns.rst @@ -105,4 +105,4 @@ Device Registration **Response:** :http:statuscode:`204 No Content`: - The device have been unregistered. -\ No newline at end of file + The device have been unregistered. diff --git a/core/api-auditor.rst b/core/api-auditor.rst @@ -387,6 +387,19 @@ balance, as that balance would be credited to the original account. .. include:: auditor/patch-monitoring-misattribution-in-inconsistency-SERIAL_ID.rst +.. _kycauth-in-inconsistency-list: + +KYCAUTH In Inconsistencies +-------------------------- + +This section lists cases where the exchange and the bank disagree about a +transfer that established a KYC authentication account. + +.. include:: auditor/get-monitoring-kycauth-in-inconsistency.rst + +.. include:: auditor/patch-monitoring-kycauth-in-inconsistency-SERIAL_ID.rst + + .. _deposit-confirmations-list: @@ -692,18 +705,3 @@ Progress This section contains information about the auditing progress an auditor has made. .. include:: auditor/get-monitoring-progress.rst - ----------- -Complaints ----------- - -This endpoint is used by the wallet or merchants to submit proof of -misbehavior of an exchange to the auditor. - -.. note:: - - To be designed and implemented. - -.. include:: auditor/put-complain.rst - -Complain about misbehavior to the auditor. diff --git a/core/api-challenger.rst b/core/api-challenger.rst @@ -97,7 +97,7 @@ The current protocol version is **v8**. * ``v6``: add the ``address_type`` field to :http:get:`/config </config>` * ``v7``: adds ``build_version`` to :http:get:`/config </config>` -* ``v8``: HTTP status code and error code corrections. +* ``v8``: HTTP status code and error code corrections. **Upcoming versions:** diff --git a/core/api-common.rst b/core/api-common.rst @@ -1024,7 +1024,7 @@ we use the `StatisticBucketRange` when rounding time to values that cannot be expressed as fixed multiples of seconds: - .. ts:def:: StatisticBucketRange +.. ts:def:: StatisticBucketRange type MerchantStatisticCounterByBucket = "decade" | "year" | "quarter" | "month" | "week" | "day" | "hour" | "minute" | "second"; @@ -1386,7 +1386,7 @@ within the * public key. */ struct TALER_HashPlanchetsP { - struct GNUNET_HashCode hash; + struct GNUNET_HashCode hash; }; @@ -2508,4 +2508,4 @@ within the */ struct GNUNET_CRYPTO_SignaturePurpose purpose; struct GNUNET_TIME_TimestampNBO timestamp; - }; -\ No newline at end of file + }; diff --git a/core/auditor/put-complain.rst b/core/auditor/put-complain.rst @@ -1 +0,0 @@ -.. http:put:: /complain diff --git a/core/bank-transfer/get-config.rst b/core/bank-transfer/get-config.rst @@ -6,7 +6,7 @@ **Response:** :http:statuscode:`200 OK`: - The adapter responds with a `PreparedTransferConfig` object. This request + The adapter responds with a `PreparedTransferConfig` object. This request should virtually always be successful. **Details:** diff --git a/core/bank-wire/get-history-outgoing.rst b/core/bank-wire/get-history-outgoing.rst @@ -70,7 +70,7 @@ // Base URL of the exchange. exchange_base_url: WebURL; - + // Optional additional metadata. // @since **v5** metadata?: string; diff --git a/core/bank-wire/post-transfer.rst b/core/bank-wire/post-transfer.rst @@ -26,7 +26,7 @@ // Base URL of the exchange. Shall be included by the bank gateway // in the appropriate section of the wire transfer details. exchange_base_url: WebURL; - + // Optional additional metadata to be stored in the transaction. // Must match [a-zA-Z0-9-.:]{1, 40} // @since **v5** diff --git a/core/corebank/post-accounts-USERNAME-cashouts.rst b/core/corebank/post-accounts-USERNAME-cashouts.rst @@ -8,7 +8,7 @@ .. note:: - Consult the `cashout rates call <cashout-rates>`_ to learn + Consult the :ref:`cashout rates call <cashout-rates>` to learn about any applicable fee or exchange rate. diff --git a/core/ebisync/get-config.rst b/core/ebisync/get-config.rst @@ -20,7 +20,7 @@ // https://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning // The format is "current:revision:age". version: string; - + // URN of the implementation (needed to interpret 'revision' in version). implementation: string; diff --git a/core/exchange/delete-purses-PURSE_PUB.rst b/core/exchange/delete-purses-PURSE_PUB.rst @@ -10,7 +10,7 @@ To authorize the request, the following HTTP headers must be provided: *Taler-Purse-Signature*: - $PURSE_SIG`` where ``$PURSE_SIG`` is the Crockford base32-encoded EdDSA + ``$PURSE_SIG`` where ``$PURSE_SIG`` is the Crockford base32-encoded EdDSA signature of purpose TALER_SIGNATURE_WALLET_PURSE_DELETE. **Response:** diff --git a/core/exchange/post-kyc-bulk-EXTERN_PUB.rst b/core/exchange/post-kyc-bulk-EXTERN_PUB.rst @@ -31,7 +31,7 @@ The following HTTP headers must be provided: *Taler-Extern-Signature*: - $EXTERN_SIG`` where ``$EXTERN_SIG`` is the Crockford base32-encoded EdDSA + ``$EXTERN_SIG`` where ``$EXTERN_SIG`` is the Crockford base32-encoded EdDSA signature of purpose ``TALER_SIGNATURE_EXTERN_BULK_UPLOAD`` and be made over the purpose header and the SHA512 hash over the body and the SHA512 hash of the payto URI. diff --git a/core/exchange/post-purses-PURSE_PUB-deposit.rst b/core/exchange/post-purses-PURSE_PUB-deposit.rst @@ -54,7 +54,7 @@ **Details:** - .. ts:def:: PurseDeposits + .. ts:def:: PurseDeposits interface PurseDeposits { diff --git a/design-documents/023-taler-kyc.rst b/design-documents/023-taler-kyc.rst @@ -1506,11 +1506,11 @@ done. If the KYC is unfinished, the merchant SPA should use long-polling on the KYC status on this page to ensure it is always up-to-date, and change to ``KYC satisfied`` should the long-poller return with positive news. - ..note:: +.. note:: - Semi-related: The TMH_setup_wire_account() is changed to use - 128-bit salt values (to keep ``deposits`` table small) and checks for salt - to be well-formed should be added "everywhere". + Semi-related: The TMH_setup_wire_account() is changed to use + 128-bit salt values (to keep ``deposits`` table small) and checks for salt + to be well-formed should be added "everywhere". diff --git a/design-documents/028-deposit-policies.rst b/design-documents/028-deposit-policies.rst @@ -46,7 +46,7 @@ Brandt-Vickrey auctions refreshed. The policies shall be implemented as *extensions* to the exchange (see -:doc:`006-extensions`). +:doc:`006-extensions`). Motivation ********** @@ -164,7 +164,7 @@ Success Timeout The policy has timed out. The amounts for payout and refresh are transfered/can be claimed. - + Failure The policy is in an failure state. Payouts and refreshes are blocked, timeouts are ignored. @@ -196,7 +196,7 @@ The following invariants need to be fulfilled and be checked by the auditor: ``policy_fulfillment``, the ``policy_details.policy_hash_code`` MUST be present in that entry's ``.policy_hash_codes``. - + Alternatives ============ diff --git a/design-documents/032-brandt-vickrey-auctions.rst b/design-documents/032-brandt-vickrey-auctions.rst @@ -195,9 +195,9 @@ Transcripts ^^^^^^^^^^^ A transcript of a Brandt-Vickrey auction is the JSON encoding of an object of -type `BrandtVickreyAuctionTranscript`. +type ``BrandtVickreyAuctionTranscript``. - .. ts:def:: BrandtVickreyAuctionTranscript + .. code-block:: typescript // This structure defines the transcript of an auction of Brandt-Vickrey kind. interface BrandtVickreyAuctionTranscript { @@ -233,7 +233,7 @@ type `BrandtVickreyAuctionTranscript`. } - .. ts:def:: BrandtVickreyAuctionMessage + .. code-block:: typescript interface BrandtVickreyAuctionMessage { // The index of the bidder into the @@ -251,7 +251,7 @@ type `BrandtVickreyAuctionTranscript`. - .. ts:def:: BrandtVickreyAuctionWinner + .. code-block:: typescript interface BrandtVickreyAuctionWinner { // The index of the bidder into the diff --git a/design-documents/034-wallet-db-migration.rst b/design-documents/034-wallet-db-migration.rst @@ -87,7 +87,7 @@ Alternatives * Per-object versioning instead of using IndexedDB minor versions * Always use the backup mechanism to upgrade the database - + * Would be overkill for minor migrations Drawbacks diff --git a/design-documents/037-wallet-transactions-lifecycle.rst b/design-documents/037-wallet-transactions-lifecycle.rst @@ -187,7 +187,7 @@ Transaction Type: Withdrawal Depending on how a bank-integrated withdrawal transaction is created, it starts either in this state or in ``pending(bank-register-reserve)``. - + * ``pending(bank-register-reserve)`` @@ -370,7 +370,7 @@ Transaction Type: Payment to Merchant Let the user accept (or refuse) the payment. * ``[action:pay-accept] => pending(submit-payment)`` - * ``[action:pay-refuse] => ``aborted(refused)`` -- The user explicitly + * ``[action:pay-refuse] => aborted(refused)`` -- The user explicitly decided not to proceed (at least not with this wallet). * ``[expired] => failed(expired)`` -- The offer has expired before the user made any decision. Note that we should use this transition at diff --git a/design-documents/038-demobanks-protocol-suppliers.rst b/design-documents/038-demobanks-protocol-suppliers.rst @@ -94,7 +94,7 @@ supplier with semi-dynamic demobank. 2. A XML-based protocol that lets user access their bank accounts under the demobank whose name is held both in the supplier state *and* in the URI is **wrong**. This supplier -doesn't respect this `mutual exclusivity <demobank-mutually-exclusive_>`_. +doesn't respect this :ref:`mutual exclusivity <demobank-mutually-exclusive>`. 3. A XML-based protocol that lets user access their bank accounts always under the 'default' demobank belongs to this category. It diff --git a/design-documents/043-managing-prebuilt-artifacts.rst b/design-documents/043-managing-prebuilt-artifacts.rst @@ -12,7 +12,7 @@ DD 43: Managing Prebuilt Artifacts and Source-Level Dependencies .. note:: History: - + * 2025-11-26: Updated to reflect current state and future plans Summary @@ -41,7 +41,7 @@ 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 +* The ``gana.git`` repository Requirements ============ diff --git a/design-documents/045-kyc-inheritance.rst b/design-documents/045-kyc-inheritance.rst @@ -83,21 +83,21 @@ On the exchange we propose the following new endpoint: .. http:post:: /kyc-attest/$TARGET_RESERVE_PUB -**Request:** + **Request:** -The request body must be a `KYCAttestationRequest` object. + The request body must be a `KYCAttestationRequest` object. -**Response:** + **Response:** :http:statuscode:`200 OK`: - Both, the attesting and the target reserves were known to the exchange, and the + Both, the attesting and the target reserves were known to the exchange, and the KYC data of the attesting reserve has been successfully inherited by the target reserve (with optionally adjusted birthday). :http:statuscode:`403 Forbidden`: The attesting reserve is not allowed to transitively attest another reserve. This is because the attesting reserve either - #. lacks KYC attestation or + #. lacks KYC attestation or #. its KYC attestation was itself inherited or @@ -112,9 +112,9 @@ The request body must be a `KYCAttestationRequest` object. point in time (more distant from current time) than the birthday of the attesting reserve. -**Details:** + **Details:** -.. ts:def:: KYCAttestationRequest + .. ts:def:: KYCAttestationRequest interface KYCAttestationRequest { // An optional birthday for the target reserve. MUST be equal or younger @@ -132,16 +132,16 @@ The request body must be a `KYCAttestationRequest` object. } -.. ts:def:: FuzzyDateString + .. ts:def:: FuzzyDateString // A date of the form "YYYY-MM-DD","YYYY-MM-00" or "YYYY-00-00". // "YYYY-MM-00" will be evaluated as "YYYY-MM-01" and // "YYYY-00-00" will be evaluated as "YYYY-01-01". - type FuzzyDateString = string; + type FuzzyDateString = string; -.. _TALER_ReserveKYCAttestationPS: -.. sourcecode:: c + .. _TALER_ReserveKYCAttestationPS: + .. sourcecode:: c struct TALER_ReserveKYCAttestationPS { /** diff --git a/design-documents/052-libeufin-bank-2fa.rst b/design-documents/052-libeufin-bank-2fa.rst @@ -20,13 +20,13 @@ DD 52: LibEufin Bank Two-factor authentification Summary ======= -This document proposes designs for supporting 2-FA for more operations in +This document proposes designs for supporting 2-FA for more operations in libeufin-bank. Motivation ========== -Currently, only cashout operations are protected using 2-FA and we want to also +Currently, only cashout operations are protected using 2-FA and we want to also protects withdrawal, transactions, account reconfiguration and account deletion. Requirements diff --git a/design-documents/064-kyc-operation-algo.rst b/design-documents/064-kyc-operation-algo.rst @@ -50,7 +50,7 @@ Initialize the following variables: request has been made. * ``last_check_code := null`` - + * Taler error code of the last kyc-check request or ``null`` if no such request has been made or the last request didn't return an error code. diff --git a/design-documents/071-auto-refresh.rst b/design-documents/071-auto-refresh.rst @@ -59,10 +59,10 @@ Proposed Solution all coins of that denomination. - ..note:: + .. note:: - This basically suggests that a refresh - would have a significant positive **impact**. + This basically suggests that a refresh + would have a significant positive **impact**. 2. For each denomination, consider if the remaining deposit period is less than **6** months, if the @@ -71,10 +71,10 @@ Proposed Solution and if we are not on battery power. If so, refresh all coins of that denomination. - ..note:: + .. note:: - This is again a significant impact, and it is basically - gratis for the user. + This is again a significant impact, and it is basically + gratis for the user. 3. For each denomination, consider if the remaining deposit period is less than **3** months, and if @@ -87,12 +87,12 @@ Proposed Solution start it at least every **3 months** to avoid the risk of loosing funds to expiration." - ..note:: + .. note:: - This is basically a last-minute effort (unless we have - an exchange with extremely short expiration periods). - We do not like getting into this situation, so it is - time to educate the user. + This is basically a last-minute effort (unless we have + an exchange with extremely short expiration periods). + We do not like getting into this situation, so it is + time to educate the user. 4. Explicitly show a warning in the balances list of the respective currency if the remaining deposit @@ -103,10 +103,10 @@ Proposed Solution 2. "The payment service provider does not offer longer validity periods." - ..note:: + .. note:: - This should prevent us from getting into trouble if - e-cash is lost anyway. + This should prevent us from getting into trouble if + e-cash is lost anyway. Definition of Done diff --git a/design-documents/085-transfer-status.rst b/design-documents/085-transfer-status.rst @@ -32,7 +32,7 @@ Proposed Solution Database -------- -For each transfer we would store a list of all status it whent through. +For each transfer we would store a list of all status it whent through. TODO @@ -83,7 +83,7 @@ Wire Gateway API // Opaque ID of the status change. // It is different from the /transfers row_id: SafeUint64; - + // Opaque ID of the wire transfer initiation performed by the bank. // It is different from the /history endpoints row_id. transfer_id: SafeUint64; diff --git a/design-documents/092-incremental-backup-sync.rst b/design-documents/092-incremental-backup-sync.rst @@ -325,9 +325,9 @@ stored hash. **Response** :http:statuscode:`200 OK`: - The body is a `SyncConfig` object. + The body is a ``SyncConfig`` object. - .. ts:def:: SyncConfig + .. code-block:: typescript interface SyncConfig { name: "sync"; @@ -358,13 +358,13 @@ stored hash. **Response** :http:statuscode:`200 OK`: - The body is a `SyncAccountStatus` object. Returned even when + The body is a ``SyncAccountStatus`` object. Returned even when ``expiration_date`` lies in the past. :http:statuscode:`404 Not found`: The server does not know this account at all. It has never been paid for, so there is no expiry to report. - .. ts:def:: SyncAccountStatus + .. code-block:: typescript interface SyncAccountStatus { // When the account expires, or expired. Every other endpoint @@ -394,7 +394,7 @@ stored hash. **Response** :http:statuscode:`200 OK`: - The body is a JSON array of `BlockEntry` objects. The array is + The body is a JSON array of ``BlockEntry`` objects. The array is empty if the account has no blocks. :http:statuscode:`400 Bad request`: The ``limit`` parameter is missing, malformed, given without a @@ -407,7 +407,7 @@ stored hash. :http:statuscode:`500 Internal server error`: A database error occurred. - .. ts:def:: BlockEntry + .. code-block:: typescript interface BlockEntry { nonce: BlockUuid; @@ -694,7 +694,7 @@ that uploaded it. **Response** :http:statuscode:`200 OK`: - The body is an `ObjectEntry` object. + The body is an ``ObjectEntry`` object. :http:statuscode:`400 Bad request`: The ``$UID`` is malformed. :http:statuscode:`404 Not found`: @@ -703,7 +703,7 @@ that uploaded it. :http:statuscode:`500 Internal server error`: A database error occurred. - .. ts:def:: ObjectEntry + .. code-block:: typescript interface ObjectEntry { uid: BlobUid; @@ -766,7 +766,7 @@ called an “increment set”. Each top-level key in this set holds a list of insertion operations (“increments”) for a particular database entity (e.g. exchanges) or event (e.g. payments). -.. ts:def:: IncrementSet +.. code-block:: typescript interface IncrementSet { addExchangeIncs?: AddExchangeInc[]; @@ -809,7 +809,7 @@ User accepts ToS for a new or existing exchange. Exchanges without an accepted ToS are not included in the backup. -.. ts:def:: AddExchangeInc +.. code-block:: typescript interface AddExchangeInc { type: "add-exchange"; @@ -833,7 +833,7 @@ Set exchange to global trust User sets an exchange to global trust. -.. ts:def:: SetGlobalExchangeTrustInc +.. code-block:: typescript interface SetGlobalExchangeTrustInc { type: "set-global-exchange-trust"; @@ -854,7 +854,7 @@ Add or update a bank account User adds (or updates) a known bank account. -.. ts:def:: AddBankAccountInc +.. code-block:: typescript interface AddBankAccountInc { type: "add-bank-account"; @@ -876,7 +876,7 @@ Set Donau info User sets info for tax-deductible donations. -.. ts:def:: SetDonauInfoInc +.. code-block:: typescript interface SetDonauInfoInc { type: "set-donau-info"; @@ -897,7 +897,7 @@ Add a denomination A denomination is stored in the wallet. -.. ts:def:: AddDenominationInc +.. code-block:: typescript interface AddDenominationInc { type: "add-denomination"; @@ -973,7 +973,7 @@ are the R-values, which nothing can re-derive, so they have to travel in the increment. The field is optional because it was added after the increment was first released: a coin from a wallet that predates it is treated as RSA. -.. ts:def:: AddCoinInc +.. code-block:: typescript interface AddCoinInc { type: "add-coin"; @@ -994,13 +994,13 @@ first released: a coin from a wallet that predates it is treated as RSA. exchangeWithdrawValues?: ExchangeWithdrawValue; } -.. ts:def:: CoinSource +.. code-block:: typescript type CoinSource = | WithdrawalCoinSource | RefreshCoinSource; -.. ts:def:: WithdrawalCoinSource +.. code-block:: typescript interface WithdrawalCoinSource { type: "withdrawal"; @@ -1009,7 +1009,7 @@ first released: a coin from a wallet that predates it is treated as RSA. reservePub: string; } -.. ts:def:: RefreshCoinSource +.. code-block:: typescript interface RefreshCoinSource { type: "refresh"; @@ -1031,7 +1031,7 @@ Spend a coin A signed coin is spent by the user. -.. ts:def:: SpendCoinInc +.. code-block:: typescript interface SpendCoinInc { type: "spend-coin"; @@ -1068,7 +1068,7 @@ instead, so the increments carry the token as it stands, and the token's *use* public key is the primary key of the family. The three increments share one body, ``TokenIncBase``: -.. ts:def:: TokenIncBase +.. code-block:: typescript interface TokenIncBase { // Purchase the token belongs to, and the position within its @@ -1103,7 +1103,7 @@ body, ``TokenIncBase``: blindingKey: string; } -.. ts:def:: AddTokenInc +.. code-block:: typescript interface AddTokenInc extends TokenIncBase { type: "add-token"; @@ -1124,7 +1124,7 @@ A token is signed by the merchant. Applying this increment also removes the slate the token was issued from, the same way the wallet's own issuance flow does. -.. ts:def:: SignTokenInc +.. code-block:: typescript interface SignTokenInc extends TokenIncBase { type: "sign-token"; @@ -1147,7 +1147,7 @@ A signed token is spent by the user. Only the fields the spend changes travel; the increment updates a token that is already there and is skipped when it is not. -.. ts:def:: SpendTokenInc +.. code-block:: typescript interface SpendTokenInc { type: "spend-token"; @@ -1179,7 +1179,7 @@ bank's withdrawal operation. That URI, the reserve key pair and the coin seed withdrawal that was still pending on the other device; the only thing that cannot be resumed is a bank operation the bank has already expired or deleted. -.. ts:def:: WithdrawalStartInc +.. code-block:: typescript interface WithdrawalStartInc { type: "withdrawal-start"; @@ -1206,7 +1206,7 @@ Abort a withdrawal User aborts a withdrawal. -.. ts:def:: WithdrawalAbortInc +.. code-block:: typescript interface WithdrawalAbortInc { type: "withdrawal-abort"; @@ -1227,7 +1227,7 @@ Withdrawal done A withdrawal started by the user completes successfully. -.. ts:def:: WithdrawalDoneInc +.. code-block:: typescript interface WithdrawalDoneInc { type: "withdrawal-done"; @@ -1250,7 +1250,7 @@ Withdrawal failed A withdrawal started by the user fails. -.. ts:def:: WithdrawalFailInc +.. code-block:: typescript interface WithdrawalFailInc { type: "withdrawal-fail"; @@ -1288,7 +1288,7 @@ not grow a seed until they create their next reserve. Reserves created before the seed existed keep their random key pairs and are backed up with the ``reservePriv`` fallback of ``add-reserve`` below. -.. ts:def:: SetReserveSeedInc +.. code-block:: typescript interface SetReserveSeedInc { type: "set-reserve-seed"; @@ -1317,7 +1317,7 @@ The increment carries the record's identity -- the exchange and the reserve's derivation index -- and, for the reserves that predate the seed, the private key. -.. ts:def:: AddReserveInc +.. code-block:: typescript interface AddReserveInc { type: "add-reserve"; @@ -1407,7 +1407,7 @@ done" section for what remains. Start a deposit ~~~~~~~~~~~~~~~ -.. ts:def:: DepositStartInc +.. code-block:: typescript interface DepositStartInc { type: "deposit-start"; @@ -1439,7 +1439,7 @@ Abort a deposit User aborts a deposit. -.. ts:def:: DepositAbortInc +.. code-block:: typescript interface DepositAbortInc { type: "deposit-abort"; @@ -1460,7 +1460,7 @@ Deposit done A deposit started by the user completes successfully. -.. ts:def:: DepositDoneInc +.. code-block:: typescript interface DepositDoneInc { type: "deposit-done"; @@ -1481,7 +1481,7 @@ Deposit fail A deposit started by the user fails. -.. ts:def:: DepositFailInc +.. code-block:: typescript interface DepositFailInc { type: "deposit-fail"; @@ -1502,7 +1502,7 @@ Start a merchant payment User initiates a payment to a merchant. - .. ts:def:: PaymentStartInc +.. code-block:: typescript interface PaymentStartInc { type: "payment-start"; @@ -1546,7 +1546,7 @@ Confirm a merchant payment User confirms a payment to a merchant. -.. ts:def:: PaymentConfirmInc +.. code-block:: typescript interface PaymentConfirmInc { type: "payment-confirm"; @@ -1568,7 +1568,7 @@ Abort a merchant payment User aborts a payment to a merchant. -.. ts:def:: PaymentAbortInc +.. code-block:: typescript interface PaymentAbortInc { type: "payment-abort"; @@ -1589,7 +1589,7 @@ Merchant purchase done A payment started by the user completes successfully. -.. ts:def:: PaymentDoneInc +.. code-block:: typescript interface PaymentDoneInc { type: "payment-done"; @@ -1604,7 +1604,7 @@ Merchant purchase fail A payment started by the user fails. -.. ts:def:: PaymentFailInc +.. code-block:: typescript interface PaymentFailInc { type: "payment-fail"; @@ -1625,7 +1625,7 @@ Start peer-push-credit User receives an incoming push payment. -.. ts:def:: PeerPushCreditStartInc +.. code-block:: typescript interface PeerPushCreditStartInc { type: "peer-push-credit-start"; @@ -1655,7 +1655,7 @@ Abort peer-push-credit User aborts an incoming push payment. -.. ts:def:: PeerPushCreditAbortInc +.. code-block:: typescript interface PeerPushCreditAbortInc { type: "peer-push-credit-abort"; @@ -1676,7 +1676,7 @@ Peer-push-credit done An incoming push payment received by the user completes successfully. -.. ts:def:: PeerPushCreditDoneInc +.. code-block:: typescript interface PeerPushCreditDoneInc { type: "peer-push-credit-done"; @@ -1696,7 +1696,7 @@ Peer-push-credit fail An incoming push payment received by the user fails. -.. ts:def:: PeerPushCreditFailInc +.. code-block:: typescript interface PeerPushCreditFailInc { type: "peer-push-credit-fail"; @@ -1717,7 +1717,7 @@ Start peer-push-debit User initiates an outgoing push payment. -.. ts:def:: PeerPushDebitStartInc +.. code-block:: typescript interface PeerPushDebitStartInc { type: "peer-push-debit-start"; @@ -1750,7 +1750,7 @@ Abort peer-push-debit User aborts an outgoing push payment. -.. ts:def:: PeerPushDebitAbortInc +.. code-block:: typescript interface PeerPushDebitAbortInc { type: "peer-push-debit-abort"; @@ -1771,7 +1771,7 @@ Peer-push-debit done An outgoing push payment initiated by the user completes successfully. -.. ts:def:: PeerPushDebitDoneInc +.. code-block:: typescript interface PeerPushDebitDoneInc { type: "peer-push-debit-done"; @@ -1791,7 +1791,7 @@ Peer-push-debit fail An outgoing push payment initiated by the user fails. -.. ts:def:: PeerPushDebitFailInc +.. code-block:: typescript interface PeerPushDebitFailInc { type: "peer-push-debit-fail"; @@ -1812,7 +1812,7 @@ Start peer-pull-debit User confirms a payment request from another wallet. -.. ts:def:: PeerPullDebitDoneInc +.. code-block:: typescript interface PeerPullDebitDoneInc { type: "peer-pull-debit-start"; @@ -1841,7 +1841,7 @@ Abort peer-pull-debit User aborts a payment to another wallet. -.. ts:def:: PeerPullDebitAbortInc +.. code-block:: typescript interface PeerPullDebitAbortInc { type: "peer-pull-debit-abort"; @@ -1862,7 +1862,7 @@ Peer-pull-debit done A payment to another wallet completes successfully. -.. ts:def:: PeerPullDebitDoneInc +.. code-block:: typescript interface PeerPullDebitDoneInc { type: "peer-pull-debit-done"; @@ -1882,7 +1882,7 @@ Peer-pull-debit fail A payment to another wallet fails. -.. ts:def:: PeerPullDebitFailInc +.. code-block:: typescript interface PeerPullDebitFailInc { type: "peer-pull-debit-fail"; @@ -1903,7 +1903,7 @@ Start peer-pull-credit User requests money to another wallet. -.. ts:def:: PeerPullCreditStartInc +.. code-block:: typescript interface PeerPullCreditStartInc { type: "peer-pull-credit-start"; @@ -1937,7 +1937,7 @@ Abort peer-pull-credit User aborts request to another wallet. -.. ts:def:: PeerPullCreditAbortInc +.. code-block:: typescript interface PeerPullCreditAbortInc { type: "peer-pull-credit-abort"; @@ -1958,7 +1958,7 @@ Peer-pull-credit done A request to another wallet completes successfully (i.e. money is received). -.. ts:def:: PeerPullCreditDoneInc +.. code-block:: typescript interface PeerPullCreditDoneInc { type: "peer-pull-credit-done"; @@ -1978,7 +1978,7 @@ Peer-pull-credit fail A request to another wallet fails. -.. ts:def:: PeerPullCreditFailInc +.. code-block:: typescript interface PeerPullCreditFailInc { type: "peer-pull-credit-fail"; @@ -2007,7 +2007,7 @@ lost the device still collect the change: the exchange holds the first melt commitment, and a wallet that re-melted with a fresh seed could not reveal against it. -.. ts:def:: RefreshStartInc +.. code-block:: typescript interface RefreshStartInc { type: "refresh-start"; @@ -2039,7 +2039,7 @@ is derived from ``sessionPublicSeed`` together with the old coin and the chosen denominations, all of which travel here, so this is the part of a refresh that has to be backed up. -.. ts:def:: RefreshSessionInc +.. code-block:: typescript interface RefreshSessionInc { type: "refresh-session"; @@ -2065,7 +2065,7 @@ Refresh done Every coin of the group has been melted and the fresh coins collected. -.. ts:def:: RefreshDoneInc +.. code-block:: typescript interface RefreshDoneInc { type: "refresh-done"; @@ -2081,7 +2081,7 @@ Refresh failed The refresh could not be completed. -.. ts:def:: RefreshFailInc +.. code-block:: typescript interface RefreshFailInc { type: "refresh-fail"; @@ -2121,7 +2121,7 @@ entirely from the group, and their identity is the merchant's (``coin_pub``/``rtransaction_id``), so a wallet that does query gets the same ones back. -.. ts:def:: RefundInc +.. code-block:: typescript interface RefundInc { type: "refund"; @@ -2135,7 +2135,7 @@ ones back. timestampCreated: TalerPreciseTimestamp; } -.. ts:def:: DerivedOutcome +.. code-block:: typescript // How one of the derived operations ended. A wire string rather than // the wallet's numeric status enum, which is a database detail. @@ -2161,7 +2161,7 @@ progress is not carried -- it describes a run the other wallet did not make -- and a restored recoup is marked finished for every coin, so that the second device does not go and re-submit somebody else's recoup. -.. ts:def:: RecoupInc +.. code-block:: typescript interface RecoupInc { type: "recoup"; @@ -2203,7 +2203,7 @@ end up with the same loss listed twice. denom_loss_event_id = SHA512(exchange_base_url || 0 || event_type || 0 || sorted(denom_pub_hashes) each || 0)[0:32] -.. ts:def:: DenomLossInc +.. code-block:: typescript interface DenomLossInc { type: "denom-loss"; @@ -2505,7 +2505,7 @@ wallet-core API. All requests below are available on every platform. The request handlers described here are implemented; the collection and scheduling mechanisms described above drive them. -.. ts:def:: AddBackupProviderRequest +.. code-block:: typescript interface AddBackupProviderRequest { backupProviderBaseUrl: string; @@ -2541,16 +2541,16 @@ confirms from the wallet, and the ``payment-required`` phase of the notification carries its ``taler://pay/...`` URI. Clients follow all of this through the notifications, not through this request's response: -.. ts:def:: AddBackupProviderResponse +.. code-block:: typescript interface AddBackupProviderResponse { status: "ok"; } -``removeBackupProvider`` takes a `RemoveBackupProviderRequest` naming the +``removeBackupProvider`` takes a ``RemoveBackupProviderRequest`` naming the provider by base URL and returns an empty object. -.. ts:def:: RemoveBackupProviderRequest +.. code-block:: typescript interface RemoveBackupProviderRequest { backupProviderBaseUrl: string; @@ -2560,7 +2560,7 @@ provider by base URL and returns an empty object. known provider, including its terms, payment status and the outcome of the last backup attempt. -.. ts:def:: BackupInfo +.. code-block:: typescript interface BackupInfo { walletRootPub: string; @@ -2570,7 +2570,7 @@ last backup attempt. ``ProviderInfo`` describes one known provider and the state of the wallet's account on it: -.. ts:def:: ProviderInfo +.. code-block:: typescript interface ProviderInfo { active: boolean; @@ -2599,7 +2599,7 @@ account on it: blockCount?: number; } -.. ts:def:: BackupProviderTerms +.. code-block:: typescript interface BackupProviderTerms { supportedProtocolVersion: string; @@ -2610,7 +2610,7 @@ account on it: The provider's ``paymentStatus`` reflects how far the account payment has gotten, based on the payment transaction the wallet opened for it: -.. ts:def:: ProviderPaymentStatus +.. code-block:: typescript type ProviderPaymentStatus = | { type: "unpaid" } @@ -2626,7 +2626,7 @@ gotten, based on the payment transaction the wallet opened for it: another device, along with the providers to fetch the blocks from. It is what the user backs up out of band, and what a restoring wallet is fed. -.. ts:def:: BackupRecovery +.. code-block:: typescript interface BackupRecovery { walletRootPriv: string; @@ -2678,7 +2678,7 @@ The providers are registered but not activated; the client activates one with ``addBackupProvider`` (``activate: true``), and that is what starts the cycle which pulls the backup. -.. ts:def:: RecoveryLoadRequest +.. code-block:: typescript interface RecoveryLoadRequest { recovery: BackupRecovery; @@ -2694,7 +2694,7 @@ reports its progress and outcome through the ``backup-status`` notifications, and persists its statistics for ``getBackupDiagnostics``. Clients track the cycle through those, not through this request's response. -.. ts:def:: RunBackupCycleRequest +.. code-block:: typescript interface RunBackupCycleRequest { // Run the full-collection pass even when its periodic watermark @@ -2710,7 +2710,7 @@ outcome. The ``outcome`` field says how the cycle ended: ``"ok"`` (including idle cycles with nothing to push), ``"payment-required"`` (the account is unpaid) or ``"error"``. -.. ts:def:: BackupCycleStats +.. code-block:: typescript interface BackupCycleStats { timestamp: TalerPreciseTimestamp; @@ -2749,7 +2749,7 @@ It is intended for developer tooling; user interfaces are expected to only expose it in developer mode, but the request itself is harmless and available on every platform. -.. ts:def:: BackupDiagnostics +.. code-block:: typescript interface BackupDiagnostics { // The increments waiting in the eager pending buffer: what a normal @@ -2764,7 +2764,7 @@ on every platform. lastCycle?: BackupCycleStats; } -.. ts:def:: IncrementStatSummary +.. code-block:: typescript interface IncrementStatSummary { incrementCount: number; @@ -2793,7 +2793,7 @@ regular wallet notification listener. Clients should use it instead of polling ``getBackupInfo`` to track a cycle: it reports the phase the cycle is in and, on the terminal phases, the outcome and the relevant counters. -.. ts:def:: BackupStatusNotification +.. code-block:: typescript interface BackupStatusNotification { type: "backup-status"; diff --git a/design-documents/100-shares.rst b/design-documents/100-shares.rst @@ -105,8 +105,6 @@ must be resolved before the API is specified. the merchant backend, but we could keep it there as well (to keep the new frontend "stateless"; in that case, we'd also want to track the p2p-pull requests in the merchant backend) -- - Test Plan ========= diff --git a/developer/taler-developer-manual.rst b/developer/taler-developer-manual.rst @@ -957,6 +957,7 @@ localization files named PO (Portable Object) holding pairs of original and translated strings. .. include:: dictionary.rst + :start-line: 4 iOS localization uses the checked-in ``Localizable.xcstrings`` catalogs as the application source and checked-in ``XLIFF/*.xliff`` files as the Weblate diff --git a/developer/taler-wallet-developer.rst b/developer/taler-wallet-developer.rst @@ -25,6 +25,14 @@ Wallet Developer Manual The GNU Taler wallet allows customers to withdraw and spend digital cash. +Additional implementation notes about request retries, cancellation, and +failure reporting are documented in :doc:`../wallet/wallet-error-handling`. + +.. toctree:: + :hidden: + + ../wallet/wallet-error-handling + WebExtension Wallet =================== diff --git a/index.rst b/index.rst @@ -68,6 +68,7 @@ and overall usage of the different Taler components in text and video formats. taler-merchant-manual taler-merchant-pos-terminal + pos-integration taler-paivana-manual .. toctree:: diff --git a/libeufin/bank-manual.rst b/libeufin/bank-manual.rst @@ -88,7 +88,7 @@ The following snippet shows the mandatory configuration values: # THe public URL that the bank will be served under BASE_URL = https://bank.taler.net - + # Supported payment target type WIRE_TYPE = iban or x-taler-bank # If WIRE_TYPE = iban @@ -158,7 +158,7 @@ To test your setup run: $ TELESIGN_AUTH_TOKEN=$TELESIGN_TOKEN $ echo "Test 1234" | libeufin-tan-sms.sh $PHONE -If you received an SMS containing "Test 1234" you can enable this channel in the config: +If you received an SMS containing "Test 1234" you can enable this channel in the config: .. code-block:: ini @@ -177,7 +177,7 @@ To test your setup run: $ echo "Test 1234" | libeufin-tan-email.sh $EMAIL -If you received an email containing "Test 1234" you can enable this channel in the config: +If you received an email containing "Test 1234" you can enable this channel in the config: .. code-block:: ini @@ -197,9 +197,9 @@ options in the configuration file: [libeufin-bank] TAN_SMS = custom-tan-sms.sh - TAN_SMS_ENV = + TAN_SMS_ENV = TAN_EMAIL = custom-tan-email.sh - TAN_EMAIL_ENV = + TAN_EMAIL_ENV = Launching libeufin-bank ======================= diff --git a/libeufin/nexus-dialects.rst b/libeufin/nexus-dialects.rst @@ -23,10 +23,10 @@ Nexus bank dialects LibEuFin Nexus is an EBICS facilitator. It offers a command line interface to setup EBICS access, download banking records, and submit payments. LibEuFin Nexus is not a generic EBICS client but a Taler specific one. -Today, the LibEuFin implementation supports EBICS 3.0 and has been -tested with Postfinance (CHF), GLS (EUR) and Maerki Baumann (CHF). Please note -that banks tend to have their own dialects of finance messages and thus other -retail banks may or may not work. Contact us if you need support for another +Today, the LibEuFin implementation supports EBICS 3.0 and has been +tested with Postfinance (CHF), GLS (EUR) and Maerki Baumann (CHF). Please note +that banks tend to have their own dialects of finance messages and thus other +retail banks may or may not work. Contact us if you need support for another bank or core banking protocol. EBICS @@ -53,8 +53,8 @@ ISO20022 CAMT files ---------- -In ISO 20022 specifications, most fields are optional and the same information -can be written several times in different places. For LibEuFin, we're only +In ISO 20022 specifications, most fields are optional and the same information +can be written several times in different places. For LibEuFin, we're only interested in a subset of the available values that can be found in both camt. 052, camt.053 and camt.054. We only parse payment transactions (transaction domain code PMNT) and ignore all others. This mean we ignore some debits that could originate from you banks for fees or taxes. diff --git a/libeufin/nexus-manual.rst b/libeufin/nexus-manual.rst @@ -124,7 +124,7 @@ submitted to the database, so this section only discusses how such queued payments will be executed. The responsible subcommand for sending payments is ``ebics-submit``, and its -configuration is a **superset** of `nexus-core-config <nexus-core-config>`_. On top of that, it expects +configuration is a **superset** of ``nexus-core-config``. On top of that, it expects the database connection string and *optionally* a frequency at which it will check for submittable payments in the database. @@ -211,9 +211,9 @@ subscriber accepted the bank keys. Furthermore, the database has to be set up. The responsible subcommand for fetching and registering payments is -``ebics-fetch``, and its configuration is a **superset** of nexus-core-config_. On -top of that, it expects the database connection string and *optionally* a -frequency and a checkpoint time of day. +``ebics-fetch``, and its configuration is a **superset** of +``nexus-core-config``. On top of that, it expects the database connection +string and *optionally* a frequency and a checkpoint time of day. For the best user experience, new transactions should be registered as soon as they are booked. This is especially important for instant transactions, which diff --git a/manpages/frags/common-serve-options.rst b/manpages/frags/common-serve-options.rst @@ -15,4 +15,4 @@ UNIXPATH UNIXPATH_MODE What should be the file access permissions for ``UNIXPATH``? - Only used if ``SERVE`` is ``unix``. -\ No newline at end of file + Only used if ``SERVE`` is ``unix``. diff --git a/manpages/libeufin-bank.1.rst b/manpages/libeufin-bank.1.rst @@ -56,7 +56,7 @@ Its options are as follows: **-c** \| **--config** *config_file* Specifies the configuration file. **-L** \| **--log** *LOGLEVEL* - Configure logging to use LOGLEVEL. + Configure logging to use LOGLEVEL. **-r** \| **--reset** Reset database (DANGEROUS: All existing data is lost) **-h** \| **--help** @@ -128,7 +128,7 @@ Its options are as follows: **-c** \| **--config** *config_file* Specifies the configuration file. **-L** \| **--log** *LOGLEVEL* - Configure logging to use LOGLEVEL. + Configure logging to use LOGLEVEL. **-u** \| **--user** \| **--username** *USERNAME* Account unique username. **-p** \| **--password** *PASSWORD* @@ -166,7 +166,7 @@ Its options are as follows: **-c** \| **--config** *config_file* Specifies the configuration file. **-L** \| **--log** *LOGLEVEL* - Configure logging to use LOGLEVEL. + Configure logging to use LOGLEVEL. **--name** *NAME* Legal name of the account owner. **--public** *true|false* diff --git a/manpages/libeufin-ebisync.conf.5.rst b/manpages/libeufin-ebisync.conf.5.rst @@ -120,7 +120,7 @@ PORT Only used if ``SERVE`` is ``tcp``. BIND_TO - Which IP address should we bind to? E.g. ``127.0.0.1`` or ``::1``for loopback. Can also be given as a hostname. + Which IP address should we bind to? E.g. ``127.0.0.1`` or ``::1`` for loopback. Can also be given as a hostname. Only used if ``SERVE`` is ``tcp``. UNIXPATH @@ -132,7 +132,7 @@ DATABASE OPTIONS Setting the database belongs to the “[ebisyncdb-postgres]” section and the following value. -.. include:: ../frags/common-db-options.rst +.. include:: frags/common-db-options.rst SEE ALSO ======== diff --git a/manpages/taler-apns-relay.1.rst b/manpages/taler-apns-relay.1.rst @@ -43,7 +43,7 @@ The interaction model is as follows: - After a successful setup, the subcommands ``worker`` can be run to send background notifications to all registered device at a regular interval. - Start the HTTP server with command ``serve``. - Let this run in a shell, writing logs to stderr. + Let this run in a shell, writing logs to stderr. The following sections describe each command in detail. @@ -57,7 +57,7 @@ Its options are as follows: **-c** \| **--config** *config_file* Specifies the configuration file. **-L** \| **--log** *LOGLEVEL* - Configure logging to use LOGLEVEL. + Configure logging to use LOGLEVEL. **-r** \| **--reset** Reset database (DANGEROUS: All existing data is lost) **-h** \| **--help** @@ -73,7 +73,7 @@ Its options are as follows: **-c** \| **--config** *config_file* Specifies the configuration file. **-L** \| **--log** *LOGLEVEL* - Configure logging to use LOGLEVEL. + Configure logging to use LOGLEVEL. **-r** \| **--reset** Reset connection info and overwrite keys file **-h** \| **--help** diff --git a/manpages/taler-apns-relay.conf.5.rst b/manpages/taler-apns-relay.conf.5.rst @@ -67,4 +67,4 @@ BUGS ==== Report bugs by using https://bugs.taler.net/ or by sending electronic -mail to <taler@gnu.org>. -\ No newline at end of file +mail to <taler@gnu.org>. diff --git a/orphaned/taler-mcig.rst b/orphaned/taler-mcig.rst @@ -26,7 +26,7 @@ who wishes to set up a "web shop" that works with the Taler payment system. Introduction ============ -.. include:: frags/taler-payment-cycle.rst +.. include:: ../frags/taler-payment-cycle.rst This guide focuses on step 4, the interaction between the customer and the merchant. In particular, we first review two basic interaction flows diff --git a/pos-integration.rst b/pos-integration.rst @@ -42,7 +42,7 @@ Merchant API Basics ------------------- A Taler merchant backend offers an HTTP API. Requests to private endpoints are -`authenticated <merchant-api-authentication>`_ with a bearer token in the +:ref:`authenticated <merchant-api-authentication>` with a bearer token in the ``Authorization: Bearer $TOKEN`` header. Some endpoints offered by the Taler merchant backend are publicly accessible, @@ -74,7 +74,8 @@ onboarding flow with the PoS provider. While more convenient, it comes with more integration effort. This flow requires that the provider of the PoS terminal is operating (or -subcontracting the operation of) a separate `Taler merchant backend <merchant-backend-operator-manual>`_. +subcontracting the operation of) a separate +:ref:`Taler merchant backend <taler-merchant-backend-operator-manual>`. The Taler exchange, the regulated payment service provider, will still be operated separately (i.e. by Taler Operations AG in Switzerland). To simplify the @@ -86,7 +87,7 @@ For the integrated onboarding, the steps for the merchant are: * Merchant onboards with PoS terminal and enables Taler support. * The PoS terminal provider creates a new tenant (=instance) in the Taler merchant backend via the - `POST /management/instances <post-management-instances>`_ endpoint and + :ref:`POST /management/instances <post-management-instances>` endpoint and configures it (i.e. setting up contact info for notifications, bank account info, etc. via the respective endpoints). This is done using administrative credentials on the merchant backend. @@ -129,7 +130,7 @@ into the *paid* state. There are two ways to subscribe to status updates: -* `Webhooks <merchant-webhooks>`_ +* :ref:`Webhooks <merchant-webhooks>` * Long-polling on the :http:get:`[/instances/$INSTANCE]/private/orders/$ORDER_ID` endpoint Refunds diff --git a/system-administration/grafana-loki.rst b/system-administration/grafana-loki.rst @@ -47,7 +47,7 @@ Download Loki # cp loki /usr/local/bin/ Loki configuration file -========================================= +======================= .. code-block:: yaml @@ -205,4 +205,3 @@ Grafana control panel You can now to go the `Grafana control panel <https://grafana.taler.net>`_ and easily add the new Loki data source. - diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst @@ -597,16 +597,16 @@ to be initialized with the following command: [root@exchange-online]# sudo -u taler-exchange-httpd taler-exchange-dbinit - ..note:: +.. note:: - To run this command, the user must have ``CREATE TABLE``, ``CREATE - INDEX``, ``ALTER TABLE`` and (in the future possibly even) ``DROP TABLE`` - permissions. Those permissions are only required for this step (which may - have to be repeated when upgrading a deployment). Afterwards, during - normal operation, permissions to ``CREATE`` or ``ALTER`` tables are not - required by any of the Taler exchange processes and thus should not be - granted. For more information, see - :doc:`manpages/taler-exchange-dbinit.1`. + To run this command, the user must have ``CREATE TABLE``, ``CREATE + INDEX``, ``ALTER TABLE`` and (in the future possibly even) ``DROP TABLE`` + permissions. Those permissions are only required for this step (which may + have to be repeated when upgrading a deployment). Afterwards, during + normal operation, permissions to ``CREATE`` or ``ALTER`` tables are not + required by any of the Taler exchange processes and thus should not be + granted. For more information, see + :doc:`manpages/taler-exchange-dbinit.1`. Finally we need to grant the other accounts limited access: @@ -706,7 +706,7 @@ must be specified in ``/etc/taler-exchange/taler-exchange.conf``. When editing ``/etc/taler-exchange/taler-exchange.conf``, take care to not accidentally remove the ``@inline-matching@`` directive to include the configuration files in ``conf.d``. - .. _Coins-denomination-keys: +.. _Coins-denomination-keys: Coins (denomination keys) ------------------------- @@ -1253,7 +1253,9 @@ The ``enable-account`` step is important and must be used to sign the correct address to wire funds to. Note that for each bank account, additional options **must** be set in the configuration file to tell the exchange how to access the bank account. The offline tool *only* configures the externally -visible portions of the setup. The chapter on `bank account configuration <_exchange-bank-account-configuration>`_ has further details. +visible portions of the setup. The chapter on +:ref:`bank account configuration <exchange-bank-account-configuration>` has +further details. taler-exchange-offline accepts additional options to configure the use of the account. For example, additional options can be used to add currency diff --git a/taler-magnet-bank-manual.rst b/taler-magnet-bank-manual.rst @@ -76,7 +76,7 @@ To install the adapter as a Debian/Ubuntu package with an automated secure setup .. code-block:: console - $ sudo apt install debhelper + $ sudo apt install debhelper $ make deb $ sudo dpkg -i ../taler-magnet-bank*.deb @@ -160,7 +160,7 @@ If the database is run on a different host, please follow the instructions from the PostgreSQL manual for configuring remote access. Assuming the configuration is correct, the following -command initializes (or upgrades) the database schema using: +command initializes (or upgrades) the database schema using: You can then use a script to automate a secure database setup: .. code-block:: console @@ -207,7 +207,7 @@ Update the configuration files: .. code-block:: ini :caption: /etc/taler-magnet-bank/secrets/magnet-bank-httpd.secret.conf - [magnet-bank-httpd-wire-gateway-api + [magnet-bank-httpd-wire-gateway-api] AUTH_METHOD = bearer TOKEN = $SECRET_TOKEN diff --git a/taler-wise-manual.rst b/taler-wise-manual.rst @@ -28,8 +28,6 @@ taler-wire-gateway API, which is alternatively provided by the :ref:`libeufin-nexus <libeufin-nexus>` (EBICS integration) or the :ref:`Deploymerizer <depolymerization>` (for Bitcoin and Ethereum). -.. image:: images/taler-wise.png - To use the adapter, you must setup an account for the GNU Taler exchange in Wise and configure the adapter with the respective credentials. Furthermore, you must point the GNU Taler exchange to the @@ -230,6 +228,7 @@ The setup process should fail and provide you with the information needed to fil .. code-block:: ini :caption: /etc/taler-wise/conf.d/wise-worker.conf + [wise-balance-eur] ID = 139524631 CURRENCY = EUR @@ -306,4 +305,4 @@ Launching the adapter Use adapter APIS ---------------- -The adapter expose the :ref:`Adapter API <adapter-api>` for each configured balance prefixes by ``/balances/{BALANCE_ID}/``. -\ No newline at end of file +The adapter expose the :ref:`Adapter API <adapter-api>` for each configured balance prefixes by ``/balances/{BALANCE_ID}/``.