[GNUnet-SVN] [taler-merchant-frontend-examples] branch master updated: link to the backoffice documentation

[gnunet]

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

marcello pushed a commit to branch master
in repository merchant-frontend-examples.

The following commit(s) were added to refs/heads/master by this push:
     new b28464f  link to the backoffice documentation
b28464f is described below

commit b28464f41501ea45363592012b35e8b80665b6b1
Author: Marcello Stanisci <address@hidden>
AuthorDate: Tue Jan 16 15:33:36 2018 +0100

    link to the backoffice documentation
---
 php/doc/tutorial.texi    | 144 +---------------------------------------------
 python/doc/tutorial.texi | 147 +----------------------------------------------
 2 files changed, 4 insertions(+), 287 deletions(-)

diff --git a/php/doc/tutorial.texi b/php/doc/tutorial.texi
index bb445cd..f410f26 100644
--- a/php/doc/tutorial.texi
+++ b/php/doc/tutorial.texi
@@ -416,149 +416,9 @@ anything goes wrong, the wallet will handle the 
respective error.
 @node Back-office-integration
 @chapter Integration with the back office
 
-This chapter shows how to implement the back office Web interface.
+Taler ships the back-office feature as a stand-alone Web application.
+See how to run it, on its own documentaion: 
@url{https://docs.taler.net/backoffice/html/manual.html}.
 
-We will use the term @emph{transaction} to refer to the business
-transaction that a merchant has with a customer (and the related
-communication with the Taler exchange for payment), and the term
address@hidden transfer} to refer to the exchange settling its accounts
-with the merchant.
-
-However, from the frontend's perspective, any transaction is denoted
-by the @emph{order id} contained in the proposal that led to the
-transaction.
-
-Given that Taler deals with microtransactions, not every customer
-payment processed with Taler will necessarily correspond to a wire
-transfer.  The Taler exchange may aggregate multiple payments from
-transactions into one larger wire transfer.  The @var{refund_deadline}
-and the @var{pay_deadline} values in the contract specify the
-timeframes within which the exchange is permitted to perform such
-aggregations, see @ref{The Taler proposal format}.
-
-In this chapter, we will see how a merchant can obtain the
-mapping from transactions to wire transfers and vice versa.
-Additionally, we will describe how to obtain a list of all
-transactions known to the backend.
-
address@hidden Entry page
-
-Given this charge, the back office's main tasks are:
-
address@hidden
address@hidden
-Allow the back office operator to specify a order id, and display the
-corresponding wire transfer identifiers.
address@hidden
-Allow the back office operator to specify a wire transfer ID, and
-display all of the corresponding order ids.
address@hidden
-Allow the back office operator to obtain a list of all transactions.
address@hidden itemize
-
-We implement these with a simple HTML form. For simplicity, we have
-one single page for gathering input data for both tracking directions:
-
address@hidden
-// php/backoffice.html
address@hidden ../backoffice.html
address@hidden smallexample
-
-The imported script @code{history.js} is responsible for dynamically
-get the list of known transactions.  See below.
-
address@hidden Tracking a transaction
-
-The @code{track-transaction.php} script is now responsible for taking
-all the URL query parameter and use them on the @code{/track/transaction}
-request to the backend, see 
@url{http://api.taler.net/api-merchant.html#get--track-transaction}.
-The parameters are the @emph{order_id} and the @emph{instance} (see 
@ref{Instances})
-of this merchant.
-Note that the backend may then request this information from the
-exchange, or retrieve it from its own cache if it has already obtained
-it.  The backend will also check signatures from the exchange, persist
-the information obtained, and complain if the exchange ever changes
-its facts in an inconsistent manner.
-
address@hidden
-// php/track-transaction.php
address@hidden ../track-transaction.php
address@hidden smallexample
-
-If the backend returned an HTTP status code @code{202} (Accepted),
-this means that the exchange simply did not yet perform the wire
-transfer. This is usually the case before @var{pay_deadline}, as the
-exchange is waiting for additional opportunities to aggregate transactions.
-In this case, we tell the user when to retry this operation later.
-
-In the @code{foreach} loop, we construct the list of all the
-wire transfers which paid back transaction @emph{order_id}.  For
-simplicity, the list will report only two values: the wire transfer
-identifier and the date when the transfer occurred. Nonetheless,
-the data returned by the backend contains more information that
-can be shown to the user.
-
address@hidden Tracking a wire transfer
-
-To track a wire transfer, the frontend just needs to forward the request
-it got from the Web form, to the backend.
-Again, the backend may request missing information from the exchange,
-verify signatures, persist the result and complain if there are
-inconsistencies.
-
-In the case that the backend detects inconsistencies, an HTTP status
-code of @code{402} is returned.  In this case, we report this
-situation to the user, who should now report this situation to the
-exchange's auditors as the exchange is misbehaving.
-
-In the usual case where everything went fine, we first output the
-amount that was supposed to have been transfered under the given
address@hidden, and when it was performed (according to the exchange).
-Finally, in the @code{foreach} loop, we construct the list of the
-order ids paid by the wire transfer:
-
address@hidden
address@hidden ../track-transfer.php
address@hidden smallexample
-
-
address@hidden History
address@hidden Listing all transactions
-
-In order to track transactions, order ids are needed as input.
-To that purpose, the frontend needs to make a HTTP GET request to
address@hidden/history}, which is offered by the backend.
-
-The returned data lists the transactions from the youngest back to
-the oldest.
-
-The @code{/history} API is actually more rich, as it offers the way
-to skim results based on time or on index, but that goes beyond the
-scope of this tutorial.
-
-Our example frontend implements this feature by orchestrating two
-parts:
-
address@hidden
address@hidden A JavaScript function, imported within @code{backoffice.html},
-      that issues the HTTP GET to @code{/history.php?instance=tutorial}
-      and modifies the current page by adding a table showing the result.
address@hidden The @code{history.php} script, which is in charge of serving the 
request
-      coming from the JavaScript. Its task is to relay that request to the
-      backend, and echo the result back.
address@hidden itemize
-
-See below both parts:
-
address@hidden
-// ../history.js
address@hidden ../history.js
address@hidden smallexample
-
address@hidden
-// ../history.php
address@hidden ../history.php
address@hidden smallexample
 
 @node Advanced topics
 @chapter Advanced topics
diff --git a/python/doc/tutorial.texi b/python/doc/tutorial.texi
index 6cd731c..0ff23ce 100644
--- a/python/doc/tutorial.texi
+++ b/python/doc/tutorial.texi
@@ -471,154 +471,11 @@ bank running at @code{https://bank.test.taler.net/}.  
After that, you
 should be able to point your browser at @code{http://localhost:5000/}
 and make a donation.
 
-
-
-
-
 @node Back-office-integration
 @chapter Integration with the back office
 
-This chapter shows how to implement the back office Web interface.
-
-We will use the term @emph{transaction} to refer to the business
-transaction that a merchant has with a customer (and the related
-communication with the Taler exchange for payment), and the term
address@hidden transfer} to refer to the exchange settling its accounts
-with the merchant.
-
-However, from the frontend's perspective, any transaction is denoted
-by the @emph{order id} contained in the proposal that led to the
-transaction.
-
-Given that Taler deals with microtransactions, not every customer
-payment processed with Taler will necessarily correspond to a wire
-transfer.  The Taler exchange may aggregate multiple payments from
-transactions into one larger wire transfer.  The @var{refund_deadline}
-and the @var{pay_deadline} values in the contract specify the
-timeframes within which the exchange is permitted to perform such
-aggregations, see @ref{The Taler proposal format}.
-
-In this chapter, we will see how a merchant can obtain the
-mapping from transactions to wire transfers and vice versa.
-Additionally, we will describe how to obtain a list of all
-transactions known to the backend.
-
address@hidden Entry page
-
-Given this charge, the back office's main tasks are:
-
address@hidden
address@hidden
-Allow the back office operator to specify a order id, and display the
-corresponding wire transfer identifiers.
address@hidden
-Allow the back office operator to specify a wire transfer ID, and
-display all of the corresponding order ids.
address@hidden
-Allow the back office operator to obtain a list of all transactions.
address@hidden itemize
-
-We implement these with a simple HTML form. For simplicity, we have
-one single page for gathering input data for both tracking directions:
-
address@hidden
-TBD.
address@hidden smallexample
-
-The imported script @code{history.js} is responsible for dynamically
-get the list of known transactions.  See below.
-
address@hidden Tracking a transaction
-
-The TBD is now responsible for taking
-all the URL query parameter and use them on the @code{/track/transaction}
-request to the backend, see 
@url{http://api.taler.net/api-merchant.html#get--track-transaction}.
-The parameters are the @emph{order_id} and the @emph{instance} (see 
@ref{Instances})
-of this merchant.
-Note that the backend may then request this information from the
-exchange, or retrieve it from its own cache if it has already obtained
-it.  The backend will also check signatures from the exchange, persist
-the information obtained, and complain if the exchange ever changes
-its facts in an inconsistent manner.
-
address@hidden
-TBD.
address@hidden smallexample
-
-If the backend returned an HTTP status code @code{202} (Accepted),
-this means that the exchange simply did not yet perform the wire
-transfer. This is usually the case before @var{pay_deadline}, as the
-exchange is waiting for additional opportunities to aggregate transactions.
-In this case, we tell the user when to retry this operation later.
-
-In the @code{foreach} loop, we construct the list of all the
-wire transfers which paid back transaction @emph{order_id}.  For
-simplicity, the list will report only two values: the wire transfer
-identifier and the date when the transfer occurred. Nonetheless,
-the data returned by the backend contains more information that
-can be shown to the user.
-
address@hidden Tracking a wire transfer
-
-To track a wire transfer, the frontend just needs to forward the request
-it got from the Web form, to the backend.
-Again, the backend may request missing information from the exchange,
-verify signatures, persist the result and complain if there are
-inconsistencies.
-
-In the case that the backend detects inconsistencies, an HTTP status
-code of @code{402} is returned.  In this case, we report this
-situation to the user, who should now report this situation to the
-exchange's auditors as the exchange is misbehaving.
-
-In the usual case where everything went fine, we first output the
-amount that was supposed to have been transfered under the given
address@hidden, and when it was performed (according to the exchange).
-Finally, in the @code{foreach} loop, we construct the list of the
-order ids paid by the wire transfer:
-
address@hidden
-TBD.
address@hidden smallexample
-
-
address@hidden History
address@hidden Listing all transactions
-
-In order to track transactions, order ids are needed as input.
-To that purpose, the frontend needs to make a HTTP GET request to
address@hidden/history}, which is offered by the backend.
-
-The returned data lists the transactions from the youngest back to
-the oldest.
-
-The @code{/history} API is actually more rich, as it offers the way
-to skim results based on time or on index, but that goes beyond the
-scope of this tutorial.
-
-Our example frontend implements this feature by orchestrating two
-parts:
-
address@hidden
address@hidden A JavaScript function, imported within @code{backoffice.html},
-      that issues the HTTP GET to TBD
-      and modifies the current page by adding a table showing the result.
address@hidden The TBD, which is in charge of serving the request
-      coming from the JavaScript. Its task is to relay that request to the
-      backend, and echo the result back.
address@hidden itemize
-
-See below both parts:
-
address@hidden
-TBD
address@hidden smallexample
-
address@hidden
-TBD
address@hidden smallexample
-
-
+Taler ships the back-office feature as a stand-alone Web application.
+See how to run it, on its own documentaion: 
@url{https://docs.taler.net/backoffice/html/manual.html}.
 
 @node Advanced topics
 @chapter Advanced topics

-- 
To stop receiving notification emails like this one, please contact
address@hidden