View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7824 [Taler] merchant backend API (HTTP specification) feature N/A 2023-04-26 00:19 2023-05-28 00:08
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: use more CRUD-like API to edit merchant instance accounts
Description: Currently account edits are folded into the instance PATCH, which results in very messy code.
Would probably be good to have the ability to edit instance accounts with their own operations instead of only with the overall instance.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020206)
Christian Grothoff   
2023-05-28 00:08    		16a14fc..62220c0 adds a POST /private/account and a DELETE /private/account/$H_WIRE endpoint (not yet documented!) to the merchant backend. I think we don't need GET (as that's covered by the GET on the instance) or PATCH (as I'd expect that could be done via DELETE + POST). Sebastian: let me know if you *want* a PATCH or see a reason for a GET or have other feedback on the API. I'll update docs.git "soon", and then start with the C client API fun, too.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7846 [Taler] merchant backend API (HTTP specification) major always 2023-05-22 19:07 2023-05-27 19:53
Reporter: sebasjm Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: after creating a reserve for tipping, the list of account is empty
Description: creation was OK and it returned with account

curl 'https://merchant-backend.taler.ar/instances/default/private/reserves' \
  -H 'Authorization: Bearer secret-token:<something here>' \
  --data-raw '{"initial_balance":"ARS:2","exchange_url":"https://exchange.taler.ar/","wire_method":"iban"}' \

{
  "reserve_pub": "N1DJB6VSDX4M3NR8BVP1BF836EX86VE97HSJ8J4XTB8JM1H3SYAG",
  "accounts": [
    {
      "payto_uri": "payto://iban/SANDBOXX/DE295170?receiver-name=exchange-feb",
      "master_sig": "W7RX1SQE4GC6ATHBF08XEJNWZP2VG7J04AGN263YDPZHSG75AKTK20J4A0FZ6JNCVY6RK8P3CF51WEC63KBREC4QHYJ1S4B723G560G",
      "credit_restrictions": [],
      "debit_restrictions": []
    } ]
}

But then getting the details didn't return accounts


curl 'https://merchant-backend.taler.ar/instances/default/private/reserves/N1DJB6VSDX4M3NR8BVP1BF836EX86VE97HSJ8J4XTB8JM1H3SYAG?tips=yes' \
  -H 'Authorization: Bearer secret-token:<the same secret here unless it was changed>' \

{
  "creation_time": {
    "t_s": 1684775123
  },
  "expiration_time": {
    "t_s": 1716311123
  },
  "merchant_initial_amount": "ARS:2",
  "exchange_initial_amount": "ARS:0",
  "pickup_amount": "ARS:0",
  "committed_amount": "ARS:0",
  "active": true,
  "exchange_url": "https://exchange.taler.ar/",
  "accounts": []
}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020204)
Christian Grothoff   
2023-05-27 19:48    		In "insert_reserve_key", we somehow stored the "reserve_pub" twice in the table, and once instead of "master_pub"...
(0020205)
Christian Grothoff   
2023-05-27 19:53    		db344e1..16a14fc fixes the issue and expands the test suite.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7850 [Taler] wallet-core feature N/A 2023-05-26 15:14 2023-05-26 17:41
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: aborting: "revive" or "resurrect" back to pending
Description: As long as no irrevocable actions within "aborting" happened, it should be possible for the user to "revive" or "resurrect" the dying (aborting) transaction back to "pending".
s.e.
Once the dying (aborting) transaction is finally dead, this is no longer possible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Transaction common states 2 abort is final.png (112,440 bytes) 2023-05-26 15:14
https://bugs.gnunet.org/file_download.php?file_id=1379&type=bug
png

Transaction common states 3 aborting can revive.png (115,411 bytes) 2023-05-26 15:43
https://bugs.gnunet.org/file_download.php?file_id=1381&type=bug
png
Notes
(0020203)
MarcS   
2023-05-26 15:43   

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7703 [Taler] wallet (WebExtension) minor have not tried 2023-02-17 13:35 2023-05-26 12:20
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: store microsecond offset for transaction timestamps in wallet-core
Description: ... Otherwise we can't properly order transactions that occur in the same second.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020202)
Florian Dold   
2023-05-26 12:20    		Fixed in cd8f76d.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7651 [GNUnet] DHT service trivial always 2023-01-30 00:49 2023-05-25 18:51
Reporter: ulfvonbelow Platform:  
Assigned To: schanzen OS:  
Priority: normal OS Version:  
Status: feedback Product Version: Git master  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.19.4  
    Target Version: 0.19.4  
Summary: "Memory leak" in gnunet-dht-get and gnunet-dht-put
Description: The argv created by GNUNET_STRINGS_get_utf8_args is never freed.
Tags: patch
Steps To Reproduce: ./configure --enable-sanitizer
make
make install
make check
Additional Information: Not a real problem, again, but sanitizers...
Patch attached.
Attached Files: 0001-DHT-remove-memory-leak-in-gnunet-dht-get-put.patch (2,234 bytes) 2023-01-30 00:49
https://bugs.gnunet.org/file_download.php?file_id=1351&type=bug
Notes
(0019765)
schanzen   
2023-02-06 06:54    		Actually, reverting this as we cannot free a const pointer here. This may have to be fixed in PROGRAM_run...
(0019766)
schanzen   
2023-02-06 07:05    		ab66a7a9d..eabc1baaf
(0020201)
ulfvonbelow   
2023-05-25 18:51    		eabc1baaf980d8948f3fc0ac83a84446d5f1b226 didn't reintroduce the 'ret = ...' line to replace the 'return ...' line, so it still always returns before the memory is freed. So the sanitizers still fail on this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7849 [Taler] wallet-core minor have not tried 2023-05-25 12:24 2023-05-25 12:24
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: specify exchange state transitions in wallet-core
Description: Similarly to how we spec state transitions for transactions in wallet-core, we should do the same for exchanges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7803 [Taler] taler-harness minor have not tried 2023-04-13 15:35 2023-05-25 12:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: generate list of sample transactions that UIs can use to test their parsers
Description: This list can't be exhaustive, but it'll still help catch problems, both in the wallet-core codebase as well as in the UI.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020200)
Florian Dold   
2023-05-25 12:19    		This is now implemented (a4112bae9) with the testingGetSampleTransactions call.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7327 [Taler] wallet-core feature have not tried 2022-09-06 18:58 2023-05-25 12:00
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet-core responses should include the transaction ID of transaction it creates
Description: This is useful for the UI to direct the user to the transaction details.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020199)
Florian Dold   
2023-05-25 12:00    		Implemented as of wallet-core.git 0b4d900088d

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7336 [Taler] wallet (WebExtension) tweak always 2022-09-08 20:24 2023-05-25 09:56
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: ToS language "wrong"
Description: During the UX study, a user complained that the ToS were in English.
One issue is that we may not have them translated yet, but even if they were, we use the platform language, which the user may or may not have set properly. So giving the user an easy way to change to other *available* ToS languages would be nice.
Tags:
Steps To Reproduce:
Additional Information: This will require some protocol extension to tell the wallet in which other languages the ToS are available.
System Description
Attached Files:
Notes
(0019405)
Christian Grothoff   
2022-11-13 10:42    		2650fea..44f5e5c (docs.git) documents the new "Acceptable-Languages" HTTP header returned by the exchange (and other /terms and /pp handlers) which now specifies the list of alternative languages in which the ToS/PP are available. UIs should make use of this information to allow users to switch to another language.

Note that when downloading the ToS/PP in an alternative language, the client MUST NOT set the ETag header after varying the Accept-Language (or Accept-Encoding) header, otherwise the service will just return a "304 Not Modified".
(0019406)
Christian Grothoff   
2022-11-13 11:25    		IMO wallet-core should now add support to expose the list of supported languages to the UIs, and then we can add a ToS/PP language switcher to UIs. Not urgent, of course.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7848 [Taler] wallet-core minor have not tried 2023-05-23 18:25 2023-05-23 18:25
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core should return maximum expiration time for purse based on available points
Description: That allows the UIs to disable later expiration times.

Otherwise, purses might expire *before* coins expire.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7847 [Taler] wallet-core major unable to reproduce 2023-05-23 17:24 2023-05-23 17:24
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: DoS when all wallet try to refresh coins at the same time
Description: Instead of wallet doing refresh exactly 3 months before expiration time, it should refresh based on a random value close to 3 months


From email

> The refresh transaction is automatically triggered by the wallet software 3 months before the end of the validity of a coin. Especially if Exchange
> operators charge refresh fees, the fact that a fee may automatically be charged in the background without user interaction is likely particularly
> difficult to explain.

> But that also means that "3 months before the end of the validity of a coin" will be the same for every wallet since the beginning,
> isn't this a self-DOS waiting for us?
> I mean, all the wallet with all those coins will try to refresh at the same time.
> Maybe refresh time should random time based in a normal distribution with mean expiration_time - 2 month and std_dev 1 month
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7681 [Taler] sandcastle (containerized demo deployment) feature have not tried 2023-02-12 20:46 2023-05-21 21:42
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: demo doesn't have any KYC checks
Description: The demo should support those to demonstrate KYC.

Maybe with a second exchange?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020198)
Christian Grothoff   
2023-05-21 21:42    		Marc has been asking for a 2nd KUDOS exchange with different fees. Sounds like a good target for this.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7440 [Taler] wallet (WebExtension) feature N/A 2022-11-06 22:55 2023-05-20 17:12
Reporter: Christian Grothoff Platform: i7  
Assigned To: MarcS OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: feedback Product Version: 0.9  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.9.1  
    Target Version: 0.9.1  
Summary: cannot specify expiration for push payments in WebExtension
Description: When sending money to another wallet, it must be possible for the user to specify an expiration time for the push payment, as only then the coins that were pushed can be recovered if the receiver didn't accept the payment.

Similarly, we should also allow setting an expiration date when invoicing (technically a separate issue, but very symmetric so should be done at the same time).

This is also missing in the other wallets.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019391)
sebasjm   
2022-11-08 03:30    		first, it should be implemented by wallet-core :)

* parse the PeerContractTerms
* use amount from CT (instead of the request)
* use expiration from the CT (instead of hardcoded)
* both push and pull request

cc @grote @marc
(0019392)
grote   
2022-11-08 15:00    		can you please get me an API diff together with the wallet-core version this first lands in, once done, please?
additional info on how the current API flow must be adapted will be appreciated.
(0019397)
sebasjm   
2022-11-08 16:34    		@grote yes, AFAIK this is covered by the documentation generation that @florian mentioned

FTR this will also apply to pull payments
(0019398)
sebasjm   
2022-11-10 14:13    		at 5c742afb
(0020197)
MarcS   
2023-05-20 17:12    		re-opened for iOS

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7699 [Taler] wallet-core minor have not tried 2023-02-16 18:57 2023-05-18 21:24
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wallet should support different types of instructed amounts (before and after fees)
Description: Depending on the context, the user wants the instructed amount to be the *effective* instructive amount or the *raw* instructed amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6800 [Taler] wallet-core feature have not tried 2021-03-10 19:06 2023-05-18 21:21
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet should support link protocol (for double spend error recovery after restore from backup)
Description: The wallet should run the link protocol if it gets a double spend error that indicates the coin has been melted, and the new coin isn't known to the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7433 [Taler] wallet-core feature N/A 2022-11-04 16:20 2023-05-18 21:19
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: wallet does not support invoicing with non-zero purse fees
Description: It is currently unable to pay for the purse creation with its coins, even if it has coins.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7845 [Taler] libeufin-sandbox minor have not tried 2023-05-17 20:40 2023-05-17 20:40
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: "libeufin-sandbox config" command should allow changing individual settings ...
Description: ... without having to specify the value of *all* other configuration settings.

The way the tool does it right now makes it very difficult to use.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7844 [Taler] libeufin-sandbox minor have not tried 2023-05-17 20:11 2023-05-17 20:11
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: libeufin-sandbox tool should allow creating accounts
Description: Even if registering new accounts is disabled via the Web interface, there should still be a way to create new accounts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7841 [Taler] merchant backend API (HTTP specification) feature N/A 2023-05-10 17:53 2023-05-13 22:18
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: merchant should require wallet to accept or reject refund
Description: in current protocol refunds are unilateral decisions, when the merchant create a refund this is assume that is good for the wallet since is more money for the pocket.
the merchant is assume to behave in a good way but there are situations that this can be exploited

consider the scenario of selling ticket of concerts:

over sell
---
1.- merchant has 100 seats to sells
2.- merchant sells 110 seats
3.- choose 10 seats based on some factors to refund

speculative price
--
1.- merchant has 100 seats to sells
2.- merchant sells 100 seats at price X
3.- sold in 2 days, still 2 month for the performance
4.- refund 20%, double the price and sell again

in all cases
1.- wallet will automatically pickup refunds
2.- wallet user can't complain since refund was accepted and money is in their pockets

more importantly:

A. if the refund does cancel the contract: wallet doesn't have a warrant that after the purchase the merchant is not going to unilateral cancel the contract
B. if the refund doesn't cancel the contract: merchant can't have a way to deny the entrance (or the service in the contact terms) after a refund.

we want to make this work without reducing the refundable duration since in the example of a ticket for a concert, the refundable duration should be between the purchase and the performance.

proposal:
---

https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-orders-$ORDER_ID-refund

interface WalletRefundRequest {
  // Hash of the order's contract terms (this is used to authenticate the
  // wallet/customer).
  h_contract: HashCode;
 
  // accepted -> actual case
  // denied -> return the amount to the merchant, as nothing happened
  decision: "accepted" | "denied"
}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020195)
Christian Grothoff   
2023-05-13 20:36    		I think your report here is filed under a false legal premise. By merely (especially automatically) accepting a refund, a customer does not inherently forfeit their rights to the contract. So the customer could still go after the merchant for not fulfilling their original agreement. And in your scenario where the merchant behaved in bad faith, I'm pretty sure they'd loose in court. On the other hand, if the merchant could not be expected to uphold their end (say concert was cancelled due to sickness or natural disasters), then the merchant would be in their rights to unilaterally break the contract like this. But, again, this is something for the courts. So before implementing anything here, we definitively need to talk to an actual contract lawyer....

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7837 [Taler] exchange API (HTTP specification) feature N/A 2023-05-08 13:22 2023-05-13 22:18
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: add option to disable tipping
Description: /config and/or /keys should signal when an exchange does not allow tipping.
Merchant backends should then respect that choice.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020194)
Christian Grothoff   
2023-05-13 20:32    		Implemented in exchange.git, merchant still needs to be taught to respect the new option.
(0020196)
Christian Grothoff   
2023-05-13 22:18    		86dc054..f79387a implements this in the merchant.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7835 [Taler] challenger feature N/A 2023-05-07 01:47 2023-05-13 17:07
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: 0.9.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: exchange does not support challenger service yet
Description: Primarily, the initial authorized setup step is not supported by our existing OAuth 2.0 plugin.

Plus, we should probably test the integration ;-).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020193)
Christian Grothoff   
2023-05-13 17:07    		ff1a2831..c9ed524b adds support for /setup. Still needs testing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6564 [Taler] wallet-core feature have not tried 2020-09-03 19:30 2023-05-11 14:51
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core API and UX design for auditor/exchange management needed
Description: We had some partially working, totally unusable implementation of this in an ancient version of the web extension.

Now that the requirements are more clear, we should properly re-design this based on the desired user experience, and then implement an API for it in wallet-core.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018130)
belen   
2021-08-25 13:05    		Where can I find those requirements? Are they documented somewhere? And if not, who should I talk to about them?
(0019828)
Florian Dold   
2023-02-13 20:04    		Waiting for feedback on DD35 now.
(0020007)
Florian Dold   
2023-04-04 12:02    		Seems like everyone agrees on DD35, we need to spec the corresponding wallet APIs now.
(0020192)
Florian Dold   
2023-05-11 14:39    		As noted by Marc, we should also have functionality to delete a known exchange (and the balance associated with that).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7842 [Taler] other major always 2023-05-10 19:38 2023-05-11 03:16
Reporter: dvn Platform:  
Assigned To: dvn OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Buildbot doc-builder not updating project sources
Description: The doxygen jobs on the doc-builder are running without ever updating the source repositories.

This means the doxygen jobs are just rebuilding from the same outdated checkout every build.

We need to make sure those repos are being updated before the doxygen jobs are run.
Tags: buildbot
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020191)
dvn   
2023-05-11 03:16    		Fixed in the following commits:

https://git.taler.net/deployment.git/commit/?id=13404a396ce25bfba5ef4b12ac6a0084563443d4
https://git.taler.net/deployment.git/commit/?id=6ebbc2c66c18559e582f3b3962a258faf604042e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7840 [Taler] wallet-core trivial N/A 2023-05-10 10:10 2023-05-10 10:10
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support new post-oec /keys format
Description: That way, we can remove the code to generate the 'old' format -- and seriously safe on bandwidth for /keys ;-).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7773 [GNUnet] transport service feature have not tried 2023-03-25 15:00 2023-05-09 19:25
Reporter: schanzen Platform:  
Assigned To: stmr OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: QUIC communicator
Description: This is the meta issue for the QUIC communicator in TNG
Tags: gsoc, tng
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7839 [Taler] libeufin (general) minor have not tried 2023-05-09 16:37 2023-05-09 16:37
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: CLI installation should check dependencies
Description: Following is one example where the CLI misses python3-click and the installation didn't detect it beforehand.

$ libeufin-cli sandbox --sandbox-url "${SANDBOX_URL}" demobank register
Traceback (most recent call last):
  File "/home/taler/bin/libeufin-cli", line 5, in <module>
    import click
ModuleNotFoundError: No module named 'click'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7838 [Taler] challenger feature N/A 2023-05-08 22:33 2023-05-09 11:07
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: none OS Version: squeeze  
Status: confirmed Product Version: 0.9.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Add support for rfc7636 to challenger
Description: This is mostly to follow best current practice, it is merely recommended in our scenario as our clients are no public and thus the "someone steals my client secret from an App" doesn't really apply to Taler. But, if we want to see challenger used more broadly (beyond Taler), this might be a nice feature to eventually add.
Tags:
Steps To Reproduce:
Additional Information: schanzen: I have some PKCE code in GNUnet if you want to steal it
https://git.gnunet.org/gnunet.git/tree/src/reclaim/oidc_helper.c#n710
System Description
Attached Files:
Notes
(0020189)
schanzen   
2023-05-09 11:07    		Note that you are implementing an AS. For the AS, it is a MUST in the BCP. For clients it is RECOMMENDED.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7811 [Taler] documentation feature have not tried 2023-04-22 17:55 2023-05-08 00:09
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: spec and implement taler://withdraw-exchange/ URIs
Description: This allows initiation of the manual withdrawal process even when the wallet does not necessarily know about the exchange yet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7836 [Taler] wallet-core minor have not tried 2023-05-07 22:11 2023-05-07 22:11
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: test-refund-gone doesn't work as expected
Description: While the test passes, it looks like the refund isn't actually gone --- for some reason, time-travel isn't working, and the refund works even though it shouldn't.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6588 [Taler] wallet-core tweak have not tried 2020-09-08 16:48 2023-05-07 16:43
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet-core should support range queries for the transactions list
Description: This might require some additional indices to be faster!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020188)
Florian Dold   
2023-05-07 16:43    		Main thing to discuss here: How do we actually do the pagination? What do we use as the "cursor"?

A transaction ID is not sufficient, as it doesn't efficiently allow querying transactions before or after it. So maybe a timestamp? But what if timestamps are not unique?

Probably the cursor should be a (timestamp, txid) tuple.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7816 [Taler] challenger feature N/A 2023-04-23 23:54 2023-05-07 01:46
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: challenger service needs to be implemented
Description: Right now, we have a skeleton.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020187)
Christian Grothoff   
2023-05-07 01:46    		challenger.git: 98577f5..95691c3 completes the first basic implementation of the challenger service. Tests pass!
What is missing is proper integration with the exchange.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7834 [Taler] wallet-core minor have not tried 2023-05-05 16:39 2023-05-05 16:39
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: wallet relies on longpolling to work
Description: Instead, the wallet should make sure that it does appropriate waiting if long-polling returns too early.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7829 [Taler] Web site(s) text always 2023-04-29 19:41 2023-05-05 16:04
Reporter: dvn Platform:  
Assigned To: Stefan OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Suboptimal Link Previews for taler.net
Description: When sharing the taler.net URL in a common messaging application, or social media site, the link preview generated shows a blurry GNU favicon instead of the Taler logo, and is non-descriptive.

This is due to the taler.net website lacking Open Graph[0] metadata in its HTML header. Link previews are generated using this metadata, if available.

I've included a patch which fixes this, and I've attached before and after screenshots of the link preview card. SVG is not supported, so I converted the logo to PNG and attached that, as well.


[0] https://ogp.me/
Tags:
Steps To Reproduce: Share "https://taler.net/" (or any localization) over a messenger such as Signal (what I did to test), or on a social media site like Twitter.
Additional Information:
Attached Files: opengraph.patch (855 bytes) 2023-04-29 19:41
https://bugs.gnunet.org/file_download.php?file_id=1373&type=bug
BEFORE-taler-linkpreview.png (20,580 bytes) 2023-04-29 19:41
https://bugs.gnunet.org/file_download.php?file_id=1374&type=bug
png

AFTER-taler-linkpreview.png (38,204 bytes) 2023-04-29 19:41
https://bugs.gnunet.org/file_download.php?file_id=1375&type=bug
png

logo-2021.png (28,781 bytes) 2023-04-29 19:41
https://bugs.gnunet.org/file_download.php?file_id=1376&type=bug
png

base.j2 (1,559 bytes) 2023-05-04 18:32
https://bugs.gnunet.org/file_download.php?file_id=1377&type=bug
stage.taler.png (22,757 bytes) 2023-05-04 23:35
https://bugs.gnunet.org/file_download.php?file_id=1378&type=bug
png
Notes
(0020171)
dvn   
2023-04-29 19:45    		This was auto-assigned to Stefan. I'm not sure if that's as it should be, but I don't seem to have the ability to change that.
(0020176)
dvn   
2023-05-04 17:11    		Stefan, what are your thoughts?
(0020178)
Stefan   
2023-05-04 18:32    		I poked a bit around with ICO generators and have now a couple of most common ICO and PNG files as well as an SVG image. 16x16 and 32x32 ICO images are awkward, so none of them will be at disposal.

All icon images have to be squares. favicon,ico and favicon.png have to be in the root folder (this requires an IE convention).

base.j2 shows the code to integrate all images. This is my solution to combine two worlds for an optimum outcome, also including your contribution as well. This code will be commited to Git and tested on several devices after I pushed the images to the git server, too.
 
Cheers,
Stefan
(0020181)
dvn   
2023-05-04 20:17    		Okay, so if I understand correctly you want to also update the icon/favicon to improve compatibility and image resolution?

That's a separate issue, in my mind, but it seems like a good idea.

The only thing I see that's a problem is in your `base.j2` attachment, is that you've added another `<meta name="description" [...]`

When you push the changes to master, can you make a comment here so we can look at https://stage.taler.net/ ?
(0020183)
Stefan   
2023-05-04 23:24    		You are absolutely right about the superfluous meta tag for description. I got rid of it now in the base-file and pushed changes in git to master so that you can see the effect on the staged website.

The 32x32 px favicon looks just ridiculous to me. I recommend to use the favicon we have on https://taler-systems.com instead (this was my choice over the old favicon). But please take a look yourself, whether it's OK for your eyes what you see on https://stage.taler.net/.

Thank you for your work in advance, dvn, looking forward to get your comments.
Cheers,
Stefan
(0020184)
dvn   
2023-05-04 23:35    		I agree that the current favicon does not look good scaled down so small. I also concur that the favicon https://taler-systems.com looks much better. I'd go with that if there's no reason *not* to.

As for the link previews, it is not showing any image, as I don't think .ico is supported by most clients. I've attached how it looks now.
We are not constrained to a square with the Open Graph image, so I think we should just use a PNG of the main Taler logo as I demonstrated before.
(0020185)
Stefan   
2023-05-05 06:31    		OK. Please test now.

Christian, is there any reason to not use the favicon we have for https://taler-systems.com?
(0020186)
dvn   
2023-05-05 16:04    		Stefan, it looks the same.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7830 [Taler] mechant backend feature N/A 2023-05-01 15:52 2023-05-04 22:02
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support webhooks for refunds
Description: n/a
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020182)
Christian Grothoff   
2023-05-04 22:02    		'refund' webhook event type is now implemented. Sebastian: please make sure the SPA allows the user to choose either 'pay' or 'refund' as the webhook event type when configuring webhooks.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7658 [Taler] qtart feature have not tried 2023-02-03 14:55 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: support threaded crypto workers
Description: Right now, qtart doesn't support running wallet-core with threaded crypto workers, because wallet-core doesn't yet understand the Worker API that QuickJS-libc offers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7697 [Taler] wallet-core tweak have not tried 2023-02-16 12:21 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: wallet is not GCing denominations
Description: Thus the database grows to a very large size.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7518 [Taler] wallet (WebExtension) feature have not tried 2022-12-11 04:10 2023-05-04 20:19
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: search transaction
Description: add a search bar

maybe in the first version just search fee text on transaction content
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7778 [Taler] wallet-core feature have not tried 2023-03-28 18:42 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: do more things in the wallet-core internal integration test
Description: We should do p2p transactions, refunds, etc., so that wallet UIs can use this to test transaction list rendering.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7736 [Taler] wallet-core feature always 2023-03-02 12:53 2023-05-04 20:19
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core should enforce accepted ToS for various operations
Description: UI need information about the ToS status

wallet-core should not allow using an exchange without accepting ToS first (does this happen also with withdrawals?)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7783 [Taler] wallet-core feature have not tried 2023-03-31 15:42 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet-core should long-poll P2P kyc status
Description: Otherwise the UI updates slowly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6397 [Taler] documentation text have not tried 2020-06-18 22:13 2023-05-04 20:19
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: write a good README(.md) file for LibEuFin
Description: See summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7506 [Taler] libeufin (general) feature have not tried 2022-11-30 22:58 2023-05-04 20:16
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Add helpers to generate test data.
Description: database data used in tests should be generated by convenient helper functions, instead of
being entered by verbose blocks of bare database instructions copied in several parts.
Tags:
Steps To Reproduce:
Additional Information: Examples are MakeEnv.kt and DownloadAndSubmit.kt in the Nexus test suite.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6396 [Taler] libeufin-nexus feature have not tried 2020-06-18 22:09 2023-05-04 20:16
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Implement FinTS
Description: ... as another bank connection type.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7694 [Taler] libeufin-sandbox feature have not tried 2023-02-14 13:23 2023-05-04 20:16
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: set currency conversion rates and fees in the configuration
Description: as opposed to have the hard-coded, as in the current version.

This however should be done after 0007527 and 0007515.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7588 [Taler] libeufin-nexus major have not tried 2023-01-14 10:56 2023-05-04 20:16
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: /admin/add/incoming has hard-coded credentials
Description: This call is offered in the Taler facade. It is used for testing and forwards the request
to fund the caller to their own bank account at the Sandbox. The Sandbox credentials
now are hard-coded in the facade, but should be specified via another mechanism.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7520 [Taler] libeufin-sandbox feature have not tried 2022-12-12 17:33 2023-05-04 20:15
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Implement policy to abort non confirmed cashout operations.
Description: A configurable time span should instruct libeufin sandbox to abort the cashout
operations that were never confirmed with the TAN.

This is not part of the API yet, and it should only be implemented after a first
deployment of Libeufin in the context of a local currency.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020060)
MS   
2023-04-11 10:40    		Not relevant for the Postfinance integration.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6268 [Taler] libeufin-sandbox feature have not tried 2020-05-29 08:47 2023-05-04 20:15
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: sandbox should support balances in c52/c53
Description: Right now, we always display a balance of 0.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017920)
MS   
2021-05-27 15:41    		For now (4c44480..d527df4) every report always include the whole history of one bank account.
(0019146)
Florian Dold   
2022-09-19 12:53    		There is an (incomplete!) test case "test-libeufin-nexus-balance" in the wallet integration tests. I will disable this test for now, but we should eventually fix it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7780 [Taler] taler-harness feature have not tried 2023-03-28 20:23 2023-05-04 20:15
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: taler-harness lint should check exchange ToS markdown syntax
Description: We require that there is at least one top-level section defined, and the linter should complain if not.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7592 [Taler] documentation text have not tried 2023-01-15 20:30 2023-05-04 20:12
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: libeufin-sandbox implementation of Taler Bank Access API may omit HTTP status codes.
Description: Research about which HTTP status codes should appear in the spec.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7147 [Taler] documentation text have not tried 2022-01-11 11:04 2023-05-04 20:12
Reporter: ttn Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: libeufin-{sandbox,nexus,cli} needs a manpage
Description: Question: Should it be part of the other Taler manpages?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: command-line-possibilities (4,652 bytes) 2022-01-11 13:26
https://bugs.gnunet.org/file_download.php?file_id=1136&type=bug
Notes
(0018628)
ttn   
2022-01-11 13:26    		I've made a preliminary distillation of the command-line possibilities for libeufin-cli (attached).
Please take a look. I'll convert it to a proper manpage once it gets your approval.
(0018637)
ttn   
2022-01-17 18:07    		Actually, it would be nice to have manpages for all libeufin programs, i.e., libeufin-{sandbox,nexus,cli}.
(0018640)
ttn   
2022-01-19 11:15    		I've started the libeufin-sandbox manpage:

https://git.taler.net/docs.git/commit/?id=bcd5adae13a2f0c94f98dc25c73c6dbcadf7d35d

@MS PTAL when you get a chance.
(0018641)
ttn   
2022-01-19 11:18    		I'm looking to clarify the libeufin-sandbox interaction model.
When you have a moment, could you take a look at the new (wip) manpage and let me know if i'm on the right track?
(0018642)
ttn   
2022-01-19 13:20    		@MS Another question:

https://git.taler.net/docs.git/commit/?id=edec0fdc0134da59e4293421f7bce37e392b8103
(0018663)
ttn   
2022-01-25 00:22    		I've just pushed the manpage for libeufin-sandbox(1).

Here are the relevant commits:
5adcf79 2022-01-24 New manpage: libeufin-sandbox(1)
01281b4 2022-01-24 add FIXME for ‘make-transaction’ and ‘camt053tick’
fcf97f5 2022-01-24 write ‘camt053tick’ description, including example
41f40cc 2022-01-24 fix typo: s/that/for/
45b63d0 2022-01-24 write ‘make-transaction’ description
4dc26e1 2022-01-24 replace question to MS w/ blurb on Control-C
a41b104 2022-01-24 replace FIXME w/ libeufin-cli
4432884 2022-01-24 mention direct-access operation mode
21f1f6b 2022-01-24 document automagic ‘default’ demobank creation for ‘make-transaction’ and ‘serve’
8de9a0e 2022-01-24 write ‘default-exchange’ description, including example
7bfee7b 2022-01-24 write ‘config’ description, including example
d6d3763 2022-01-24 reorder command ‘config’ before ‘default-exchange’
f770a37 2022-01-19 s/core banking system/banking system core/g
edec0fd 2022-01-19 describe ‘serve’ in libeufin-sandbox(1)
5c02597 2022-01-19 describe ‘reset-tables’ in libeufin-sandbox(1)
bcd5ada 2022-01-19 new WIP manpage: libeufin-sandbox(1)

Feedback welcome!

Now on to libeufin-nexus(1)...
(0018671)
ttn   
2022-01-26 12:21    		The libeufin-nexus(1) manpage is now available:

- https://git.taler.net/docs.git/commit/?id=65a9b2dc88c4756f10c8287347d33b01bb1ec9c4
- https://docs.taler.net/manpages/libeufin-nexus.1.html

Now on to the big one: libeufin-cli(1)!
(0018677)
ttn   
2022-02-02 06:25    		After some discussion w/ MS, i've come to a better understanding (maybe) of the Access API as it
relates to the LIBEUFIN_SANDBOX_URL env var. To help the documentation effort, i've pushed:

- https://git.taler.net/libeufin.git/commit/?h=dev/ttn/refactoring&id=4caed8388d11701da995cf368c21a6b742e2b628

IIUC, non-Acess-API commands will go away at some point. So, i wonder if it makes sense to document
them at all. My question is: Is there a timeframe planned for their removal?
(0018678)
ms-mantis   
2022-02-02 07:39    		I'd discourage to document those: both in the manpage and in various tutorials.
They'll be removed once TypeScript tests (at wallet-core.git) won't use them anymore.
No defined timeframe but now reported here: 0007168
(0018692)
ttn   
2022-02-10 10:37    		OK, i'm taking a detour from the libeufin-cli(1) manpage to fix up the "configuring the sandbox" section in the Nexus tutorial:

- https://git.taler.net/docs.git/tree/libeufin/nexus-tutorial.rst#n130

Currently, here are the libeufin-cli sandbox commands used in that section:
  - cli sandbox check
  - cli sandbox ebicshost create
  - cli sandbox ebicshost list
  - cli sandbox ebicssubscriber create
  - cli sandbox ebicssubscriber list
  - cli sandbox ebicsbankaccount create
  - cli sandbox bankaccount generate-transactions
  - cli sandbox bankaccount simulate-incoming-transaction
  - cli sandbox bankaccount transactions

Of these, i'm trying to determine which are "old" commands (to be replaced by 'libeufin-cli sandbox demobank' commands, perhaps).
I guess the "... create" commands are "old", but the "... list" commands are going to stay. Is that correct?
My question generally is: Which of those are "old"?
(0019055)
Christian Grothoff   
2022-08-25 21:30    		MS: can you please try to help ttn with this?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7664 [Taler] documentation text have not tried 2023-02-08 13:18 2023-05-04 20:12
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: merge api core documentation
Description: move libeufin sandbox api to core/libeufin-sandbox-api
move libeufin nexus api to core/libeufin-nexus-api
merge integration, access, circuit into sandbox document (same component, different sections, like merchant)
move wallet-core core/wallet-api (it's not HTTP but belongs here)

from grothoff
> I also think the existing chatper 1.15 on 'errors and testing' should probably be removed. It doesn't cover all the errors (gana does!), and I'm not sure the 2 testing scenarios described there belong there (or are still relevant!)
> 1.13 should also die: we have RFC 8905 for that. We should link to that and be done with that. For 1.14 we have the draft, which we should put on lst.gnunet.org and again remove that chapter and link to the draft.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7669 [Taler] documentation text have not tried 2023-02-09 16:07 2023-05-04 20:11
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Document data types used in libeufin REST calls.
Description: One example are amounts: there should be one document that specifies their format.
Along this, the API docs have to point at those specifications whenever the said type is
mentioned. The same way that Taler does with api-common.rst.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019791)
MS   
2023-02-09 16:52    		be6eb54..af11ed5 starts to address this. Notably, the size in bits of the integer part of amounts is not documented.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7591 [Taler] documentation text have not tried 2023-01-15 20:28 2023-05-04 20:11
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Review Nexus native API specification.
Description: Check whether the implementation matches the spec and research
about which HTTP response codes should appear in the spec.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019968)
MS   
2023-03-20 16:33    		What is documented does exist in the code. Before closing this, the reverse process should be done.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7665 [Taler] documentation text have not tried 2023-02-08 16:31 2023-05-04 20:10
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: Document database schema of Sandbox and Nexus
Description: of both Sandbox and Nexus.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7807 [Taler] documentation text have not tried 2023-04-21 15:04 2023-05-04 20:10
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: document conventions/guidelines for source-level dependencies (i.e. prebuilt branches and submodules)
Description: We currently handle this slightly different across subprojects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7826 [Taler] other feature have not tried 2023-04-26 13:01 2023-05-04 20:06
Reporter: javier.sepulveda Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: Taler OPS - Install PostgreSQL
Description:  Install PostgreSQL
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020174)
javier.sepulveda   
2023-05-04 12:41    		PostgreSQL 13 installed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7825 [Taler] other minor have not tried 2023-04-26 12:02 2023-05-04 20:06
Reporter: javier.sepulveda Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: Taler OPS - Etckeeper
Description: Install and configure etckeeper, instead of bind mount the /etc directory into the maintenance git folder.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020162)
javier.sepulveda   
2023-04-26 12:38    		Etckeeper installed and configured okay.
Plus I have left a short tutorial, with a simple list of commands, to keep track of changes or revert things.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7779 [Taler] wallet (Android App) minor have not tried 2023-03-28 18:45 2023-05-04 20:06
Reporter: grote Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: Add dev option to run integration test
Description: The integration test leaves transactions in the history and even some KUDOS in the balance. So this can be helpful for quick smoke testing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019984)
grote   
2023-03-28 20:07    		resolved in https://git.taler.net/taler-android.git/commit/?id=4d0fabf804e1afffd91927d9805a026e8aaad777 just not sure if it is normal that no transaction of the test get left behind in the history.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7770 [Taler] demobank-ui minor have not tried 2023-03-16 15:18 2023-05-04 20:06
Reporter: MS Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: typo
Description: UI shows this wrong text: "Repeast password", when trying to change a user password from the admin panel.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020000)
sebasjm   
2023-04-01 00:17    		at ce53dd8b8

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7768 [Taler] demobank-ui minor have not tried 2023-03-14 12:43 2023-05-04 20:06
Reporter: MS Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: cash-out rates wrong when starting from fiat.
Description: When the cash-out amount is calculated starting from the fiat, then the UI
submits a rates/fees application that's not accepted by the backend.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019964)
sebasjm   
2023-03-15 13:46    		the truncation of amount after applying rate conversion is wrong, here [1] SPA is doing a simple string truncation and libeufin does a BigDecimal round up, SPA should match that [2]

if calculateFromCredit with amount 3.15 sellFee 0 sellRate 0.95 I get amount debit debitAmount 3.31 which is wrong because calculateFromCredit for amount 3.31 (same rates) the credit is 3.14 !== 3.15

Amounts API in taler-util doesnt have a truncation or roundup function, should we add this function in amounts API?


[1] https://git.taler.net/wallet-core.git/tree/packages/demobank-ui/src/pages/BusinessAccount.tsx#n839
[2] https://git.taler.net/libeufin.git/tree/sandbox/src/main/kotlin/tech/libeufin/sandbox/CircuitApi.kt#n404
(0019998)
sebasjm   
2023-04-01 00:16    		using the cashouts/estimate endpoint
(0019999)
sebasjm   
2023-04-01 00:16    		fixed at f947c8e54919343ac4f5f951d2f701651c06dd52

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7767 [Taler] demobank-ui minor have not tried 2023-03-14 12:41 2023-05-04 20:06
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: negative balance not shown from admin panel
Description: If one customer has negative balance "-X", the admin panel shows instead "X" as the balance.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019963)
sebasjm   
2023-03-15 13:43    		the balance response has "DBIT" | "CRDT" in field credit_debit_indicator
in the docs is specified "credit" | "debit" which SPA expect here https://git.taler.net/wallet-core.git/tree/packages/demobank-ui/src/pages/AdminPage.tsx#n323

doc https://docs.taler.net/libeufin/api-sandbox.html#get--accounts
(0019965)
MS   
2023-03-15 20:05    		fixed libeufin here: 297a6344..973ec3de.

Setting as feedback until the next test.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7756 [Taler] deployment and operations minor have not tried 2023-03-08 18:31 2023-05-04 20:06
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: move .deb packaging infra to non-root user, with user-local docker service enabled
Description: This allows us to build debs as a non-privileged user.

We should not have to log into the system as root for non-sysadmin tasks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019962)
Florian Dold   
2023-03-14 11:02    		Could you elaborate a bit on which user is now responsible?
(0019966)
Florian Dold   
2023-03-16 09:18    		Did this myself; the taler-packaging user is now responsible.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7751 [Taler] merchant-pos-terminal (Android App) minor have not tried 2023-03-07 18:20 2023-05-04 20:06
Reporter: grote Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: Add free-form to add custom amounts to order
Description: Add a keypad icon that allows us to add a custom order item with a custom amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019970)
grote   
2023-03-21 17:36    		implemented in https://git.taler.net/taler-android.git/commit/?id=e690df6d0eaacb60ca9edf1d4caf382711278b8b

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7723 [Taler] demobank-ui minor have not tried 2023-02-24 01:15 2023-05-04 20:06
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: bank backend URL should be configurable in globalThis.talerDemobankSettings
Description: We currently use localStorage to override the bank backend base URL, but that's annoying to configure. We should also allow the same mechanism we use for the other config overrides.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019905)
sebasjm   
2023-02-26 00:06    		fixed at d11048b68

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7808 [Taler] exchange feature have not tried 2023-04-21 22:48 2023-05-04 20:05
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: wire transfer tracking endpoints should support long-polling
Description: The wallet needs to wait for deposits to be done, and this should be done via long-polling rather than busy retrying.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020127)
Christian Grothoff   
2023-04-23 13:30    		Wallet should be able to signal that it wants to wait for a change in AML status here, too.
(0020128)
Christian Grothoff   
2023-04-23 13:32    		Merchant should then ALSO use this one to long-poll for AML status updates.
(0020130)
Christian Grothoff   
2023-04-23 17:52    		EXCHANGE_DEPOSIT_STATUS_CHANGED added to GANA for this.
(0020177)
Christian Grothoff   
2023-05-04 17:15    		2de2b6e3..7c0de44a modifies the main handler logic. Missing are:
1) actual DB event generation to wake up the handler
2) update to libtalerexchange to support LP in the C API
(0020180)
Christian Grothoff   
2023-05-04 20:05    		Seems fine, documented, updated merchant to accept new API.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7832 [Taler] deployment and operations tweak have not tried 2023-05-03 14:43 2023-05-04 13:22
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Setting libeufin log level.
Description: Both libEuFin services have a "--log-level" option under the "serve" subcommand. That should be set to "warn", to further reduce disk usage.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020175)
MS   
2023-05-04 13:22    		Fixed here (deployment.git): 83a8c0695d4e1a507adad8367f318065ae4ade7e

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6363 [Taler] mechant backend feature have not tried 2020-06-03 13:31 2023-05-04 10:52
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: allow merchants to query more information about the deposit status
Description: Quoting from the e-mail discussion:

>> I'm not really sure what to do there in practice, as "Taler 1.0" doesn't
>> really have any way for the merchant to ask about the status of the
>> transfer other than trying to call the exchange.
>>
>
> Well, we do have:
>
> https://docs.taler.net/core/api-exchange.html#get--deposits-$H_WIRE-$MERCHANT_PUB-$H_CONTRACT_TERMS-$COIN_PUB
>
> We could easily add a HTTP "Failed Dependency" status code to the API
> here and define a message format to indicate details about the problem
> to the merchant (and prescribe resolution strategies).
>
> This would mostly require another taler-exchange-XXX process to _query_
> LibEuFin for R-transactions, *and* a change to the exchange DB schema.
> More messy: this will require additional changes to the merchant
> backend. Please file a bug on this on Mantis, but I think we should
> target Taler v1.5 for this, given the scope of the changes and need for
> testing -- and the hopefully reasonably low likelihood of occurrence. At
> least I think we should be fine to manually handle the first generation
> of complaints for R-transactions, and that might even be better than
> trying to automate a process where we may not fully understand all the
> ways these things fail in practice.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016388)
Christian Grothoff   
2020-07-06 11:00    		Some status information is now provided ('wired'), alas automatically querying LibEuFin for transactions as _merchant_ is missing: right now, the merchant has to manually POST incoming transactions to the backend.

Writing a taler-merchant-wirewatch tool should be done, but later.
(0017804)
Christian Grothoff   
2021-05-09 13:48    		DD13 will include the required wire API changes (as we need to change the wire API for DD13 anyway).
(0017805)
Christian Grothoff   
2021-05-09 19:45    		Discussed with Florian: wire API should NOT be used for this, but a separate libEuFin facade created.
(0019527)
Christian Grothoff   
2022-12-20 23:23    		Marcello: can we please semi-urgently discuss this? I think this would be very good for Basel, and if you can _easily_ add the facade (which I would expect), I could likely get Priscilla to do the merchant backend legwork in January...
(0020047)
Christian Grothoff   
2023-04-10 13:25    		Marcello (correctly) suggests to try to get this working using the Anastasis facade first.
(0020079)
Christian Grothoff   
2023-04-12 15:12    		taler-merchant-wirewatch skeleton now exists. Todo: parse subject line, persist progress in new DB table, add man-page + test.
(0020080)
Christian Grothoff   
2023-04-12 16:10    		Parsing, persisting and man-page are done. Testing is left.
(0020089)
Christian Grothoff   
2023-04-13 19:29    		src/testing/test_merchant_wirewatch.sh is now a new test for this feature. However, it currently fails with a 500 internal server error from libeufin.
1) obviously we shouldn't ever fail with 500, so that should be fixed, _maybe_ a 502 is appropriate. So first the HTTP status should probably be fixed.
2) I do not understand _why_ we fail (what is wrong with the setup/script).

Marcello: could you please look into both of these soon? Thanks!
(0020095)
MS   
2023-04-14 17:16    		The error is from Nexus alone, _before_ even reaching the bank: the 502 error would
not apply in this case.

That's the response along the 500 status:

{
  "code" : 9000,
  "hint" : "nexus error, see detail",
  "detail" : "EBICS (outgoing) document is invalid"
}

That happens because the EBICS document it is sending to the bank has one
invalid value, which is the EBICS partner ID (in this case). The log below from
libeufin-nexus-stderr.log shows the details:

16:55:23.343 [eventLoopGroupProxy-4-1] WARN tech.libeufin.util - Validation failed: org.x
ml.sax.SAXParseException; lineNumber: 1; columnNumber: 235; cvc-pattern-valid: Value '{gnu
net_partner}' is not facet-valid with respect to pattern '[a-zA-Z0-9,=]{1,35}' for type 'P
artnerIDType'.
16:55:23.349 [eventLoopGroupProxy-4-1] ERROR tech.libeufin.nexus - Caught exception while
handling '/bank-connections/gnunet-connection/connect (EBICS (outgoing) document is invali
d (HTTP status 500 Internal Server Error))

Try to adjust the value in "--partner-id" in the CLI's "new-ebicssubscriber" subcommand to one
that matches the pattern shown above in the logs.
(0020096)
Christian Grothoff   
2023-04-16 10:54    		After your fix, it still doesn't work: the facade doesn't return the transaction! I've tried adding an explicit fetch-transactions in addition to the existing "sleep 3", but neither seems to make the transfer show up in the facade!? Please help!
(0020097)
Christian Grothoff   
2023-04-16 11:34    		With the very latest wallet, the withdraw step fails (wallet regression). => Assigning to Florian.
(0020104)
Florian Dold   
2023-04-17 14:10    		According to what MS said on the phone, the issue was with how that wallet was used. And that invocation should be fixed now.
(0020131)
Christian Grothoff   
2023-04-23 17:52    		Design discussion:
- configuration for taler-merchant-wirewatch should entirely move into the database
- tmw should NOT use the REST API (no credentials!)
- tmw should support multiple instances (from one process)
- merchant-exchange interaction for transfers should be moved into a separate helper process (triggered by NOTIFY)
(0020132)
Christian Grothoff   
2023-04-23 17:53    		MERCHANT_WIRE_TRANSFER_CONFIRMED and MERCHANT_ACCOUNTS_CHANGED added to GANA as new event types for this.
(0020134)
Christian Grothoff   
2023-04-23 20:25    		31e5e07..dba2b83 documents the API change to allow user to configure taler-merchant-wirewatch per instance.
(0020135)
Christian Grothoff   
2023-04-23 23:06    		Credentials and progress tracking are now stored in merchant backend together with accounts. Missing is moving the merchant-exchange interaction into a separate helper.
(0020164)
sebasjm   
2023-04-26 19:21    		pushed 9df2547cc..03d3cce82

need an updated merchant to test it out
(0020173)
Christian Grothoff   
2023-05-04 10:51    		6396057..9316c05 should fix taler-merchant-exchange and removes now dead logic from the POST /transfers endpoint.
Assuming the SPA can handle the 204 instead of the 200 for the POST /transfers endpoint (reported separately on mattermost), this should fix "everything" for this bug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7833 [Taler] libeufin (general) feature have not tried 2023-05-03 15:23 2023-05-03 22:19
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Implement programmatical DB migration.
Description: LibEuFin database should migrate the same way that other Taler components do. One .sql-file for every database version that get passed to 'psql'. The order to pass the .sql-files to 'psql' is determined by the numbered file names.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7831 [Taler] documentation text have not tried 2023-05-02 08:41 2023-05-02 18:51
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Create section about setting up a regional currency.
Description: One NLnet suggestion was to have a documentation section about how
to _completely_ setup a regional currency, therefore with ALL the Taler
components.

And before publishing it, any tool (e.g. shell scripts) should have general names
that do NOT mention any particular regional currency, and the source code as well
should NOT hard-code any value related to one particular regional currency.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7810 [Taler] exchange feature have not tried 2023-04-22 17:54 2023-05-02 12:09
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: support conversion service URL and regex validation for /wire
Description: We also need to distinguish between withdrawals and deposits, as in the conversion case, different restrictions for the payto:// URI apply.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020126)
Christian Grothoff   
2023-04-22 22:08   
(Last edited: 2023-04-22 22:09) 		API change for /wire specified in docs.git -- 43a3dca..d3102b7.

Once implemented, we MUST bump the protocol to "15:0:0" and add a (transient) protocol-version based switch in libtalerexchange.
(0020172)
Christian Grothoff   
2023-05-02 12:09    		This is largely implemented (exchange, merchant, documentation). Wallet is missing (=> assigning to Florian). What is still missing is that the merchant (and wallet) currently ignores debit restrictions imposed by the exchange and would be perfectly happy to accept deposits for coins from exchanges where the exchange doesn't actually accept the merchant's bank account.

To fix this, we need a working regex evaluator for this style of regex AND to modify the pay logic to actually check.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7446 [Taler] wallet-core feature have not tried 2022-11-07 16:30 2023-04-29 13:49
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: dev mode is not persisted after restart
Description: Service worker is a short lived process, so any setting on the wallet core should persist restart.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019428)
sebasjm   
2022-11-16 18:55    		should we add this into the wallet-core db?
(0019452)
Christian Grothoff   
2022-11-18 22:40    		Does it even make sense to persist dev-mode? I actually think turning it off on restart might be a good thing. Devs can re-enable, but having it on by accident might be bad...
(0019473)
MarcS   
2022-11-23 00:07    		On iOS, Dev-Mode is persisted in the application settings, which is just two words of code preceding a variable definition:
    @AppStorage("developerMode") var developerMode: Bool = false
Next time the app launches it will not init with false, but use the value for key "developerMode". If I delete the first two words, the app will fall back to false at launch - after reboot, or if the user manually kicked it off the background app list, or the user launched so many other apps while we are in the background that iOS runs out of memory and kills us - which could take days if the user doesn't launch many other apps. In this case they would maybe see Dev-Mode active for multiple days, and on other days falling back to inactive even within minutes (if they launch many other apps before coming back to us). Such unpredictability is not the best user experience - but OK, it's just developer mode...
(0019477)
sebasjm   
2022-11-23 12:57    		> I actually think turning it off on restart might be a good thing.

Restart the browser yes, but service worker may restart (wiping out wallet memory) after short time.

I will implement saving the state in localStorage (the web version of marc's description) and sync wallet on startup.
(0020163)
sebasjm   
2023-04-26 16:28    		fixed with the implementation of feature flags

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7796 [Taler] merchant backend API (HTTP specification) feature N/A 2023-04-10 10:39 2023-04-29 13:48
Reporter: Christian Grothoff Platform: i7  
Assigned To: sebasjm OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: store user type in merchant instance settings
Description: We right now hard-code BUSINESS as the user-type for KYC, which is incorrect.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020076)
Christian Grothoff   
2023-04-11 19:45    		Fixed in feaf7ba..5ed3b2c
(0020077)
Christian Grothoff   
2023-04-11 19:45    		Next is to add support to the SPA => assigning to sebasjm!
(0020152)
sebasjm   
2023-04-25 05:35    		fixed at 25346a03f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7134 [libmicrohttpd] build system major always 2021-12-30 07:21 2023-04-28 22:26
Reporter: kloczek Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.75  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 0.9.76  
    Target Version: 0.9.76  
Summary: 0.9.75: missing file chapters/websocket.inc in dist tar ball
Description: Looks like it is missing file in dist tart ball. I found it after modify *texi files afetr which it was necessary to renerate info pages.

Making all in doc
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
Making all in .
make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/sh '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/build-aux/missing' makeinfo --version) >/dev/null 2>&1; then \
  for f in libmicrohttpd-tutorial.info libmicrohttpd-tutorial.info-[0-9] libmicrohttpd-tutorial.info-[0-9][0-9] libmicrohttpd-tutorial.i[0-9] libmicrohttpd-tutorial.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/sh '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/build-aux/missing' makeinfo -I . \
 -o libmicrohttpd-tutorial.info libmicrohttpd-tutorial.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd .; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd . && \
  $restore $backupdir/* `echo "./libmicrohttpd-tutorial.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
libmicrohttpd-tutorial.texi:116: @include: could not find chapters/websocket.inc
make[3]: *** [Makefile:553: libmicrohttpd-tutorial.info] Error 1
make[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
make[2]: *** [Makefile:774: all-recursive] Error 1
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75/doc'
make[1]: *** [Makefile:608: all-recursive] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.75'
make: *** [Makefile:515: all] Error 2

Please next time on generate dist tar ball use "make distchec" instead "make dist"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018753)
Christian Grothoff   
2022-02-28 23:55    		Fixed by Evgeny in bf89bd95f8d4401ddaabdb59023175e66bdbd80f
(0020169)
kloczek   
2023-04-28 21:57    		Still dist tar ball is broken.
(0020170)
kloczek   
2023-04-28 22:26    		Looks like not only doc/chapters/websocket.inc is missing in tar ball.
After add that filre on buiulding rpm package building documentation failed on another file

libmicrohttpd-tutorial.texi:190: @verbatiminclude: could not find examples/websocket.c
make[1]: *** [Makefile:554: libmicrohttpd-tutorial.info] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/libmicrohttpd-0.9.76/doc'
make: *** [Makefile:775: all-recursive] Error 1

PLEASE make sure next time that dist tar ball has been generated not using "make dist" but "make dist check".

IMO it would be good ASP make new release with all missing files.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7828 [Taler] wallet (WebExtension) minor have not tried 2023-04-28 19:02 2023-04-28 19:04
Reporter: MS Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Blog payment opens two tabs with the content.
Description: Buying one article ends with two tabs showing the article just paid.

To reproduce:

0. Click on one article in the shop.
1. Open the wallet pop-up
2. Click the "open pay page".
3. Finalize the payment.

Observed in this version "0.9.3-dev.5".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6860 [Taler] Merchant frontends (Python3) minor have not tried 2021-05-10 17:17 2023-04-28 18:30
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: avoid redirect loop in blog merchant frontend demo
Description: When the user agent blocks cookies (or for some other reason the cookie that we expect isn't set correctly, such as due to escaping issues), the browser is currently sent in a redirect loop.

This could be avoided via some intermediate URL that just sets the order ID cookie *or* shows a warning to the user that the cookie wasn't set.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020154)
MS   
2023-04-25 18:29    		I could reproduce it.

By disabling the cookies, and:

1, visiting shop.demo.taler.net
2, clicking on one article
3, getting the QR code page to pay
4, instructing the Firefox wallet to pay
5, confirming the payment in the contract page

The browser is faced again with the QR code page from step 3.
(0020168)
MS   
2023-04-28 18:30    		Addressed here: 6fa8d80..9431000.

The wallet redirect, however, still causes the article to be requested twice. The browser is left in fact with two tabs showing the content.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7827 [Taler] libeufin-sandbox minor have not tried 2023-04-27 14:57 2023-04-27 14:57
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Refund invalid attempts of withdrawing the regional currency.
Description: Incoming payments to the association's fiat bank account are expected to have a valid reserve public key. The conversion service for now ignores invalid payments, letting them stay in the association's fiat bank account. Such payments should instead be refunded to the original sender.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7426 [Taler] Web site(s) minor have not tried 2022-11-03 09:18 2023-04-27 08:56
Reporter: MS Platform:  
Assigned To: javier.sepulveda OS:  
Priority: low OS Version:  
Status: assigned Product Version: 0.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: "public-accounts" link points at bank's homepage
Description: The landing Website offers a link to the "public-accounts" page at the bank. The
link however doesn't show a dedicate page of public accounts, but rather the bank's
homepage.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019362)
Christian Grothoff   
2022-11-06 23:18    		When I click the link inside of the SPA header, I get a message saying that there are no public accounts. Also, I don't know what the deep link to get the public account page would even be right now.

We should fix the demo to have the public accounts setup, fix the link inside the SPA, and have a way to get to the public accounts page from the outside. Maybe the public accounts page should even not be the main SPA but some separate page/SPA served under a different URL?
(0019363)
Christian Grothoff   
2022-11-06 23:19    		Maybe we should disable the links (landing page, bank header) until this is fixed? Not sure how long it'll take...
(0019366)
sebasjm   
2022-11-07 12:16    		The navigation should be made based on URI (fragment is usually used so the SPA can be serve from an unique location) instead of localStorage state.
I will take a look
(0019380)
sebasjm   
2022-11-07 16:44    		fixed at 3eafb649
(0019381)
MS   
2022-11-07 16:57    		The links on the demo navigation bar should now be adapted to this new change.
(0020166)
MS   
2023-04-27 08:54    		Fixed in taler-merchant-demos.git at 6fa8d80b8d6873935ab14956b4ba62932bdd2a14. The "?lang=en" part is also gone from the link, as suggested by Sebastian.
(0020167)
MS   
2023-04-27 08:55   
(Last edited: 2023-04-27 08:56) 		Setting to feedback and assigning to Javier to be ultimately checked after the next demo deployment.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7819 [Taler] demobank-ui minor always 2023-04-25 09:12 2023-04-26 19:47
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: clicking "abort" in demobank-ui does not abort the underlying withdrawal operation
Description: It only closes the dialog. Instead, it should also POST ${wopid}/abort to notify wallets that have potentially already scanned the QR code that the withdrawal is aborted.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020165)
sebasjm   
2023-04-26 19:47    		fixed 93e8010b5

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7822 [Taler] libeufin-nexus feature have not tried 2023-04-25 23:50 2023-04-26 09:34
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: nexus should have endpoint to submit all pending payment initiations; exchange tests should use it
Description: See 0007809. Currently we use a sleep of 5 seconds in the test, to make sure that nexus has time to submit payment initiations to sandbox and then fetch transactions. Instead of sleeping, we should be able to explicitly trigger payment initiations. We already have an API that does that, but only for particular PAINs. But we should have one that submits *all* PAINs of a nexus account.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020161)
MS   
2023-04-26 09:33    		Exists, documentation now mentions it: https://git.taler.net/docs.git/commit/?id=493c38e2f7522da54e9e9ced88f8e5d68d77378d

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7809 [Taler] libeufin-nexus block always 2023-04-22 15:34 2023-04-26 00:23
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: regression: test_bank_api_with_nexus started to fail
Description: Basically, the test says that the expected debit transaction history is empty, even though it should have a transaction in it.

There were no changes I would consider even 'related' to this issue in the exchange, so this is likely a regression in libeufin.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: test_bank_api_with_nexus.log (27,721 bytes) 2023-04-24 20:25
https://bugs.gnunet.org/file_download.php?file_id=1371&type=bug
new-log.txt (33,288 bytes) 2023-04-25 23:07
https://bugs.gnunet.org/file_download.php?file_id=1372&type=bug
Notes
(0020141)
MS   
2023-04-24 14:49    		Could not reproduce.
(0020146)
Christian Grothoff   
2023-04-24 20:25    		Attaching the log from the test. I really just run 'make check' with the latest gnunet/exchange/merchant/libeufin.
(0020153)
MS   
2023-04-25 12:59   
(Last edited: 2023-04-25 13:02) 		The logs suggest that the failing "history-2b" command started before the libeufin scheduler could start the
"fetch" task. This change in libeufin.git makes tighter rounds to schedule background tasks:
2471f00eba039a460cc31f02fc47a2267367efd.
(0020156)
Christian Grothoff   
2023-04-25 23:07    		With Florians help, after spending like 2h, we've added the fetch-transactions you suggested. But, it still fails the same way as before. Log attached.
(0020159)
Christian Grothoff   
2023-04-26 00:22    		Florian figured it out. Additional feature bugs filed, but for now the test again passes (together with MS change from 5s to 1s for scheduler loop frequency).
(0020160)
Christian Grothoff   
2023-04-26 00:23    		The high-level point was that fetch-transactions is not enough, as first the transaction from nexus to sandbox has to go through, not only from sandbox to nexus. With a scheduler loop running only every 5s, the 5s sleep was no longer enough, even with the force-fetch. With 1s frequency, a 5s wait is plenty.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7820 [Taler] merchant backend API (HTTP specification) feature N/A 2023-04-25 18:41 2023-04-26 00:20
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: /paid should signal if contract was refunded
Description: When, during repurchase detection, a wallet uses /paid, the merchant backend should signal the wallet if the order has been (partially) refunded.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020158)
Christian Grothoff   
2023-04-26 00:20    		Implemented in fd591ef..7afc018

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7821 [Taler] libeufin (general) major always 2023-04-25 23:10 2023-04-25 23:55
Reporter: Christian Grothoff Platform: i7  
Assigned To: MS OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implementation of basic-auth on server is wrong
Description: Which is why it works with curl but not with wget. wget doesn't like it because the server does not return a proper challenge when requesting authorization.

This applies to nexus and sandbox.

When giving a 401, WWW-Authenticate should always be properly specified by the server.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020157)
Christian Grothoff   
2023-04-25 23:11    		Passing "--auth-no-challenge" to wget works around the issue, but this is a bug in the HTTP server logic and should be fixed there.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7716 [Taler] sandcastle (containerized demo deployment) major always 2023-02-23 01:02 2023-04-25 19:33
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: survey bank account does not allow high negative balance needed for tipping
Description: We either need to increase the limit or somehow add funds to the account in a different way.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019904)
Florian Dold   
2023-02-23 23:30    		We should just transfer a bigger amount of money from the bank's root account to the survey account.
(0019938)
Florian Dold   
2023-03-08 19:37    		I'm keeping this open until we automate it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7229 [Taler] wallet-core minor have not tried 2022-04-18 17:36 2023-04-25 19:18
Reporter: ms-mantis Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: unable to reproduce  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: tipping fails due to "logic invariant failed"
Description: Passing the "taler://tip" URI to the CLI wallet fails with the following message:

2022-04-18T15:30:08.523Z wallet.ts INFO finished wallet core request with error: {
  "code": 7001,
  "hint": "unexpected exception (message: BUG: logic invariant failed)",
  "stack": "Error: BUG: logic invariant failed\n at checkLogicInvariant (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:16495:19)\n at getExchangeWithdrawalInfo (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:19462:5)\n at async prepareTip (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:22622:9)\n at async dispatchRequestInternal (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:26771:20)\n at async handleCoreApiRequest (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:26900:24)\n at async Object.call (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:26618:25)\n at async /home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:47266:33\n at async withWallet (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:47125:21)\n at async CommandGroup.myAction (/home/job/.local/lib/taler-wallet-cli/node_modules/taler-wallet-cli/dist/taler-wallet-cli.js:47255:5)"
}
Operation failed: undefined
Error details: undefined
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019859)
Florian Dold   
2023-02-17 02:37    		Do you recall how this can be reproduced? Otherwise, I suggest closing it.
(0020155)
MS   
2023-04-25 19:17    		Latest wallet (c8d78d68d369bcc3ff3e0fc257b481146ec92626) is not failing anymore.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7684 [Taler] merchant backend API (HTTP specification) feature N/A 2023-02-13 15:14 2023-04-25 04:47
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: report exchange AML issues in merchant REST API
Description: https://docs.taler.net/core/api-merchant.html#get--instances-$INSTANCE-private-kyc should report AML status from
600fc4f645286d30cc8446bec1aac466a27a8ec3 (docs.git); GET /deposits/ endpoint of the exchange.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020044)
Christian Grothoff   
2023-04-10 10:48    		79b2673..837416e updates the spec.
(0020045)
Christian Grothoff   
2023-04-10 10:48    		677ac4a5..090c532b modifies the exchange to return the AML status together with the KYC status.
(0020046)
Christian Grothoff   
2023-04-10 11:19    		31babe5..208dbea modifies the merchant to expose the AML status in its API. Untested!
(0020063)
Christian Grothoff   
2023-04-11 11:01    		ad925cc..feaf7ba adds a test.
(0020064)
Christian Grothoff   
2023-04-11 11:02    		Last step is to add support to the SPA to show a pending/frozen AML state to let the user know why they might not be getting any money ;-). => Assigning to sebasjm.
(0020151)
sebasjm   
2023-04-25 04:46    		fixed 2f8de9ea8..00f108b9d

if (kyc url !== undefined) => kyc (1)
else if (aml === 1) => AML pending (2)
else => AML frozen (3)

text:
1.- Pending KYC process, click here to complete
2.- There is an anti-money laundering process pending complete
3.- The account is frozen due to the anti-money rules. Contact the exchange service provider for instructions.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7749 [Taler] wallet-core minor have not tried 2023-03-07 18:16 2023-04-24 23:00
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet-core should forward offline payment TOTP to UIs
Description: See summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Selection_086.png (41,596 bytes) 2023-04-24 19:53
https://bugs.gnunet.org/file_download.php?file_id=1370&type=bug
png
Notes
(0020123)
Florian Dold   
2023-04-21 12:41    		Sebastian already implemented it in wallet-core. Is it also supported in the UI? I also wonder if we should have an integration test.
(0020142)
sebasjm   
2023-04-24 19:53    		fixed at 974cd0206
(0020143)
sebasjm   
2023-04-24 19:53   
(0020144)
sebasjm   
2023-04-24 19:57    		the list of numbers is serialized by the merchant to a string separated by \n
this is not standard

comma separated is better or maybe just a simple array of numbers instead of string

https://docs.taler.net/core/api-merchant.html#post-[-instances-$INSTANCE]-orders-$ORDER_ID-pay
(0020145)
Christian Grothoff   
2023-04-24 20:01   
(Last edited: 2023-04-24 20:02) 		I'm not sure what you mean by "is not standard". First of all, we do not guarantee that this is an array, or even numbers.
The idea is (for now) that this is the "text to show", and that if it has newlines, you should render it with newlines! These are 5 TOTP
codes, and the idea is that the POS staff should match any single one of them. So I don't see why comma vs \n would be any better, or more "standard". My goal was to give it to you in exactly the format that you could just directly give to a rendering engine.

Oh, and you should NOT render them in one long line, that's not the intended format here. The idea was to show one code per line on 3-5 lines.
(0020147)
sebasjm   
2023-04-24 20:48   
(Last edited: 2023-04-24 22:52) 		> Oh, and you should NOT render them in one long line, that's not the intended format here. The idea was to show one code per line on 3-5 lines.

That's how the render engine is showing it, I will add a < pre > so the browser will render the \n

> I'm not sure what you mean by "is not standard"
For clarification: I meant a standard way of showing a list of numbers, people can understand a comma separated value and it will show exactly the same way everywhere.

\n may not be rendered in the same way in html or in a cli using linux or windows.
(0020150)
sebasjm   
2023-04-24 23:00    		2f8de9ea86cc1170b45e13fae6f0a66c7c4fd038 added

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6723 [Taler] libeufin-nexus minor have not tried 2021-01-26 14:51 2023-04-24 22:41
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: unify responses format styles
Description: Right now Nexus uses *4* different flavors to respond:

1) JSON for exceptions.
2) Plain text for the fallback route.
3) a empty JSON for *some* successful requests.
4) plain text for some other successful requests.

Those should be unified under two JSONs formats: one for errors, and one for 200 OK responses.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020148)
MS   
2023-04-24 22:40   
(Last edited: 2023-04-24 22:41) 		libeufin-keyrotation now breaks because of the format Nexus responds to "/fetch-transactions". The failing check is now commented out (see FIXME in the source file), and should be enabled after this bug gets fixed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6558 [Taler] wallet-core feature have not tried 2020-09-03 12:34 2023-04-24 21:41
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: transaction item for "lost coins due to expiration" needed
Description: In some cases, the auto-refresh comes to late and the wallet loses coins. The wallet has to show an appropriate item in the transactions list for that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016824)
Florian Dold   
2020-09-03 17:27    		According to the discussion in 0006561, we also need to make sure that coins can be "revived" from this state when they were marked as expired because of a wrong system time setting.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7817 [Taler] exchange minor always 2023-04-23 23:55 2023-04-24 21:23
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: exchange twisted test skip
Description: ... due to a configuration issue. We should fix the configuration --- and not skip on configuration bugs.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7815 [Taler] exchange feature always 2023-04-23 22:21 2023-04-24 20:06
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: exchange should have API to give refunds for purses in peer-pull payments
Description: The refund should only be possible until the purse is filled completely. The refund is done for each deposited coin individually.

The attached diagram shows the state machine for peer-pull-debit transactions *with* refunds. The wallet for now does not support them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: transaction-pull-debit-states.png (109,494 bytes) 2023-04-23 22:21
https://bugs.gnunet.org/file_download.php?file_id=1369&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7745 [Taler] other minor always 2023-03-06 23:16 2023-04-24 19:38
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: pogen doesnt work with double quotes
Description: somehow it creates invalid format

see commit https://git.taler.net/wallet-core.git/commit/?id=f99e1522d1114eeda6bd7ff3aea91421699c783c

error was

Error: Command failed: msgmerge -o 'src/i18n/de.po' 'src/i18n/de.po' 'src/i18n/taler-merchant-backoffice.pot'
src/i18n/taler-merchant-backoffice.pot:1986: missing 'msgstr' section
src/i18n/taler-merchant-backoffice.pot:1986:29: syntax error
src/i18n/taler-merchant-backoffice.pot:1986: keyword "$s" unknown
src/i18n/taler-merchant-backoffice.pot:2462: missing 'msgstr' section
src/i18n/taler-merchant-backoffice.pot:2462:36: syntax error
src/i18n/taler-merchant-backoffice.pot:2462: keyword "$s" unknown
msgmerge: found 6 fatal errors

    at checkExecSyncError (node:child_process:885:11)
    at Object.execSync (node:child_process:957:15)
    at Object.main (/home/sebasjm/Work/taler/taler-docker/development/base/wallet.git/packages/pogen/lib/pogen.js:35:31)
    at Object.<anonymous> (/home/sebasjm/Work/taler/taler-docker/development/base/wallet.git/packages/pogen/bin/pogen:2:28)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
  status: 1,


example of translation

#: src/paths/admin/list/index.tsx:89
#, c-format
msgid "Instance \\"%1$s\\" (ID: %2$s) has been deleted"
msgstr ""
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020094)
Florian Dold   
2023-04-14 16:06    		Should be fixed in f18305776167a3838245fd7d, please check!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7804 [Taler] deployment and operations trivial always 2023-04-14 10:46 2023-04-24 13:42
Reporter: hbarnard Platform:  
Assigned To: javier.sepulveda OS:  
Priority: low OS Version:  
Status: resolved Product Version: 0.9.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Suggested tweaks to main.sh
Description: 1. Warn people to set up DNS before proceeding otherwise the pings will fail. Probably both in the README and the script:

Set up Domain names first!
=========================

Assuming a main domain at netzbon.ch (i.e. "netzbon.ch" will be given as the
value for the domain during configuration), this setup expects the following
subdomains to be reachable:

A netzbon.ch
CNAME exchange.netzbon.ch
CNAME bank.netzbon.ch
CNAME backend.netzbon.ch (merchants frontends need this)

etc.

2. I sometimes use a dollar symbol in passwords, this makes main.sh fail, presumably because of bash. Solution is remove config file and start again. Incidentally that password is in clear in the generated config? Need something a bit better there?

These are trivial suggestions and the whole process works well now.
Tags:
Steps To Reproduce: Run ./main.sh
Additional Information:
Attached Files:
Notes
(0020140)
javier.sepulveda   
2023-04-24 13:42    		Set up Domain names first! - Added to README file
Dollar symbol in passwords - DONE in main.sh
Web UI bank password field, removed character restrictions.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7818 [Taler] wallet-core feature always 2023-04-24 07:49 2023-04-24 07:49
Reporter: MarcS Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version: post-1.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: fractionalBaseDigits of currencies
Description: Most currencies in the world have two digits after the decimal point/comma - but some have three (most arabian countries: Bahraini Dinar, Iraqi Dinar, Jordanian Dinar, Kuwaiti Dinar, Libyan Dinar, Rial Omani, Tunisian Dinar) and some have none (Indonesian Rupiah, Japanese Yen, South-Korean Won, Vietnamese New Dong, Cape Verdi Escudo, Paraguay Guarani, and a few african and caribbean countries).

When querying for exchanges, the data returned should not only tell the name of the currency:
    var exchangeBaseUrl: String
    var currency: String?
but also the fractionalBaseDigits:
    var fractionalBaseDigits: UInt?

There are 3 possible wallet-core calls where that information could be returned:
1) ListExchangesOp
2) GetExchangeDetailedInfoOp
3) ListCurrenciesOp

Sebastian wrote about using denominations to find out what amount might be possible to send, but fractionalBaseDigits are needed to display amounts correctly in balances and transaction views, especially whole numbers which might still need to be shown with decimal delimiter and fractional digits (.00, .000, ...).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7510 [Taler] deployment and operations major have not tried 2022-12-06 21:43 2023-04-23 23:50
Reporter: MS Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: buildmaster-builder NOT automatically reloading the Buildbot master configuration.
Description: To be fixed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020139)
Christian Grothoff   
2023-04-23 23:50    		Eh, this used to work just fine, with a buildslave kicking the buildmaster on master configuration changes -- unless the master configuration had a syntax error. MS: care to elaborate what you changed and what didn't work?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7306 [Taler] wallet-core feature have not tried 2022-08-23 19:19 2023-04-23 23:49
Reporter: grote Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Add number of decimal places to transaction list response
Description: Could be added here to `TransactionsResponse`: https://docs.taler.net/taler-wallet.html#transactions

Maybe there's other places to add this to as well?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019087)
Florian Dold   
2022-09-05 13:59    		I'm not sure if the transaction list is the right place to put this information. The information is per-currency, so it might make sense to have some general "getCurrencyInfo" request to wallet-core that the UI requests at startup. Would that help?

But additionally, do we ever *not* want to show all digits of an amount? It is already limited by the maximum number of decimal places of the amount data type in Taler.
(0019089)
grote   
2022-09-05 14:24    		Do you suggest to just always show the maximum number of decimal places? Would work for me.

Is this already part of the amount data type in the wallet API?
(0019091)
Florian Dold   
2022-09-05 16:23    		Amounts in Taler are limited to 8 decimal places [1].

Do you think we need some info for the *minimum* number of decimal places to display? Something like "10.00 EUR"?

[1] https://docs.taler.net/core/api-common.html#amounts
(0019093)
grote   
2022-09-05 16:27    		If we always want to show a minimum number of decimal places, then yeah I'd like to get that info from wallet core wherever I need it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7116 [Taler] libeufin-nexus feature have not tried 2021-11-30 18:48 2023-04-23 23:46
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: payment bouncing fee should be configurable
Description: The Taler facade bounces malformed incoming payments with the same amount that was paid by the debtor. Instead it should deduct a bounce fee, and this one should be specified in the configuration.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7683 [Taler] wallet-core minor have not tried 2023-02-12 20:56 2023-04-23 23:43
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: remove deprecated auditor/exchange trust management
Description: ... in favor of new currency configuration
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7795 [Taler] libeufin-sandbox minor have not tried 2023-04-07 15:59 2023-04-23 23:38
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: STDOUT not showing.
Description: Redirecting both STDOUT and STDERR to a file doesn't show STDOUT.
Observed in Sandbox when using Exposed's StdOutSqlLogger.
Tags:
Steps To Reproduce:
Additional Information: Information loss is very unlikely, because logging goes to STDERR.
Attached Files:
Notes
(0020138)
Florian Dold   
2023-04-23 23:38    		Can you clarify this a bit?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7600 [Taler] libeufin (general) minor have not tried 2023-01-18 23:11 2023-04-23 23:37
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Consider reducing 'util' file number.
Description: The Util package grew with >20 files, according to which feature the
function(s) in one file offer(s). However, some function may ambiguously
be appropriate to more than one file, resulting in this fine grained division
not being helpful (and therefore only creating more scaffolding).

On top of that, the files aren't placed under a path that matches their
package definition, with the IDE constantly warning about this.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020137)
Florian Dold   
2023-04-23 23:37    		Is this still relevant?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7771 [Taler] libeufin (general) trivial have not tried 2023-03-23 12:52 2023-04-23 23:36
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Manage missing testing dependencies.
Description: Instead of failing when 'jq', Python 'requests', or 'sqlite3' are missing, tests should either
install them or inform the user about such missing dependencies.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5954 [Taler] libeufin (general) minor have not tried 2019-10-29 18:00 2023-04-23 23:32
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: look for or implement better alternative to JAXB
Description: JAXB doesn't work well with kotlin, but it also is pretty bad in general.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6259 [Taler] libeufin-nexus minor have not tried 2020-05-24 13:58 2023-04-23 23:32
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: error log in database
Description: LibEuFin should collect bank-technical errors in a database, and the UI should be able to render them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6556 [Taler] wallet-core tweak have not tried 2020-09-03 11:41 2023-04-23 23:31
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: have integration tests that mutate signatures to check that implementation checks all relevant signatures
Description: It's pretty easy to forget checking signatures in the wallet. We should have test cases that actually trigger signature verification failures.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7118 [Taler] other minor have not tried 2021-12-01 11:25 2023-04-23 23:30
Reporter: ms-mantis Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: merchant demos doesn't install all dependencies
Description: Namely, 'babel' and 'uwsgi' should be included as dependencies.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7582 [Taler] wallet-core feature have not tried 2023-01-13 02:27 2023-04-23 23:30
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement user-initiated p2p kyc / KYCed reserve management
Description: This might include the ability for users to initiate opening a KYC account (=KYCed reserve).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6804 [Taler] wallet-core feature have not tried 2021-03-11 16:10 2023-04-23 23:19
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: implement wallet test case for a multi-exchange payment
Description: The test case should withdraw from two exchanges and then pay for an order with a merchant that accepts both exchanges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7792 [Taler] exchange minor always 2023-04-05 18:20 2023-04-23 23:17
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: exchange responds with 500 to non-idempotent deposit
Description: When the wallet handles a deposit request that is equivalent to a previous one *except* for the amount, it returns status 500

This issue is present in master and in the released 0.9.2.
Tags:
Steps To Reproduce: $ taler-harness run-integrationtests exchange-deposit
Additional Information:   "requestUrl": "http://localhost:8081/coins/EAEC4V41CBQEVMTXR2B3BT5J0P77Y36NF7NW6XXN1TT0HHKPKVD0/deposit",
  "requestMethod": "POST",
  "httpStatusCode": 500,
  "errorResponse": {
    "code": 52,
    "hint": "The service failed to store information in its database.",
    "detail": "deposit"
  }
Attached Files:
Notes
(0020038)
Christian Grothoff   
2023-04-08 08:30    		Fixed in 36b2cbb4..cbabddf0 -- now returning a 409. The test still fails though, as you don't like the 409. But I think 409 is correct.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7814 [Taler] wallet-core minor have not tried 2023-04-23 20:47 2023-04-23 22:18
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: DD37: handle funky deposit txn case where aborting(refresh) might still need to do a refund
Description: If the refund request fails because the deposit request did not arrive *yet*, the refresh will *also* fail if the refresh arrives after the deposit request is finally handled.

To resolve this, refresh groups should learn the ability to try to a refund request once if the refresh on that particular coin fails.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4379 [Taler] wallet-core feature have not tried 2016-04-06 23:34 2023-04-23 20:21
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: error handling: exportable proof of e.g. double spending for auditor
Description: When payments fail and it is not a transient error, the wallet needs to provide the user with a way to extract the information regarding the claim the merchant made.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011423)
Florian Dold   
2016-11-03 20:21    		Not clear how this should look UI-wise, and I'm also not sure what's the best way to test this.

For the UI: We could open an in-extension tab that shows a message and a way to save the proof. Should it show up anywhere in the wallet popup, or just in the history?

Does this error page provide the user with the option to refresh coins that are not double-spended? Does this happen automatically (probably makes most sense)?

Should we have some informal spec that documents these cases before we start implementing?
(0011451)
Florian Dold   
2016-11-08 15:01    		Moved to 0.3 since we should have at least the facilities to trigger the various error paths (wallet really double-spended / merchant falsely claimed double spending).
(0011452)
Christian Grothoff   
2016-11-08 16:11    		Eh, that would be 0.5. That's when the error path triggering is on the roadmap.
(0011453)
Christian Grothoff   
2016-11-08 16:11    		Wrong again. 0.6.
(0011945)
Christian Grothoff   
2017-03-19 00:06    		In terms of specification, I basically expect that for each possible proof we export a JSON file with:

* always top-level: some numeric information about the type of proof
* always top-level: some human-readable information about the type of proof

Then, type-specific key-value pairs where:

key: some string describing the value
value: some json object (or array) with structured proof data, i.e. public keys, amounts, signatures, hashes, etc., depending on what the proof is about.


We should also have some command-line tool to verify proofs, i.e. I would run:

taler-check-proof FILENAME.json

and it would:
1) open file, parse the json (make sure JSON was valid)
2) look at the type, use it to load some plugin to verify the proof and
3) output the result of the check ("valid" / "invalid")

We need to have an additional options "--extract-contract" that could be used to extract the JSON contract from the overall proof (if present), so that one can use the (generic) contract renderer (which we need to have a standalone-version of) to show the contract. I think that's about it for the overall design, the individual JSON field members for each proof should probably just be speced as the export-logic and proof-validation plugin are implemented.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6258 [Taler] libeufin-nexus minor have not tried 2020-05-24 13:55 2023-04-23 19:38
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: parse HAC for better reliability
Description: With some operations, we will only know by looking at HAC whether they succeeded or failed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7587 [Taler] libeufin (general) minor have not tried 2023-01-14 10:04 2023-04-23 19:36
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: General pass to potentially switch "200 OK" to "204 No Content".
Description: The Taler Wire Gateway API got already changed here: 0676e25980a8b..

This report contiues: 0007301.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020099)
Florian Dold   
2023-04-17 11:04    		What's the rationale for this? It's clearly not a performance issue, why are we complicating the API with different types of responses (empty list vs. 204) to indicate zero transactions?
(0020133)
Florian Dold   
2023-04-23 19:36    		Discussed with Christian: The idea is that 204 indicates that there are no new transactions *and the client should go into long-polling*, while we expect 200 only when transactions are present.

While I still think that this is an over-optimization, we should still consistently apply what we've agreed on.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7812 [Taler] libeufin-sandbox minor have not tried 2023-04-22 18:19 2023-04-22 18:19
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: demobank account registration sometimes fails because IBAN already exists
Description: It looks like the sandbox just generates a random IBAN but then gives up if it's already used. Instead, it must try harder to find a fresh one!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7276 [Taler] exchange feature N/A 2022-07-05 13:15 2023-04-22 15:17
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: improve wirewatch performance via multi-value insert
Description: Right now, we do a separate INSERT per wire transfer, which needs one RTT per request to the database.

We could likely significantly improve wirewatch performance if we batched these requests, providing multiple tuples of values for a single INSERT.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020120)
Christian Grothoff   
2023-04-18 20:44    		Code exists in reserves_in_insert, but needs urgent correctness review!
(0020125)
Christian Grothoff   
2023-04-22 15:17    		Bugs fixed (including unrelated ones in fakebank and wirewatch), performance on my desktop due to batching went up from 33k to 43k TPS when going from batch size 1 to 8.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7738 [Taler] libeufin-nexus minor have not tried 2023-03-04 16:44 2023-04-21 22:03
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Creating a facade with a unavailable name responds 500.
Description: That should be changed to 409, or even 200 if the API is idempotent.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020124)
MS   
2023-04-21 21:41   
(Last edited: 2023-04-21 22:03) 		Fixed here by making the facade creation idempotent: bb96fd4f635cd9b760363acc7aacb9f7d890cf89.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7581 [Taler] wallet-core feature have not tried 2023-01-13 02:26 2023-04-21 14:50
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement soft KYC for balance limits
Description: The wallet should request a KYC check when the balance exceeds a threshold
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7806 [Taler] wallet (Android App) minor have not tried 2023-04-17 17:44 2023-04-21 00:02
Reporter: hbarnard Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 0.9.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Lots of 'complaints' when compiling wallet
Description: I'm doing some wallet compiles, because I may need a modified version. Maybe this is something I'm not setting?
Lots of deprecation warnings during the compile, but I seem to get an apk, that I haven't tried yet! See below:


hbarnard@hbarnard-OptiPlex-9020:~/projects/taler/taler-android$ ./gradlew :wallet:build
Configuration on demand is an incubating feature.
warn: removing resource net.taler.wallet.nightly:string/backup_last without required default value.
warn: removing resource net.taler.wallet.nightly:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet.nightly:string/transactions_detail_title_balance without required default value.


> Task :wallet:compileNightlyDebugKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java

> Task :wallet:packageFdroidRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.
warn: removing resource net.taler.wallet:string/backup_last without required default value.
warn: removing resource net.taler.wallet:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet:string/transactions_detail_title_balance without required default value.

warn: removing resource net.taler.wallet.nightly:string/backup_last without required default value.
warn: removing resource net.taler.wallet.nightly:string/nav_settings_backup without required default value.
warn: removing resource net.taler.wallet.nightly:string/transactions_detail_title_balance without required default value.


> Task :wallet:compileGoogleReleaseKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/Utils.kt:25:25 'WifiConfiguration' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/accounts/AccountManager.kt:33:27 Parameter 'knownBankAccounts' is never used, could be renamed to _
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/payment/ProductImageFragment.kt:50:41 'getParcelable(String?): T?' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:58:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:99:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:106:15 'onCreateOptionsMenu(Menu, MenuInflater): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:39:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:44:15 'onActivityCreated(Bundle?): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:62:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionsFragment.kt:66:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java

> Task :wallet:compileNightlyReleaseKotlin
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/MainActivity.kt:147:20 'onBackPressed(): Unit' is deprecated. Overrides deprecated member in 'androidx.core.app.ComponentActivity'. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/Utils.kt:25:25 'WifiConfiguration' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/accounts/AccountManager.kt:33:27 Parameter 'knownBankAccounts' is never used, could be renamed to _
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/payment/ProductImageFragment.kt:50:41 'getParcelable(String?): T?' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:58:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:99:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/pending/PendingOperationsFragment.kt:106:15 'onCreateOptionsMenu(Menu, MenuInflater): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:39:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:44:15 'onActivityCreated(Bundle?): Unit' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionDetailFragment.kt:62:27 'onOptionsItemSelected(MenuItem): Boolean' is deprecated. Deprecated in Java
w: file:///home/hbarnard/projects/taler/taler-android/wallet/src/main/java/net/taler/wallet/transactions/TransactionsFragment.kt:66:9 'setHasOptionsMenu(Boolean): Unit' is deprecated. Deprecated in Java

> Task :wallet:packageGoogleRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageNightlyRelease
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageFdroidDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageGoogleDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:packageNightlyDebug
PackagingOptions.jniLibs.useLegacyPackaging should be set to true because android:extractNativeLibs is set to "true" in AndroidManifest.xml.

> Task :wallet:lintReportFdroidDebug
Wrote HTML report to file:///home/hbarnard/projects/taler/taler-android/wallet/build/reports/lint-results-fdroidDebug.html

BUILD SUCCESSFUL in 6m 9s
Tags:
Steps To Reproduce: ./gradlew :wallet:build
Additional Information:
Attached Files:
Notes
(0020112)
grote   
2023-04-18 17:56    		None of those are critical. Deprecations happen all the time in Android and we'll take care of them eventually. Outdated strings get fixed when Weblate is pushing new translations.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7704 [Taler] wallet-core feature have not tried 2023-02-17 16:17 2023-04-19 17:43
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: implement feature flags for wallet core
Description: UI dev mode should allow the user to set flags on and off
UI should save a map Record<string,boolean> with name of the flag and status (on,off)
By default all flags should be considered off
Wallet core should take this in the initialization
It is not expected to change the flags in runtime (restart needed)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020122)
sebasjm   
2023-04-19 17:43    		d483a3f5574355ed9c43eb6ddea59e5734323cf0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7801 [Taler] deployment and operations minor have not tried 2023-04-12 17:33 2023-04-19 13:22
Reporter: hbarnard Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9.1  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Deployment fails at last step
Description: Running deployment/netzbon/main.sh, finally it fails with:
`
TALER: Launching exchange
Created symlink /etc/systemd/system/multi-user.target.wants/taler-exchange.target → /lib/systemd/system/taler-exchange.target.
TALER: Waiting for exchange HTTP service (/config)...
TALER: DONE
TALER: Waiting for exchange management keys (this may take a while)...
TALER: DONE
TALER: Offline interaction...
2023-04-12T15:23:02.918130+0000 taler-exchange-offline-28437 WARNING Did NOT detect response `<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.22.0 (Ubuntu)</center>
</body>
</html>
' as JSON
2023-04-12T15:23:02.918277+0000 taler-exchange-offline-28437 ERROR Unexpected response code 404/10 for exchange management get keys
2023-04-12T15:23:02.918295+0000 taler-exchange-offline-28437 ERROR Failed to download keys from `http://exchange.bank-in-a-box.net/': The response we got from the server was not even in JSON format. (HTTP status: 404/10)
`
Maybe because I decided not to use https?
Tags:
Steps To Reproduce: 1. Clone deployment onto an Ubuntu 22.10 server
2. Run ./main.sh
3. Say no to TLS question
Additional Information:
Attached Files:
Notes
(0020082)
Christian Grothoff   
2023-04-12 21:46    		Florian, I remember you mentioning something about a missing nginx symlink for sites-available that might explain this. If this could be it, which Git version was this fixed in?
(0020083)
Christian Grothoff   
2023-04-12 21:46    		@hbarnard : We did quite a few changes even *today* to the netzbon script. Could you please report the exact Git version you used?
(0020084)
hbarnard   
2023-04-13 12:23    		Just wiped and recreated an Ubuntu 22.10 VM, apt update etc. git clone deployment repo from 13/4 and run the install, it looks 'good', so please close this one and thanks:

TALER: Exchange setup finished
TALER: Launching taler-merchant-httpd
Created symlink /etc/systemd/system/multi-user.target.wants/taler-merchant-httpd.service → /lib/systemd/system/taler-merchant-httpd.service.
TALER: Congratulations, you have successfully installed GNU Taler
TALER: Your bank is at https://bank.bank-in-a-box.net/
TALER: A merchant is at https://backend.bank-in-a-box.net/
TALER: You should set credentials for the merchant soon.
(0020085)
Florian Dold   
2023-04-13 12:48    		Great, marking this as resolved.
(0020091)
Christian Grothoff   
2023-04-13 20:22   
(Last edited: 2023-04-13 20:23) 		Maybe we should extend the netzbon script to first *test* if the distro is the right one? Javier: can you write a test for this and add it to the top of the main script?
(0020121)
javier.sepulveda   
2023-04-19 13:22    		dev/javier-sepulveda/netzbon-tls
netzbon/check-distro.sh
Tested the whole branch from scratch (new instance Ubuntu 22.10) and works okay.
The new files {check-distro,check-services}.sh and config_journald.sh, work okay.
We can now manually add --new supported distros to the file "distros-supported.txt"
Pending merge by Florian.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7794 [Taler] exchange minor have not tried 2023-04-06 17:46 2023-04-18 23:11
Reporter: MS Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: Library not found despite correct LD_LIBRARY_PATH
Description: The following logs shows the execution environment and how the Postgres
database plugin is NOT being found by the taler-exchange-dbinit program.

ms@notebook:~$ ls $HOME/.local/lib/taler/ | grep exchangedb_postgres
libtaler_plugin_exchangedb_postgres.la
libtaler_plugin_exchangedb_postgres.so
ms@notebook:~$ export LD_LIBRARY_PATH=$HOME/.local/lib/taler
ms@notebook:~$ echo $LD_LIBRARY_PATH
/home/ms/.local/lib/taler
ms@notebook:~$ taler-exchange-dbinit
2023-04-06T17:45:15.673649+0200 util-plugin-176000 ERROR `lt_dlopenext' failed for library `libtaler_plugin_exchangedb_postgres' with error: file not found
Failed to initialize database plugin.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020034)
Christian Grothoff   
2023-04-06 22:28    		LD_LIBRARY_PATH is irrelevant for plugins. Did you set TALER_PREFIX correctly to $HOME/.local/? In fact, is you main binary linked correctly? Do you have more than one libtalerutil.so on your disk? Is the plugin actually installed, or was libgnunetpq outdated/not found during configure? Are you using the latest exchange with Joseph's linker issue fixed?
(0020101)
Florian Dold   
2023-04-17 11:40    		I also had this problem, but didn't see it recently. Likely that it was due to the issue that Joseph has now fixed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6664 [Taler] documentation text have not tried 2020-12-08 15:59 2023-04-18 20:06
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: clarify normalization algorithm of contract terms and backup blob
Description: We currently don't specify the algorithm, but just refer to the jansson implementation.

We should have a look at https://tools.ietf.org/html/rfc8785 for this.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020119)
Christian Grothoff   
2023-04-18 20:06    		DD 018 already clearly refers to RFC 8785, so I am not sure what else is left to do here.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7597 [Taler] exchange trivial have not tried 2023-01-17 17:01 2023-04-18 20:01
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: none OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: exchange triggers MHD deprecation warning
Description: taler_error_codes.c:177:13: warning: Value MHD_HTTP_PAYLOAD_TOO_LARGE is deprecated,
  177 | .http_code = MHD_HTTP_PAYLOAD_TOO_LARGE
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  CC yna.lo
taler_error_codes.c:2277:13: warning: Value MHD_HTTP_PAYLOAD_TOO_LARGE is deprecated,
 2277 | .http_code = MHD_HTTP_PAYLOAD_TOO_LARGE
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
taler_error_codes.c:2283:13: warning: Value MHD_HTTP_PAYLOAD_TOO_LARGE is deprecated,
 2283 | .http_code = MHD_HTTP_PAYLOAD_TOO_LARGE
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
taler_error_codes.c:2745:13: warning: Value MHD_HTTP_PAYLOAD_TOO_LARGE is deprecated,
 2745 | .http_code = MHD_HTTP_PAYLOAD_TOO_LARGE
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019692)
Christian Grothoff   
2023-01-17 19:44    		Yes, that's well-known and would be trivial to fix --- but we'd then require more recent versions of MHD to be deployed at end-users, so I'm holding off intentionally until recent versions of MHD are really universally available.
(0020118)
Christian Grothoff   
2023-04-18 20:00    		Fixed in latest GANA by updating HTTP status code registry to current IANA values.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7585 [Taler] mechant backend minor have not tried 2023-01-13 13:11 2023-04-18 19:36
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: merchant build shows compiler warning
Description: plugin_merchantdb_postgres.c: In function ‘lookup_accounts_cb’:
plugin_merchantdb_postgres.c:531:3: warning: ‘<unknown>’ may be used uninitialized [-Wmaybe-uninitialized]
  531 | call_with_accounts (lic,
      | ^~~~~~~~~~~~~~~~~~~~~~~~
  532 | num_results,
      | ~~~~~~~~~~~~
  533 | accounts);
      | ~~~~~~~~~
plugin_merchantdb_postgres.c:445:1: note: by argument 3 of type ‘const struct TALER_MERCHANTDB_AccountDetails[]’ to ‘call_with_accounts’ declared here
  445 | call_with_accounts (struct LookupInstancesContext *lic,
      | ^~~~~~~~~~~~~~~~~~
  CCLD libtaler_plugin_merchantdb_postgres.la
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019662)
Christian Grothoff   
2023-01-13 17:00    		Yeah, I checked, couldn't find at all why gcc thinks there is an issue with that code. Didn't want to just brutally memset() the warning away, so it stays "for now".
(0019663)
Christian Grothoff   
2023-01-13 18:50    		Which platform do you get this? Just tried on Debian with gcc-10 and gcc-12 and no warning even with -Wextra.
(0019668)
Florian Dold   
2023-01-15 14:59    		I get this both on my old Arch Linux installation and on Fedora on my Workstation:

[fdold-work@fedora merchant]$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(0019675)
Christian Grothoff   
2023-01-15 22:45    		Update: affects gcc-11 and gcc-12, on -O2 with -Wall. Jose is on it as it looks like a gcc bug.
(0020117)
Christian Grothoff   
2023-04-18 19:36    		ccfd643c..d940480c adds a work-around using memset(). Just to make the warning disappear, as otherwise we'll surely hear again of it, even though it is a gcc bug.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7373 [Taler] documentation text have not tried 2022-09-27 10:45 2023-04-18 18:56
Reporter: ttn Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: add a "project overview" section in the developer's manual
Description: The core software components (exchange, merchant, libeufin, various SPAs)
need to be described in an overview that relates the components.

CG suggests adding such an overview to the developer manual.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020116)
Christian Grothoff   
2023-04-18 18:56    		Fixed in 159339b..88fc9a2.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6949 [Taler] documentation text have not tried 2021-07-23 13:36 2023-04-18 18:38
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: inventory use-cases should be properly described in merchant backend manual
Description: The manual should properly describe the inventory management use-case (limited stocks), and how to use product locks (when customer is building shopping cart), as well as order locks (once shopping cart is "complete") and the auto-unlocking (see 0006937).
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018096)
ttn   
2021-08-11 05:34    		See https://git.taler.net/docs.git/commit/?id=108101d5c13e2e1e1e12290c29a53969ce715511
(particularly, the FIXME).
(0018098)
Christian Grothoff   
2021-08-11 09:17    		FIXME: I would say that the product locks expire after a given time if they are not transferred into an order lock, and the order locks expire when the offer to the customer expires without payment. There is not really any 'event' other than time that would remove the locks.
(0018099)
ttn   
2021-08-11 11:52    		Some recent commits, ending w/ "simplify":
2789962 2021-08-11 simplify; swap out old FIXME for new FIXME
f357f26 2021-08-11 link to ‘Reverse proxy configuration’
eaab49e 2021-08-11 replace hyphen between ‘reverse’ and ‘proxy’ with space
552ceeb 2021-08-11 add a pair of identical FIXMEs: "What about 40[34] swizzling? (0006944)"
Direct link: https://git.taler.net/docs.git/log/

Anyway, the new FIXME should be the last one in this file.

On to "how to use locks" documentation....
(0020115)
Christian Grothoff   
2023-04-18 18:37    		Last fixme addressed in 92103b6..159339b.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7013 [Taler] documentation text have not tried 2021-09-04 20:25 2023-04-18 18:32
Reporter: ttn Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: explain and index all $-substitutable variables (e.g., DATADIR)
Description: The explanation should include origins (e.g., DATADIR comes from Autotools),
common usage, and placement.

https://mail.gnu.org/archive/html/taler/2021-09/msg00001.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018388)
Christian Grothoff   
2021-09-04 22:36    		Well, everything that can be $-substituted must be in $PATHS. Some variables there are in the default-config, others are created at runtime by libgnunetutil based on its heuristics to guess where the various autotools prefixes ended up.
(0018391)
Florian Dold   
2021-09-11 12:38    		This is not just a documentation issue, but the taler-util TS package also needs to support those variables.
(0020114)
Christian Grothoff   
2023-04-18 18:32    		Documented in 52c8fbc..92103b6. Not sure if something still needs to be done about the TS package, hence assigning to Florian.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7455 [Taler] documentation text always 2022-11-14 12:56 2023-04-18 18:17
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: 0.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: merchant backend tutorial is completely outdated on tipping
Description: Ancient endpoints, doesn't work at all as described right now. Needs a thorough (!) revision based on the current core API.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020113)
Christian Grothoff   
2023-04-18 18:17    		Fixed in ffb0b26..52c8fbc

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7516 [Taler] deployment and operations minor sometimes 2022-12-10 15:36 2023-04-18 16:41
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: TypeScript test harness fails at preparing the database.
Description: The following error happens when running the complete suite (command below), marking the test case as failed.
It MAY be needed to run the suite more than once.

Ideally, the harness should handle the problem, or at least mark the test as skipped.

$ taler-wallet-cli testing run-integrationtests
Tags:
Steps To Reproduce:
Additional Information: running test test-withdrawal-manual in worker process
running test test-withdrawal-manual
2022-12-10T14:17:19.331Z harness.ts INFO running test in directory [
  "/tmp/taler-integrationtests-Li7zK6/test-withdrawal-manual"
]
FATAL: test failed with exception Error: Command failed: createdb "taler-integrationtest"
createdb: error: database creation failed: ERROR: database "taler-integrationtest" already exists

    at ChildProcess.exithandler (node:child_process:398:12)
    at ChildProcess.emit (node:events:527:28)
    at maybeClose (node:internal/child_process:1092:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5) {
  code: 1,
  killed: false,
  signal: null,
  cmd: 'createdb "taler-integrationtest"',
  stdout: '',
  stderr: 'createdb: error: database creation failed: ERROR: database "taler-integrationtest" already exists\n'
}
2022-12-10T14:17:24.395Z harness.ts INFO shutting down
test test-withdrawal-manual finished in worker
Attached Files:
Notes
(0019623)
Florian Dold   
2023-01-10 13:10    		I've added some code to the harness to write the output of "dropdb" and "createdb" to log files.

Please try again and look at the logs: /tmp/taler-integrationtests-$ID/$TESTNAME/{dropdb,createdb}-stderr.log

This might be a permissions issue on your side.
(0020105)
MS   
2023-04-18 11:09   
(Last edited: 2023-04-18 11:12) 		Yes, the log files reflect your last change.

And no, in contrast with this bug report, Florian points out that integration
tests should fail even when a part not belonging to Taler isn't reliable. That
however isn't already the case for the exchange codebase, that instead skips
integration tests when the DB, for example, isn't properly configured.
(0020106)
Christian Grothoff   
2023-04-18 15:06    		That's different. If the OS is not configured correctly (dependencies missing, database down), then I think 'skip' is correct. But if say there is a bug in libgnunetutil, then the test should fail.
(0020110)
MS   
2023-04-18 16:38    		The TypeScript harness was observed to fail with a database down, so if things stay this way, wallet-core.git and exchange.git handle this scenario inconsistently.
(0020111)
Christian Grothoff   
2023-04-18 16:41    		I think it should fail --- with a return code of 77 ;-).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7333 [Taler] wallet-core feature have not tried 2022-09-07 21:46 2023-04-18 15:52
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: introduce minimalistic JS API for wallet that can be used by SPAs
Description: With an approach similar to MetaMask, we can provide a simple talerWallet.handleUri API into the browser that can be used by SPAs to handle URIs without a navigation.

Additionally, the wallet is currently over-eager to open taler:// URIs. We should remove this behavior once the SPA API is available. Otherwise, *every* taler://... link on any page would trigger the wallet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020087)
sebasjm   
2023-04-13 18:19    		webex now injects a script that add the taler support API

this is an example of can be done programmatically

window.location = window.taler.api.convertURIToWebExtensionPath("taler://pay/asd")

it should not be needed, since after the script run every link with href.value that start with taler should be intercepted
also, the scripts observes DOM mutation for new links that appears after initial load (like in the spa)
(0020088)
sebasjm   
2023-04-13 18:23    		I have intentionally commented out this 2 lines

https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/taler-wallet-interaction-support.ts#n50
https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/taler-wallet-interaction-loader.ts#n55

that check the presences of the taler support meta tag, this allows testing without updating bank.demo.taler.net and the merchant payments pages.
This should be un-commented after merchant and bank is updated
(0020109)
sebasjm   
2023-04-18 15:52    		feedback was given, final issues addressed.
commit b34f3568e8c9dde73f11583a6b46ef1509990397

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7539 [Taler] wallet (WebExtension) minor always 2022-12-25 22:51 2023-04-18 15:50
Reporter: davidak Platform:  
Assigned To: sebasjm OS:  
Priority: low OS Version:  
Status: resolved Product Version: 0.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Can't go back to bank when "Automatically open wallet based on page content" is enabled
Description: Demonstration: https://youtu.be/_MIJfEMa4Mg
Tags:
Steps To Reproduce: 1. Go to wallet settings and enable "Automatically open wallet based on page content"
2. Go to bank and withdraw money
3. Cancel withdraw, you get redirected to your walled
4. Go back to the bank

now you always get the withdraw screen and can never go to the bank. you can't cancel the withdraw
Additional Information: Workaround: disable "Automatically open wallet based on page content"

Wallet Core
0.9.0 673e7a417d043cd6b0644d2a7a52d1fdbc5345ee
Web Extension
0.9.0.35 673e7a417d043cd6b0644d2a7a52d1fdbc5345ee
Attached Files:
Notes
(0020018)
Florian Dold   
2023-04-04 19:32    		We should implement the taler:// URI handling from DD39. The "Automatically open wallet based on page content" should go away.
(0020107)
sebasjm   
2023-04-18 15:50    		fixed, now this feature is not present anymore.
wallet inject a script which will handle all the links to taler:// and will navigate to the wallet. back button should work as expected and should not trigger this issue
(0020108)
sebasjm   
2023-04-18 15:50    		b34f3568e8c9dde73f11583a6b46ef1509990397

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6381 [Taler] libeufin-nexus minor have not tried 2020-06-14 17:19 2023-04-17 13:18
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: implement and test transaction identification matching for INFO->PENDING->BOOKED transition
Description: Currently we don't support a transaction transitioning between these states.

In order to do this, a transaction should be marked with a foreign key column "supersededBy" that points to the newer "version" of the same transaction with a different status.

By default, the superseded transaction shouldn't be returned in the transactions list anymore. The superseded and current transaction must share some common transaction identifier.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020062)
MS   
2023-04-11 10:54    		If one transaction gets from PENDING to BOOKED (becoming therefore superseded),
then this bug suggests that such transaction shows up in the list only as long as is pending.

Then, once it gets superseded by the new booked status, it won't show anymore?

If yes, why would the booked status NOT be interesting?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7334 [Taler] wallet (Android App) tweak N/A 2022-09-08 20:20 2023-04-17 11:59
Reporter: Christian Grothoff Platform: i7  
Assigned To: grote OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: UX Study: user fails to identify QR button
Description: In the UX study today, one of the users had trouble to identify the QR button as the place to initiate interactions with QR codes.

We should discuss how we can make it easier to discover the button's functionality for first-time users.

Note: We had similar issues with the QR-Code button and URI-entry discoverability in the WebExtension.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Screenshot_20230411_114728.png (161,880 bytes) 2023-04-11 16:49
https://bugs.gnunet.org/file_download.php?file_id=1368&type=bug
png
Notes
(0019106)
Christian Grothoff   
2022-09-08 20:38    		One user suggested labeling the button "Payment" (which of course is not quite correct, as it can do more). I think "scan QR code" would be good, but maybe better to show a big hint (scan Taler QR codes to pay, withdraw, ...) as long as the balance is empty and we don't have much to show anyway?
(0020022)
Florian Dold   
2023-04-05 10:54    		One way to address this might also be what Marc suggested: Do one of these short intro slide shows (not sure what these are called by UI/UX people) that highlights the QR code button somehow.
(0020069)
grote   
2023-04-11 16:49    		Possible solution on Android to make the button more prominent.
(0020070)
Christian Grothoff   
2023-04-11 16:57    		Idea: change the text to be on 2 lines and say:

Tap: scan QR code
Hold: enter URI

That'd make the 'hold' feature more discoverable as well. Just an idea.
(0020071)
Florian Dold   
2023-04-11 17:02    		I think that's way too verbose and big (Christian's suggestion). I like grote's new label!

To make entering URIs more discoverable, we might want to do it like a lot of banking apps do it with IBANs: Detect when they're in the copy+paste buffer when opening the app and then showing some toast (or whatever this UI element is called) offering to handle it.
(0020081)
Christian Grothoff   
2023-04-12 16:44    		I think with Grote's new label, we can consider this one resolved.
(0020090)
grote   
2023-04-13 20:11    		resolved in https://git.taler.net/taler-android.git/commit/?id=d9985f0db0c8c603a6814b332328b43b97d1d367

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7788 [Taler] auditor major always 2023-03-31 20:32 2023-04-17 11:58
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: account access is not possible for non-circuit accounts
Description: In admin panel, all account are listed. If the account is not a circuit account the 404 is returned.
Then, the admin can't change password or access the view.

Maybe this account show not be listed? Do new a new endpoint that just returns circuit accounts?
Should admin access this account if registration is enabled?

I think that even if cashout is not possible we will want the admin to be able to reset the password or close then if the balance is empty so endpoint should work for both type of accounts

{
  "error" : {
    "type" : "util-error",
    "description" : "sebasjm not managed by the Circuit API."
  }
}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020002)
MS   
2023-04-01 19:54    		Agreed.

Non-circuit accounts should be listed and be subject to any admin operation
that doesn't involve cashing-out.
(0020036)
MS   
2023-04-07 17:15    		Addressed here: f2710520..101fa06f

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7782 [Taler] auditor crash sometimes 2023-03-29 20:05 2023-04-17 11:58
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: nexus was dead, found "sorry, too many clients already" in the logs
Description:     at org.jetbrains.exposed.sql.Transaction.exec(Transaction.kt:121)

    at org.jetbrains.exposed.sql.AbstractQuery.iterator(AbstractQuery.kt:65)

    at org.jetbrains.exposed.sql.IterableExKt$mapLazy$1.iterator(IterableEx.kt:129)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$2.invoke(Scheduling.kt:149)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$2.invoke(Scheduling.kt:108)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.inTopLevelTransaction$run(ThreadLocalTransactionManager.kt:173)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.access$inTopLevelTransaction$run(ThreadLocalTransactionManager.kt:1)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt$inTopLevelTransaction$1.invoke(ThreadLocalTransactionManager.kt:194)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.keepAndRestoreTransactionRefAfterRun(ThreadLocalTransactionManager.kt:202)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.inTopLevelTransaction(ThreadLocalTransactionManager.kt:193)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt$transaction$1.invoke(ThreadLocalTransactionManager.kt:151)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.keepAndRestoreTransactionRefAfterRun(ThreadLocalTransactionManager.kt:202)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction(ThreadLocalTransactionManager.kt:123)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction(ThreadLocalTransactionManager.kt:121)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction$default(ThreadLocalTransactionManager.kt:120)

    at tech.libeufin.nexus.SchedulingKt.startOperationScheduler(Scheduling.kt:108)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$1.invokeSuspend(Scheduling.kt)

    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)

    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)

    at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)

    at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)

    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

Caused by: org.postgresql.util.PSQLException: FATAL: sorry, too many clients already

    at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:693)

    at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:203)

    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:258)

    at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:54)

    at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:253)

    at org.postgresql.Driver.makeConnection(Driver.java:434)

    at org.postgresql.Driver.connect(Driver.java:291)

    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:681)

    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:229)

    at org.jetbrains.exposed.sql.Database$Companion$connect$10.invoke(Database.kt:160)

    at org.jetbrains.exposed.sql.Database$Companion$connect$10.invoke(Database.kt:160)

    at org.jetbrains.exposed.sql.Database$Companion$doConnect$3.invoke(Database.kt:112)

    at org.jetbrains.exposed.sql.Database$Companion$doConnect$3.invoke(Database.kt:111)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction$connectionLazy$1.invoke(ThreadLocalTransactionManager.kt:58)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction$connectionLazy$1.invoke(ThreadLocalTransactionManager.kt:57)

    at kotlin.UnsafeLazyImpl.getValue(Lazy.kt:81)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction.getConnection(ThreadLocalTransactionManager.kt:64)

    at org.jetbrains.exposed.sql.Transaction.getConnection(Transaction.kt)

    at org.jetbrains.exposed.sql.statements.Statement.prepared(Statement.kt:24)

    at org.jetbrains.exposed.sql.statements.Statement.executeIn$exposed_core(Statement.kt:47)

    ... 26 common frames omitted

17:16:26.469 [eventLoopGroupProxy-4-1] DEBUG tech.libeufin.nexus - LISTENing on domain LIBEUFIN_TALER_INCOMING for IBAN: DE210658 with timeout: 60000. Resulting channel name: XVD3K5HSN1KXP9YQG8SH29BTJNEWF4QYFB48EEKKW4B5VE38ZYW00

17:16:26.470 [DefaultDispatcher-worker-11] ERROR tech.libeufin.nexus - org.jetbrains.exposed.exceptions.ExposedSQLException: org.postgresql.util.PSQLException: FATAL: sorry, too many clients already

SQL: [Failed on expanding args for SELECT: org.jetbrains.exposed.sql.Query@4284b0bc]

    at org.jetbrains.exposed.sql.statements.Statement.executeIn$exposed_core(Statement.kt:49)

    at org.jetbrains.exposed.sql.Transaction.exec(Transaction.kt:135)

    at org.jetbrains.exposed.sql.Transaction.exec(Transaction.kt:121)

    at org.jetbrains.exposed.sql.AbstractQuery.iterator(AbstractQuery.kt:65)

    at org.jetbrains.exposed.sql.IterableExKt$mapLazy$1.iterator(IterableEx.kt:129)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$2.invoke(Scheduling.kt:149)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$2.invoke(Scheduling.kt:108)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.inTopLevelTransaction$run(ThreadLocalTransactionManager.kt:173)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.access$inTopLevelTransaction$run(ThreadLocalTransactionManager.kt:1)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt$inTopLevelTransaction$1.invoke(ThreadLocalTransactionManager.kt:194)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.keepAndRestoreTransactionRefAfterRun(ThreadLocalTransactionManager.kt:202)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.inTopLevelTransaction(ThreadLocalTransactionManager.kt:193)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt$transaction$1.invoke(ThreadLocalTransactionManager.kt:151)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.keepAndRestoreTransactionRefAfterRun(ThreadLocalTransactionManager.kt:202)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction(ThreadLocalTransactionManager.kt:123)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction(ThreadLocalTransactionManager.kt:121)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction$default(ThreadLocalTransactionManager.kt:120)

    at tech.libeufin.nexus.SchedulingKt.startOperationScheduler(Scheduling.kt:108)

    at tech.libeufin.nexus.SchedulingKt$startOperationScheduler$1.invokeSuspend(Scheduling.kt)

    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)

    at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)

    at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)

    at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)

    at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)

    at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)

Caused by: org.postgresql.util.PSQLException: FATAL: sorry, too many clients already

    at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:693)

    at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:203)

    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:258)

    at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:54)

    at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:253)

    at org.postgresql.Driver.makeConnection(Driver.java:434)

    at org.postgresql.Driver.connect(Driver.java:291)

    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:681)

    at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:229)

    at org.jetbrains.exposed.sql.Database$Companion$connect$10.invoke(Database.kt:160)

    at org.jetbrains.exposed.sql.Database$Companion$connect$10.invoke(Database.kt:160)

    at org.jetbrains.exposed.sql.Database$Companion$doConnect$3.invoke(Database.kt:112)

    at org.jetbrains.exposed.sql.Database$Companion$doConnect$3.invoke(Database.kt:111)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction$connectionLazy$1.invoke(ThreadLocalTransactionManager.kt:58)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction$connectionLazy$1.invoke(ThreadLocalTransactionManager.kt:57)

    at kotlin.UnsafeLazyImpl.getValue(Lazy.kt:81)

    at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManager$ThreadLocalTransaction.getConnection(ThreadLocalTransactionManager.kt:64)

    at org.jetbrains.exposed.sql.Transaction.getConnection(Transaction.kt)

    at org.jetbrains.exposed.sql.statements.Statement.prepared(Statement.kt:24)

    at org.jetbrains.exposed.sql.statements.Statement.executeIn$exposed_core(Statement.kt:47)

    ... 26 more
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020048)
sebasjm   
2023-04-10 15:16    		not seen anymore

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6260 [Taler] libeufin-nexus minor have not tried 2020-05-24 14:34 2023-04-17 11:57
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: nexus should store balance
Description: The nexus should parse the latest account balance and offer it via API.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019821)
MS   
2023-02-13 18:29    		Not required for regional currencies: users don't have accounts at Nexus and the exchange doesn't need it.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6269 [Taler] libeufin-sandbox minor have not tried 2020-05-29 08:48 2023-04-17 11:56
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: sandbox should emit c52/c53 more like real banks do
Description: Right now we generate a fresh c53 statement for every request.

Banks would return the same message on every request. They basically emit c5x messages regularly, and EBICS just allows you to download them.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015980)
Florian Dold   
2020-05-29 09:25    		A major problem right now is that the MsgId of messages emitted by the sandbox is always zero. This doesn't mesh well with the assumptions made in the nexus (and that are presumably true for all real banks).
(0015981)
Florian Dold   
2020-05-29 09:26    		Setting this to higher prio, as Heng Yeow needs this for testing his UI stuff
(0015983)
MS   
2020-05-29 13:33    		bf5ae27..01c8396 is a quick fix that gives more entropy to the message id.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6715 [Taler] libeufin-sandbox minor have not tried 2021-01-22 16:32 2023-04-17 11:54
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: sandbox should not "activate" EBICS subscriber keys by default
Description: Instead, there should be a separate step where a request is made to the sandbox to activate the keys.

This allows us to test the behavior of Nexus *before* keys were activated by the bank (but after they were uploaded electronically).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6741 [Taler] libeufin-nexus minor have not tried 2021-02-05 14:13 2023-04-17 11:54
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: bank account operation affects the whole connection
Description: The "fetch-transactions" API offered by Nexus operates under one bank account imported name. However,
the actual Camt record is asked in the name of the *connection*. If one connection can host two bank accounts,
then asking for account A will involve *also* account B, leading to confusion.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6893 [Taler] libeufin-sandbox minor have not tried 2021-05-27 15:51 2023-04-17 11:53
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: Camt reports should respect time "chunking".
Description: At this present time, every report / statement accounts for the whole history of the bank account. Instead, those reported histories need to account only for a particular time window. Usually, from one point in the past, up to the current date.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6962 [Taler] libeufin-sandbox minor have not tried 2021-07-29 11:44 2023-04-17 11:53
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: CAMT reports need more structure to specify negative balances.
Description: CAMT numbers cannot be negative, therefore whenever a bank account enters the debit status, the CAMT generation must include more structure to reflect it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7569 [Taler] libeufin-sandbox minor have not tried 2023-01-12 17:27 2023-04-17 11:52
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: EBICS error codes should be fetched from the enum defined in Util.
Description: Sandbox hard-codes EBICS error codes as strings in its responses, ignoring the enum
offered in the util package that already collects many EBICS codes.

The enum is called "EbicsReturnCode", in Ebics.kt at util package.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7696 [Taler] libeufin-nexus major have not tried 2023-02-15 16:09 2023-04-17 11:48
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: EBICS_NO_DOWNLOAD_DATA_AVAILABLE check is possibly wrong.
Description: Nexus checks this as a EBICS-technical return code, although the documentation lists it among the
business-technical return codes. That doesn't break demo because Sandbox does the same (just
server-side).

However, this may break when using Nexus with other banks. Hence such check needs more tests
with different banks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7735 [Taler] libeufin-sandbox minor have not tried 2023-02-28 17:09 2023-04-17 11:48
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Avoid calculating balances based on the transactions history.
Description: The bank should instead calculate the new balance right after having processed one
transaction, and store it into the database.
Tags:
Steps To Reproduce:
Additional Information: The reason for this change is to reduce the computational cost of the balance calculation.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7739 [Taler] libeufin-nexus minor have not tried 2023-03-04 16:48 2023-04-17 11:45
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Creating background tasks should be idempotent.
Description: Now it responds with 400, which is not even suitable for a name conflict.

The "POST ../schedule" call is responsible.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019951)
MS   
2023-03-10 14:56    		Agreed that background tasks should be just overridden by the owner, without any idempotent behavior.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7762 [Taler] libeufin-nexus minor have not tried 2023-03-10 08:48 2023-04-17 11:44
Reporter: javier.sepulveda Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: The libeufin-{nexus,sandcastle} Debian packages ask additional questions
Description: The libeufin-{nexus,sandcastle} Debian packages ask additional
questions (hostname, password) about the database that the
taler-merchant Debian package does NOT ask. Likely some 'default' option
is missing that causes these additional questions to be asked. Ideally,
we like _zero_ questions to be asked, but surely we should be able to
get the libeufin-packages to ask only the 1 interactive question that
the taler-merchant package asks.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020102)
Florian Dold   
2023-04-17 11:44    		The packaging should use suggestions from DD40 for the database configuration.

Furthermore, we should validate that libeufin now supports unix domain socket connections for the database.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7763 [Taler] deployment and operations feature have not tried 2023-03-10 08:50 2023-04-17 11:43
Reporter: javier.sepulveda Platform:  
Assigned To: javier.sepulveda OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Netzbon - Terms of Service
Description: We need to make it easy for the netzbon-deployment to setup the
terms of service. This will require
a) modifying the script to set certain options for the Taler exchange,
including the TERMS_DIR and the TERMS_ETAG (and same for the privacy
policy). But, moreover, we *generate* the ToS using some non-trivial
scripting (see exchange.git/contrib/update-*.sh). We should probably
find a nice way to ship such TOS-generation scripts with the
Taler-exchange (maybe convert all of it -- including the logic and
configurations from the Makefile in the contrib/tos/ directory) into
some big shell script?). The idea is that the user would supply us with
the RST files of the ToS in en/de/it/es/etc, and then the script
generates the HTML, TXT, PDF and markdown versions from the master RST
file(s) and puts them into the right directory locations.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6250 [Taler] libeufin-nexus minor have not tried 2020-05-21 09:05 2023-04-17 11:42
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement advanced permission storage and checking
Description: Right now, the nexus doesn't do any permissions at all beyond authenticating the user.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020065)
MS   
2023-04-11 11:03    		It does. This is one example from the Taler facade:
https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/Taler.kt?id=1b9fbb02ac2d2eb402c18877079d1bdbae03a620#n180
(0020066)
MS   
2023-04-11 11:08    		Although a valid issue, that can be moved to another release because Nexus
will rarely be exposed online AND have more than one user at the first deployment
with Postfinance. On top of that, the note above shows that checks do take place.

It remains to check WHERE ELSE they may be needed and test them.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7766 [Taler] libeufin-nexus major have not tried 2023-03-14 10:52 2023-04-17 11:41
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Production deployments need "since-last" when downloading bank transactions.
Description: Tasks that download bank transactions need "since-last" as the "range-type" (see API doc below),
in order to avoid data loss in case one batch doesn't get stored in the database.

This problem exists, for example, with the "latest" range type. If "latest"-batch at time T doesn't
arrive to the database, then "latest"-batch at time T+1 will likely NOT include payments from T,
resulting in data loss.

https://docs.taler.net/libeufin/api-nexus.html#post-nexusBase-bank-accounts-acctid-schedule
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7785 [Taler] libeufin-nexus minor have not tried 2023-03-31 18:40 2023-04-17 11:40
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Error handling mixes up bank- and EBICS-technical errors.
Description: For example, if Nexus submits a payment with the wrong currency, then
an error object named EbicsProtocolError is thrown and it carries the error
code from the bank in its 'ebicsTechnicalCode' field.

The error in question is NOT EBICS-technical because the problem was in
the EBICS _payload_ and NOT in the EBICS communication itself.

The fix should provide this difference, and as well be the occasion to review
the code to spot other places where the same problem lies.
Tags:
Steps To Reproduce:
Additional Information: The test case 'unsupportedCurrency()' at EbicsTest.kt reproduces the wrong currency scenario.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5973 [Taler] libeufin-sandbox minor have not tried 2019-11-18 19:33 2023-04-17 11:40
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: report more information about a user's state
Description: For example, if the user tries to send signed data *before* sharing their keys with the bank, then the Sandbox responds with "invalid signature". Instead, the Sandbox should point the user to the right way telling them that their keys weren't received yet.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015296)
Marcello Stanisci   
2020-01-23 00:13    		260528a..5bc7981 throws more appropriate errors (EbicsSubscriberStateError) whenever a subscriber attempts some operation while being in a wrong state. Leaving open until testing this change.
(0015914)
Marcello Stanisci   
2020-05-15 19:08    		Still untested.
(0019747)
MS   
2023-02-03 16:06    		The code doesn't show anymore such checks. Issue still open
(0019817)
MS   
2023-02-13 18:17   
(Last edited: 2023-02-13 18:17) 		not needed for regional currencies. As soon as a user is registered, their state is ready to operate.
(0020100)
Florian Dold   
2023-04-17 11:06    		Not sure why this is assigned to me. @MS could you please look into this bug and whether we can already resolve it?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6243 [Taler] libeufin-sandbox minor have not tried 2020-05-20 19:05 2023-04-17 11:39
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: sandbox filtering on EBICS date range is missing in C53 requests
Description: The sandbox is ignoring the date range from C53 requests. To be fixed.
Tags:
Steps To Reproduce:
Additional Information: The responsible function is called "constructCamtResponse()"
Attached Files:
Notes
(0018149)
ms-mantis   
2021-08-31 14:49    		That is implemented here: 3967193487e42335b43b80ee7407fa44ad39cf70.

Extensive testing is now needed, especially via Nexus' querying.
(0019514)
MS   
2022-12-13 16:39   
(Last edited: 2022-12-14 23:14) 		Camt.052 needs date range too. Now throws NotImplementedError().

=> after private discussion, libeufin won't support date ranges on C52.

Keep open until C53 gets tested. Not urgent as not used by Taler.
(0019751)
MS   
2023-02-03 18:17   
(Last edited: 2023-02-03 18:18) 		That depends on the Sandbox to "tick" business days. A tick operation moves all the pending transactions to the booked state, and only then they become available for C53.

Hence before fixing this, Sandbox should tick, otherwise it will have always no C53-content.

This feature would help in case of data loss from Nexus, as then only the bank could resort
the lost information.
(0019822)
MS   
2023-02-13 18:39    		Lowering the priority because Sandbox won't _serve_ EBICS in the context of regional currencies.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7781 [Taler] libeufin-sandbox feature have not tried 2023-03-29 14:51 2023-04-17 11:37
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: sandbox demobank should have endpoint for transaction volume / statistics info
Description:
from chat:
> But at least for the bank we should be able to show both
> # bank transactions (per day/week/month/year) and
> # <CURRENCY> transacted in total (per day/week/month/year).
>
> It should be displayed in SPA as an HTML table with a CSV-export might do as well.

So there should be endpoint for the SPA (returns json) but also content-type = csv
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6046 [Taler] libeufin-sandbox major have not tried 2020-01-15 10:12 2023-04-17 11:19
Reporter: Marcello Stanisci Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: Must distinguish between booked and non booked transactions
Description: To implement C52 and C53 messages, the database should allow to qualify transactions as "booked" or "non-booked".
Tags:
Steps To Reproduce:
Additional Information: In particular, non-booked transactions must be excluded from CAMT.053 responses.
Attached Files:
Notes
(0015913)
Marcello Stanisci   
2020-05-15 19:07    		Still open.
(0019816)
MS   
2023-02-13 18:14    		Removing the 0.9.2 target as this issue suggests to emulate traditional banks. That doesn't fit into the current regional currency scenario.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6427 [Taler] libeufin-sandbox feature have not tried 2020-07-09 19:41 2023-04-17 11:04
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: EBICS errors need XML
Description: In some (all?) error cases related to EBICS, the sandbox responds with plain text.
Instead it should respond with the XML document that complies to the EBICS specifications.
Tags:
Steps To Reproduce:
Additional Information: Moving to 0.2 because it became a testing problem.
Attached Files:
Notes
(0016507)
MS   
2020-07-23 13:42   
(Last edited: 2020-07-23 13:44) 		Mostly addressed here: c716d23073be8846d0765fa766de341dbc953a88
(0016508)
MS   
2020-07-23 13:48    		The EbicsError global catcher needs a private key to be included in the exception object,
and if that's not found, it responds with JSON (and status 500). (The private key is needed
to sign the response object.)

The current problem is that not in all the parts of the code such private key is included in
the exception object, resulting still in JSON+500 being returned.
(0016509)
MS   
2020-07-23 17:13    		After private discussion, the private key will be moved away from the exception object. But at the same time, the exception handler
must be moved in a place where it is easier to get more context (including the private key) from the current request.
(0016531)
MS   
2020-07-29 15:41    		Fixed, but this test now fails: integration-tests/test-ebics-double-payment-submission.py
(0017647)
MS   
2021-03-25 10:42    		The test mentioned in the last comment was long ago removed, and in general, corner cases will 'all' have to be implemented in the new TypeScript harness. IMO, this can be closed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7805 [Anastasis] General minor have not tried 2023-04-14 11:54 2023-04-17 09:51
Reporter: javier.sepulveda Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Taler OPS - Domain name
Description: Domain permissions - OK
Point domain name to the the taler-systems server
Create NGINX virtualhost
Configure Let's Encrypt certificate
Create under constructions .html file
Leave everything ready to just upload final website
Tags: taler-operations-server
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020093)
javier.sepulveda   
2023-04-14 13:14    		Everything done except for requesting domain TLS certificate.
(0020098)
javier.sepulveda   
2023-04-17 09:51    		TLS certifcate for domain taler-ops.ch domain name - Done
Pending to create a specific user for this new website such as /home/talerops/talerops-public
Right now the "under construction website" is within the talersystems user home folder.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6696 [Taler] documentation text have not tried 2021-01-13 23:50 2023-04-13 21:59
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: discuss better structure for LibEuFin docs
Description: The LibEuFin docs are currently pretty chaotic. We should come up with a better structure.

I guess there are three different target audiences for the docs:
* Operators of LibEuFin (who want to use it with Taler)
* Developers who want to use the LibEuFin API
* Core Developers of LibEuFin ("internal stuff, documented in public")
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017449)
ttn   
2021-01-29 19:42    		Well, the HOWTO (tutorial) is clearly targeted at the Operator audience. I don't know what the distinction is between the other two audience groups are, however.
(0017490)
ttn   
2021-02-02 21:34    		Applicable not just to Libeufin, but all Taler documentation:
https://documentation.divio.com/
(0018093)
ttn   
2021-08-11 04:55    		Please see recent commits in docs.git/libeufin/*.rst --
the "target audience" can be "operator", "developer", "core developer".
(Feel free to add/correct my guesses.)
(0018632)
ttn   
2022-01-12 02:25    		Just managed to "manually" build/install libeufin. When i tried to run libeufin-cli, i saw an error:

 ModuleNotFoundError: No module named 'click'

This makes sense since i don't have that module installed on my system (yet).
Anyway, we should probably document these runtime dependencies, and additionally
make sure the Debian packaging declares them so that they are installed automatically.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5830 [Taler] merchant backend API (C) feature have not tried 2019-08-17 19:26 2023-04-13 21:58
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: implement request tunneling for wallets
Description: The /proxy API should be implemented to allow the wallet to tunnel requests to the exchange and merchant backend via a PoS terminal.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0014870)
Florian Dold   
2019-09-06 11:51    		Moving this to a later milestone.

Currently the Android PoS app does the tunneling. Doing the tunneling through the merchant backend would be much nicer, but is not really urgently needed.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7748 [Taler] merchant backoffice SPA feature always 2023-03-07 18:15 2023-04-13 21:53
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: qr code for the template order
Description: that
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019925)
sebasjm   
2023-03-07 18:34    		i should be printable
also should be able to add the paramteres like subject and amount
https://datatracker.ietf.org/doc/html/draft-grothoff-taler-00#name-action-pay-template
(0019949)
sebasjm   
2023-03-10 12:48    		fixed 867d2ca76

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6120 [Taler] libeufin (general) minor have not tried 2020-03-09 16:44 2023-04-13 21:50
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Incapsulate marshall/unmarshall exceptions inside UtilError
Description: Right now Nexus and Sandbox code must explicitly install a exception handler for marshall/unmarshall errors, making the code more verbose. Ideally, the util layer should hide such details and just raise a UtilError().
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015900)
Marcello Stanisci   
2020-05-15 18:17    		Confirming that this is STILL open!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6404 [Taler] libeufin-nexus minor have not tried 2020-06-22 12:03 2023-04-13 21:49
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: ISO20022 camt mapping is not documented, incomplete and incorrect in some places
Description: See summary.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020059)
MS   
2023-04-11 10:39    		Assuming the bug refers to this data type, suggesting to more verbosely document its fields:
https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/iso20022/Iso20022.kt?id=101fa06fd5fa863a90eb4cbc0b4fcd2e28fda583#n274

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7732 [Taler] libeufin-sandbox minor have not tried 2023-02-26 18:55 2023-04-13 21:49
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: circuit API uses floating point numbers
Description: We never ever want floating point numbers in financial calculations!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019906)
Florian Dold   
2023-02-26 19:15    		Furthermore, we made the decision to avoid floats in all JSON that we produce, because it makes normalization for signing very hard.

Doesn't matter it we don't sign this particular message; it's a principle we apply to all our protocols.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6383 [Taler] libeufin-nexus minor have not tried 2020-06-15 08:54 2023-04-13 21:49
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support notifications / "long polling" for certain operations
Description: For the UI, we might want to support web socket notifications.

For the TWG, we need to support long polling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019959)
MS   
2023-03-13 11:03    		TWG part addressed, see 0007693.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6387 [Taler] libeufin-nexus tweak have not tried 2020-06-16 12:05 2023-04-13 21:48
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: more integration tests for key management needed
Description: Right now we mostly cover the "happy path" in key management, but we should also cover error cases.

For example, real banks don't set the subscriber to "ready" after INI and HIA. We thus need a test to make sure that Nexus handles this situation correctly: A sent INI/HIA where the subscriber keys aren't activated on the bank side yet.

Some of these might require support from the sandbox.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6400 [Taler] libeufin-nexus minor have not tried 2020-06-21 14:18 2023-04-13 21:48
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: consider doing faster re-tries for some scheduled operations
Description: When the daily bank statement download fails, should LibEuFin retry before the next scheduled execution?

For most tasks, a faster re-try doesn't make sense though.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6704 [Taler] libeufin-nexus minor have not tried 2021-01-17 00:09 2023-04-13 21:48
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: TWG facade gives unhelpful error message when payto URI is incorrect
Description: ... we should return a better error message in the Taler error format.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7462 [Taler] libeufin (general) minor have not tried 2022-11-16 10:31 2023-04-13 21:47
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Unix domain sockets fails.
Description: The following error might be due to wrong file permissions on the open Unix domain socket.

11:42:34.310 [main] DEBUG tech.libeufin.util - Listening on /home/demo/sockets/bank.http ..
16:08:56.861 [epollEventLoopGroup-3-1] INFO ktor.test - Autoreload is disabled because the development mode is off.
16:08:56.868 [epollEventLoopGroup-3-1] INFO ktor.test - Application started in 0.057 seconds.
16:08:57.142 [DefaultDispatcher-worker-1] DEBUG tech.libeufin.sandbox - 404 Not Found, GET /bad-request - thread (id/name/group): 23/DefaultDispatcher-worker-1/main
16:08:57.149 [epollEventLoopGroup-3-1] DEBUG tech.libeufin.sandbox - Application stopping: io.ktor.application.Application@3b430b91
16:08:57.149 [epollEventLoopGroup-3-1] DEBUG tech.libeufin.sandbox - Application stopped: io.ktor.application.Application@3b430b91
16:08:57.158 [epollEventLoopGroup-3-1] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
java.lang.NullPointerException: null
    at io.netty.buffer.Unpooled.wrappedBuffer(Unpooled.java:156)
    at LibeufinHttpHandler$channelRead0$1.invoke(UnixDomainSocket.kt:108)
    at LibeufinHttpHandler$channelRead0$1.invoke(UnixDomainSocket.kt:72)
    at io.ktor.server.testing.TestEngineKt$withTestApplication$1.invoke(TestEngine.kt:68)
    at io.ktor.server.testing.TestEngineKt$withTestApplication$1.invoke(TestEngine.kt:66)
    at io.ktor.server.testing.TestEngineKt.withApplication(TestEngine.kt:49)
    at io.ktor.server.testing.TestEngineKt.withApplication$default(TestEngine.kt:41)
    at io.ktor.server.testing.TestEngineKt.withTestApplication(TestEngine.kt:66)
    at LibeufinHttpHandler.channelRead0(UnixDomainSocket.kt:72)
    at LibeufinHttpHandler.channelRead0(UnixDomainSocket.kt:67)
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
    at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:280)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
    at io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:138)
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:829)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7515 [Taler] libeufin (general) minor have not tried 2022-12-09 20:21 2023-04-13 21:47
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Configuration should not impact the database.
Description: In the current version, every change in the configuration causes a database
migration, because every value gets a column. That is not sustainable. An alternative
would be to host all the configuration values into one global object that gets serialized
into the database.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019957)
MS   
2023-03-13 10:42    		Addressed in this tag: v0.9.2-dev.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6402 [Taler] libeufin-nexus major have not tried 2020-06-22 07:01 2023-04-13 21:47
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: handle disrupted EBICS transactions
Description: We should either explicitly cancel such a transaction or re-try if the EBICS host supports this feature.

Currently we might run into waiting for a timeout (for re-doing the same order type) until the bank cancels the active transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6368 [Taler] libeufin-nexus tweak have not tried 2020-06-08 21:17 2023-04-13 21:47
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: test message chunking
Description: Right now we mostly have EBICS transactions with one segment. We also need test cases for bigger EBICS order payloads.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6376 [Taler] libeufin-nexus tweak have not tried 2020-06-11 09:39 2023-04-13 21:47
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: test against all samples given by the German standard supplement
Description: https://www.ebics.de/de/datenformate/ergaenzende-dokumente

We should test against the camt5x documents in particular.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017381)
Florian Dold   
2021-01-21 02:15    		We mainly should make sure that the parser doesn't crash, and that we have the JSON that we generated as a reference file in a test case.
(0017391)
MS   
2021-01-22 17:07    		This gets delayed, as now the parser targets only one particular Camt style.
(0017392)
MS   
2021-01-25 15:56    		From commit: 5b536593b9d84a9bb5ea2908aa2ab259d9199308, libeufin-tests.git contains samples from ebics.de and the UBS testing platform.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6380 [Taler] libeufin-nexus minor have not tried 2020-06-14 15:53 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: more extensive integration test cases for TWG are required
Description: We currently test very little. What we need to add is:

* transactions that are returned due to missing reserve pub
* transactions that don't even have a debtor account (needs sandbox support)
* transactions that
* ... and probably many more!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017219)
MS   
2020-12-20 13:58    		The mapping between (a) and (b) needs to be tested.

(a) transaction indexes that are known natively (= no facade involved) by the nexus.
(b) the transaction indexes as viewed by the Taler facade.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6698 [Taler] libeufin (general) minor have not tried 2021-01-14 00:27 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: general code cleanup required
Description: There are currently quite a number of compile-time warnings as well as linter issues pointed out by IntelliJ.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6973 [Taler] libeufin (general) minor have not tried 2021-08-03 14:54 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: CLI integration test should test nexus permissions
Description: ... both positive (=yes, allowed user can access this) and negative (=no, without permissions the user can't access)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5953 [Taler] libeufin (general) minor have not tried 2019-10-29 10:08 2023-04-13 21:46
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: generate code documentation with Dokka
Description: See https://kotlinlang.org/docs/reference/kotlin-doc.html
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6364 [Taler] libeufin (general) text have not tried 2020-06-04 16:37 2023-04-13 21:46
Reporter: MS Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: Comments style.
Description: From a private conversation:

I've seen that some comments in LibEuFin use the

/**
 * foo
 * bar
 */

style. While this is not really a big issue, I just wanted to mention
that comments beginning with "/**" usually indicate doc comments. That
is, comments that are relevant to the documentation generator (doxygen,
dokka, ...).

As such, it's better style to use "//" comments or "/*" comments (single
start) for comments that just explain what's going on inside the code,
as opposed to comments that represent the documentation for some
"documentable" element, such as functions, class members, etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6399 [Taler] libeufin-nexus minor have not tried 2020-06-19 14:19 2023-04-13 21:45
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: review and document date/time/timezone handling
Description: Especially for EBICS order params.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6602 [Taler] libeufin-nexus minor have not tried 2020-09-11 17:47 2023-04-13 21:44
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Check that API docs match the code.
Description: There is also a minimal library that checks if the fields are present in the JSON objects, although it doesn't validate the values.

Here's an example of how to use that library:
https://git.taler.net/libeufin.git/tree/integration-tests/json_checks.py?id=f3a2bf68bef89428d7a3885531b1780d51f6a81b
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017113)
MS   
2020-11-10 11:39    		All the API calls used in the tests *except* the Taler facade have been double checked using the "check library" mentioned above.
Next step: test the Taler facade using the same check-library, and extend test cases to use EVERY API call that is written in the documentation.
(0019746)
MS   
2023-02-03 15:13    		Sandbox got reviewed along the Circuit API implementation. Nexus needs a pass.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7662 [Taler] libeufin-sandbox minor always 2023-02-07 15:34 2023-04-13 21:44
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: error does not provide the field where the validation is made
Description: Some validation show the field where the error is, but for the username looks like not. It will be nice to have the some kind of error that help fixing the problem.

Also, I couldn't find documentation of this validations.

curl 'https://sandbox-libeufin.taler.ar/demobanks/default/circuit-api/accounts' -d '{"username":"1","password":"1","name":"the name","contact_data": {},"cashout_address":"payto://iban/DE123123"}' -v

  "error" : {
    "type" : "util-error",
    "description" : "Invalid resource name. The first character must be a lowercase letter, and all following characters (except for the last character) must be a dash, lowercase letter, or digit. The last character must be a lowercase letter or digit."
  }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7686 [Taler] libeufin-nexus minor have not tried 2023-02-13 18:48 2023-04-13 21:44
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Allow date range when asking transactions.
Description: That helps in case of data loss.

A typical example is:

1. data gets lost due to a parser issue
2. use this feature to download again the problematic transaction
3. fix the parser after inspecting the problematic transaction
4. download again the problematic transaction with the fixed parser
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019823)
MS   
2023-02-13 18:53    		Nexus needs to be adapted to use such date range.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6073 [Taler] libeufin-nexus major have not tried 2020-02-04 14:38 2023-04-13 21:43
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: serialize some transaction state to the database
Description: ... so that we don't run into timeouts when we didn't properly acknowledge a previous transaction.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015908)
Marcello Stanisci   
2020-05-15 18:44    		Still pending. It seems that nexus performs all the steps in two big functions,
without storing any state during the operations:

- doEbicsDownloadTransaction()
- doEbicsUploadTransaction()
(0015953)
Florian Dold   
2020-05-24 13:52    		We likely require a new API for this. I wouldn't prioritize this right now though.

Just as a reminder, the main purpose of this is to be more robust against failures, because when we don't acknowledge an EBICS upload/download transaction on our side, we might have to wait for a timeout until the bank lets us do the same order type again.
(0017908)
MS   
2021-05-27 10:23    		Priority changed after this last note.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6972 [Taler] libeufin-nexus minor have not tried 2021-08-03 14:53 2023-04-13 21:42
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: review /facades and /facades/${id} implementation
Description: We currently have a lot of code duplication there, and the code is not generic for the facade, but only works with the TWG facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6987 [Taler] other feature have not tried 2021-08-07 20:16 2023-04-13 21:42
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wirewatch should use long polling
Description: While not supported yet by libeufin, it might be a good idea for taler-exchange-wirewatch to do long-polling.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018110)
Christian Grothoff   
2021-08-12 13:18    		10d8342f..f174781b adds support for longpoll_ms to libtalerbank. fakebank still needs long polling support. Not sure about libeufin...
(0018112)
Christian Grothoff   
2021-08-17 10:05    		Fakebank now has long-polling support.
(0018115)
Christian Grothoff   
2021-08-18 10:22    		Exchange logic should be complete, now it's up to LibEuFin to finish this.
(0019958)
MS   
2023-03-13 11:01    		Implemented at this libeufin.git tag: long-polling-twg.

Sandcastle-Libeufin needs to switch to Postgres, to help testing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7168 [Taler] libeufin (general) feature have not tried 2022-02-02 07:38 2023-04-13 21:41
Reporter: ms-mantis Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: remove non-Access-API command from libeufin-cli
Description: That should happen after having removed their use from wallet tests.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7414 [Taler] libeufin-sandbox major N/A 2022-10-23 15:20 2023-04-13 21:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: MS OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: 0.9.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: [security] Demonstration SPA stores password in plaintext in localstorage
Description: Nora reports:

The SPA currently stores the login details on the client in LocalStorage as backend-state.username & backend-state.password in plaintext.

We should instead serve authentication tokens which would be stored in place of a password, at a bare minimum.

Something like a simple randomized string that would get invalidated after some time should be sufficient, however something similar to RFC7519 should also work. Either way, we should not store the password (in an unhashed form) anywhere, neither on the client, nor the server.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7458 [Taler] demobank feature always 2022-11-15 15:55 2023-04-13 21:40
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: allow configuration of another BIC number other than SANDBOXX
Description: should this be done on account creation?
(CustomerRegistration needs a "val bic: String?" that can be used on /register)

it will be better to set a default value on sandbox config.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7507 [Taler] libeufin-nexus minor have not tried 2022-12-01 16:58 2023-04-13 21:39
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: EBICS management spans two API routes.
Description: Sandbox serves EBICS calls at both "/admin/ebics/*" and "/demobanks/default/ebics/subscribers".

Should all the endpoints be moved into only one route?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6122 [Taler] libeufin-nexus minor have not tried 2020-03-10 15:13 2023-04-13 21:39
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: EBICS error responses should be correctly parsed.
Description: The current Nexus responds with a "invalid XML" message whenever the bank gives it a EBICS error response. Such message is wrong, and should be adapted to reflect what happens.

The real responsible is the util module, where the actual parsing happens, therefore this one should be adapted to tolerate EBICS error responses. One example is the function: "parseAndDecryptEbicsKeyManagementResponse()"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015911)
Marcello Stanisci   
2020-05-15 19:05    		It doesn't look like that applies anymore, but I would defer solving this to when
we will be testing faulty requests along the integration tests.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6248 [Taler] libeufin-nexus tweak have not tried 2020-05-21 09:01 2023-04-13 21:39
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: test error handling during subscriber initialization
Description: Right now we assume everything goes okay.

We should have a *separate* test case where we mess with the sandbox during the subscriber initialization. For example, we can "undo" the INI on the sandbox and see if the nexus correctly reports what's going on.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6253 [Taler] libeufin-nexus text have not tried 2020-05-21 09:16 2023-04-13 21:38
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: adjust and document JSON formats for account information
Description: This includes:
 * information about the account itself (should include payto URI!)
 * information about a prepared payment
 * information about a transaction

These formats are currently barely documented.

We also should try to make the terms match more commonly accepted terminology, like creditorAccount and debitorAccount instead of "counterpart".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6721 [Taler] libeufin-nexus minor have not tried 2021-01-25 15:14 2023-04-13 21:38
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: consider a way to synchronize the row_id with the TWG
Description: We should be able to recover as cleanly as possible in case the LibEuFin state somehow gets purged.

The TWG might notify the exchange to reset to a lower row_id when the transactions request is "unreasonable".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017393)
Christian Grothoff   
2021-01-25 23:23    		I don't think the exchange can possibly reset -- it must not have duplicate row IDs. More importantly, it is necessary that the auditor sees/computes the same row IDs!

So what instead can/should be done, is that a resuming libeufin can be told to _begin_ its row IDs at a non-zero offset. That offset could then be extracted from the exchangedb.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7734 [Taler] libeufin-sandbox minor have not tried 2023-02-28 17:06 2023-04-13 21:37
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Track used IBANs.
Description: In order to avoid that one IBAN gets reassigned after a user removal, the bank has to keep track of all the IBANs
that were assigned to any bank account.
Tags:
Steps To Reproduce:
Additional Information: At a later stage, the bank may employ a policy to recycle those used IBANs.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6547 [Taler] libeufin-nexus minor have not tried 2020-08-31 12:56 2023-04-13 21:36
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Offer raw EBICS upload for any message.
Description: Nexus needs to offer a API call to upload for any type of EBICS message. This is already documented,
therefore needs the implementation. The download does have a implementation already.

The endpoint will look like the following:
  
  {nexus_base_url}/bank-connections/{connection_name}/ebics/upload/{msg}
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020061)
MS   
2023-04-11 10:43    		Not _strictly_ relevant for the Postfinance integration as what gets uploaded to the bank
needs a defined type (as opposed to raw content to be sent "on the fly"). Still, this may result
convenient, so keeping for now but with low priority.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6085 [Taler] libeufin-nexus minor have not tried 2020-02-10 12:52 2023-04-13 21:36
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: abstract out ebics version
Description: The util library probably should not "leak" the version of the EBICS protocol we're using to the nexus and the sandbox. We should abstract out the details of EBICS 2.5 and EBICS 3 into data structures describing their content in a version-independent way that does not expose the underlying XML too much.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015337)
Marcello Stanisci   
2020-02-10 19:02    		Could you point to the function / class that causes this?
(0015338)
Florian Dold   
2020-02-10 19:03    		Let's discuss this tomorrow in person, after I've committed my rather large change.
(0015906)
Marcello Stanisci   
2020-05-15 18:37    		Still pending.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6080 [Taler] libeufin-nexus minor have not tried 2020-02-06 15:28 2023-04-13 21:35
Reporter: Florian Dold Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: understand format of pain.002
Description: The pain.002 is the bank's way of telling us the result (error/success) of submitting a pain.002 message, and we should understand the content of it.

One possible way to do this is by playing around with the GLS client (making a payment, then requesting the payment status).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015905)
Marcello Stanisci   
2020-05-15 18:36    		This got slowed down because GLS does not respond to the EBICS CRZ message type.
The issue was reported already to the GLS responsible department.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5962 [Taler] libeufin-nexus minor have not tried 2019-11-08 19:46 2023-04-13 21:34
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: find out details about EBICS case sensitivity
Description: Apparently some EBICS clients treat data in a case-insensitive way and upper case even when they got data (e.g. transaction IDs) in lower case.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5972 [Taler] libeufin-nexus minor have not tried 2019-11-18 19:28 2023-04-13 21:31
Reporter: Marcello Stanisci Platform:  
Assigned To: Marcello Stanisci OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Avoid sending signed data before key exchange
Description: The Nexus should check if their keys were accepted by the bank (via INI / HIA) before performing any operation using those.

This is useful because some banks may simply respond "signature invalid" without telling what the real cause is.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015917)
Marcello Stanisci   
2020-05-15 19:19    		This happens here (1) for example, where the 'makeEbicsHpbRequest()' function just
makes the message without checking the state of the key used to sign the message.

But possibly, this is not a real problem. If errors are nicely reported, then the user
will be correctly warned about the impossibility of the attempted operation.

[1] https://git.taler.net/libeufin.git/tree/nexus/src/main/kotlin/tech/libeufin/nexus/Main.kt?id=4f0af79c3cde2b71f8a3607d5310aaf375d011eb#n87
(0020067)
MS   
2023-04-11 11:14   
(Last edited: 2023-04-11 11:22) 		This can be closed after testing how Postfinance reacts to such scenario,
but using keys that were never shared with the bank should be avoided.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6382 [Taler] libeufin-nexus minor have not tried 2020-06-15 08:47 2023-04-13 21:31
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: support transaction fetching since last successful bank-side creation date/time
Description: Thus we can request transaction history without any gaps.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0016330)
Florian Dold   
2020-06-21 16:06    		A rudimentary version of this is implemented, however the EBICS-related timezone mess still needs to be sorted out.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7786 [Taler] libeufin-nexus minor have not tried 2023-03-31 18:43 2023-04-13 21:31
Reporter: MS Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Taler facade throws EBICS errors.
Description: The Taler facade faces only clients that are unaware of EBICS. For this reason it should throw the more
generic NexusError objects.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7797 [Taler] libeufin-sandbox minor have not tried 2023-04-10 14:24 2023-04-13 21:30
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Integration API has the wrong error format.
Description: Error handling happens, but responds with the wrong format. Starting with the Integration API part,
and Ideally ending with all LibEuFin, the following format should be used:
this format: https://docs.taler.net/core/api-common.html#tsref-type-ErrorDetail

The original bug report follows:

> $ curl "
> https://bank.demo.taler.net/demobanks/default/integration-api/withdrawal-operation/b1155bcf-4550-497f-be0e-ff6948b03194"
> -d '{"reserve_pub":"123123"}'
> {
> "error" : {
> "type" : "sandbox-error",
> "description" : "Selecting a different reserve from the one already
> selected"
> }
> }
>
> The response doesn't contain error code, it follows another format.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5955 [Taler] libeufin-sandbox minor have not tried 2019-10-31 19:48 2023-04-13 20:58
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: use EBICS return codes from EBICS spec, make sure correct codes are returned
Description: The specification has three things:
1. code
2. short name
3. explanatory text

and all these are required.

Furthermore, unless there is actually a bank-technical response code, ebicsHEVResponse should be used.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7556 [Taler] libeufin (general) minor have not tried 2023-01-07 10:35 2023-04-13 20:57
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Fix "make parse".
Description: The two failing tests (test_dashed_subject, test_camt53_example3) show both a message like the following:

self = <json.decoder.JSONDecoder object at 0x7fd9059361d0>
s = '10:04:43,134 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]\n10... "unstructuredRemittanceInformation" : "subject-with-dashes"\n }\n } ]\n } ]\n } ]\n } ]\n}\n'
_w = <built-in method match of re.Pattern object at 0x7fd905a892f0>
Tags:
Steps To Reproduce: Run "make parse".
Additional Information: =============================== short test summary info ================================
FAILED checks.py::test_dashed_subject - json.decoder.JSONDecodeError: Extra data: line 1 column 3 (char 2)
FAILED checks.py::test_camt53_example3 - json.decoder.JSONDecodeError: Extra data: line 1 column 3 (char 2)
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7800 [Taler] demobank-ui feature have not tried 2023-04-12 13:26 2023-04-13 20:57
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Show payto:// URI in account info page
Description: It's currently not easy to get the payto:// URI for an account in the demobank. We should show it somewhere.

If that's too much clutter on the profile page, we could make the account name (i.e. in "Welcome,y (DE775470)!") clickable and to to a dedicated page with the verbose account info.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5947 [Taler] libeufin-sandbox minor have not tried 2019-10-24 20:13 2023-04-13 20:56
Reporter: Marcello Stanisci Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: spec and implement proper generation of EBICS Host "OrderID"
Description: The element "ebicsKeyManagementResponse/header/mutable/orderID" is currently set to a mock value, but it must contain a meaningful identificator.
Tags:
Steps To Reproduce:
Additional Information: The responsible object is generated in KeyManagementResponse.kt.
Attached Files:
Notes
(0015024)
Florian Dold   
2019-10-25 11:02    		See "Order Number" in the glossary (https://docs.taler.net/libeufin/ebics.html#ebics-glossary) for more info about the order ID.

The number must be unique per subscriber and order type. I'd suggest keeping a counter per subscriber and incrementing that in the same (SQL) transaction where the (EBICS) transaction is created.
(0015025)
Florian Dold   
2019-10-25 14:58    		Also, there needs to be some additional logic to "recycle" order IDs, since the space of order IDs is very small.

An order ID can be reused if the corresponding order is completely processed (e.g., there are no pending VEUs).
(0019818)
MS   
2023-02-13 18:19    		not fitting into the regional currencies setup, since Sandbox will not _serve_ EBICS. Removing the 0.9.2 target.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5936 [Taler] libeufin-sandbox minor have not tried 2019-10-18 19:16 2023-04-13 20:55
Reporter: Marcello Stanisci Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: version / revision / other globals / should be available from context
Description: Since EBICS responses want (at least) the EBICS version and revision, the sandbox should have some global object/context that is always updated with the revision and version under which it is serving requests
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0015019)
Marcello Stanisci   
2019-10-18 19:17    		Clearly, after this is done, the parts where such values are hardcoded must be adapted to use the global context.
(0015923)
Marcello Stanisci   
2020-05-15 19:43    		Still open, but not urgent.
(0019820)
MS   
2023-02-13 18:25    		takes even less priority, because Sandbox won't _serve_ EBICS in the context of regional currencies.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7693 [Taler] libeufin-nexus minor have not tried 2023-02-14 13:21 2023-04-13 20:55
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Serve transactions via long polling.
Description: The Nexus native JSON API should support long polling. This way, the currency
conversion service gets timely data without requesting every second. At the same
time, Nexus should always support the EBICS message that gets the most updated
transactions from the bank.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7789 [Taler] libeufin-sandbox major always 2023-03-31 20:33 2023-04-13 20:52
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: Can delete account when balance is 0
Description: This error is thrown

org.postgresql.util.PSQLException: ERROR: update or delete on table "ebicssubscribers" violates foreign key constraint "fk_ebicsuploadtransactions_subscriber_id" on table "ebicsuploadtransactions" Detail: Key (id)=(10) is still referenced from table "ebicsuploadtransactions".


The account was a non-circuit account
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020035)
MS   
2023-04-07 14:50    		Lowering the priority because no regional setup will have EBICS accounts
in Sandbox and demo setups with EBICS have no reason to delete the only
EBICS account: exchange's.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6713 [Taler] libeufin-nexus minor have not tried 2021-01-21 16:53 2023-04-13 20:50
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: implement exporting a TWG facade for easier upgrades of LibEuFin
Description: Due to the way that the Taler Wire Gataway works, we can't just "start from zero". An easy way to avoid costly migration code would be to offer an export feature for the facade.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6992 [Taler] libeufin-nexus feature N/A 2021-08-15 11:55 2023-04-13 20:43
Reporter: Christian Grothoff Platform: i7  
Assigned To: MS OS: Debian GNU/Linux  
Priority: high OS Version: squeeze  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: need new "generic-credit" facade
Description: For Anastasis, we need a new Facade of LibEuFin where we can _only_ poll for incoming credits into the account.
In contrast to the existing taler-exchange facade, the wire transfer subjects can be arbitrary strings and not only reserve public keys.

Please implement the respective facade and specify a REST API for it (based on the existing exchange facade API). The main difference should be that it returns an unrestricted "const char */String" for the wire subject.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0018138)
Christian Grothoff   
2021-08-27 23:15    		I think this is fixed, at least I'm happy with what I got ;-). Marcello: unless the facade is completely fake and only works with sandbox, you should probably 'resolve' this one :-)
(0020092)
Christian Grothoff   
2023-04-13 20:43    		We may want to rename it from anastasis to 'generic-credit' or something like that?

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7309 [Taler] demobank-ui tweak always 2022-08-25 16:52 2023-04-13 20:41
Reporter: Christian Grothoff Platform: i7  
Assigned To: MS OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: improve language switcher integration
Description: Right now, the SPA is launched via /demobanks/default and then always starts with English.
We should support passing "/demobanks/default?language=$LANG" ($LANG=en/de/it/...) and then automatically switch the SPA into the respective language on load, instead of relying on the user (again) setting the language via the language switcher.

The demo.site of nginx is currently configured to replace https://bank/$LANG/ with https://bank/demobanks/defaults, and should be updated to not throw away $LANG but instead pass it via language=$LANG.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7344 [Taler] demobank-ui text have not tried 2022-09-08 20:40 2023-04-13 20:33
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: withdraw target unclear
Description: One user was confused where the money would go when withdrawing money from the bank. The idea that it would go into the Wallet/Webextension in the browser (or on a Mobile phone) was completely alien. He would have liked to FIRST specify the destination before selecting an amount.

Idea: maybe do it more parallel to what we do in the wallet, where we can now specify "send money" and then pick "to wallet" or "to bank account" -- and then ask for the amount?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7345 [Taler] demobank-ui feature N/A 2022-09-08 20:42 2023-04-13 20:32
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: User confused by captcha
Description: User was confused why a captcha was needed, did not see link to PIN/TAN. I guess we should probably really collect a phone number on account creation and send an actual SMS even in the demo...
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7509 [Taler] documentation text have not tried 2022-12-01 19:01 2023-04-13 20:31
Reporter: MS Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: libeufin-sandbox API doc lacks response status codes.
Description: Make sure that every endpoint has their HTTP response status and/or make a disclaimer where obvious statuses are omitted.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7685 [Taler] General minor have not tried 2023-02-13 18:42 2023-04-13 20:26
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Allow date range when serving transactions over JSON
Description: That helps against data loss, whenever Nexus fails at parsing one batch of transactions.
This feature is desired before launching regional currencies, because Nexus will speak JSON
to Sandbox.
Tags:
Steps To Reproduce:
Additional Information: This feature will affect the Access API.
Attached Files:
Notes
(0020058)
MS   
2023-04-11 10:36    		Solved. See the "from_ms" and "until_ms" URI parameters:
https://docs.taler.net/core/api-bank-access.html#get-$BANK_API_BASE_URL-accounts-$account_name-transactions

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7667 [Taler] General block always 2023-02-08 21:47 2023-04-13 20:26
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Unable to render counter part of the cashout (destination of the cashout)
Description: the response of the cashout details endpoint [1] has

  // Circuit bank account that created the cash-out.
  account: string;


if the caller is the owner of the account it is going to be always the same account, this field should contain the destination payto? AKA the counterpart

if the caller is the admin, it should contain both payto: origin and destination.

[1] https://docs.taler.net/libeufin/api-sandbox.html#get--cashouts-$cashoutId
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019789)
MS   
2023-02-09 12:57   
(Last edited: 2023-02-09 12:58) 		the 'origin' is the "account: string" field reported in this bug's description, and the destination can be learned from GET ../circuit-api/accounts/$accountName. This call shows the cash-out address of $account that is *always* the payment destination.
(0019824)
sebasjm   
2023-02-13 19:40    		Sandbox should show historical information about where the money went.
If the account destination is taken from the account details endpoint then the information about where the cash went is lost after the user updates his/her account.
(0019834)
MS   
2023-02-14 15:24   
(Last edited: 2023-02-14 15:24) 		implemented here: aec39ac06ca56.. Documentation updated accordingly

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7663 [Taler] General minor have not tried 2023-02-07 20:49 2023-04-13 20:26
Reporter: sebasjm Platform:  
Assigned To: MS OS:  
Priority: normal OS Version:  
Status: resolved Product Version: Git master  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: sandbox does not allow patch as cors method
Description: and some method are just available under patch method
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019846)
MS   
2023-02-15 11:21    		addressed here: aec39ac0..18126f19

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7802 [Taler] exchange API (C) major N/A 2023-04-13 12:48 2023-04-13 17:31
Reporter: Christian Grothoff Platform: i7  
Assigned To: Christian Grothoff OS: Debian GNU/Linux  
Priority: urgent OS Version: squeeze  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: wire fee signature not validated in libtalerexchange
Description: We validate the signature on the accounts, but not on the wire fee. Should be implemented.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0020086)
Christian Grothoff   
2023-04-13 17:31    		Fixed in 4e9c4395..eb2b4a13

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7790 [Taler] merchant-pos-terminal (Android App) major have not tried 2023-04-04 13:52 2023-04-11 19:45
Reporter: grote Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Try again to get payment status, after connection fails
Description: We already increased the timeout to something like unlimited, but we still do not re-try to make the connection when it fails due to network issues.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020008)
Christian Grothoff   
2023-04-04 15:03    		Just to clarify: having an *abort* button is of course OK, so there should be a way for the user to explicitly give up. My remark was just that until that happens, the PoS app should keep trying.
(0020078)
grote   
2023-04-11 19:45    		https://git.taler.net/taler-android.git/commit/?id=7e8d39aa6f7a97ae14cb90db12f3ab83c9c5a343

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7750 [Taler] exchange minor have not tried 2023-03-07 18:18 2023-04-11 19:16
Reporter: MS Platform:  
Assigned To: MS OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: taler-exchange-wirewatch ignores the -f option
Description: That causes requests to Nexus /history/incoming to lack the long_poll_ms parameter.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019927)
Christian Grothoff   
2023-03-07 21:20    		I've inspected the code (visually), and it seems to CLEARLY set the timeout, except for two key cases:
1) if we are in test-mode (-t), and
2) if we are going backwards in time

In both cases, using the timeout makes no sense and is correctly disabled. How exactly are you calling taler-exchange-wirewatch to conclude that '-f' is not respected?
(0019934)
MS   
2023-03-08 14:27    		with -t. Why is that disabled? What if users want to check that both client and server respect the timeout?
(0019935)
Christian Grothoff   
2023-03-08 14:29    		-t is test-mode, where the service is supposed to exit when no more work is available, not "hang around". So long polling doesn't make sense in test-mode.
(0019936)
MS   
2023-03-08 14:39    		Also, the help message is unclear about the unit of time being expected by -f. Below is the relevant --help part:

  -f, --longpoll-timeout=DELAY
                             what is the timeout when asking the bank about
                               new transactions

After some tries, it seems that -f N translates to a long_poll_ms of N/1000.

This command:
$ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f 100000

Causes this request:
GET /facades/test-facade/taler-wire-gateway/history/incoming?delta=1024&long_poll_ms=100

Is that intentional?
(0019937)
Christian Grothoff   
2023-03-08 14:49   
(Last edited: 2023-03-08 14:50) 		Yes. Note that you probably want to use

$ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f "100 ms"
$ taler-exchange-wirewatch -c wirewatch.conf -L DEBUG -f "30 s"

etc, just like we usually do when passing time values. Without any unit, it is microseconds and hence correctly divided by 1000.
(0020075)
MS   
2023-04-11 19:15    		Ack. for the clarification and yes, without "-t" wirewatch sends the long_poll_ms parameter.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7680 [Taler] sandcastle (containerized demo deployment) minor have not tried 2023-02-12 20:45 2023-04-11 18:29
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: demo survey tipping should be topped up automatically
Description: We have the tooling (see sandcastle README), but there needs to be some container with a systemd timer or similar mechanism to regularly create a new tipping reserve.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7705 [Taler] sandcastle (containerized demo deployment) minor have not tried 2023-02-19 14:20 2023-04-11 18:29
Reporter: Florian Dold Platform:  
Assigned To: javier.sepulveda OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: exchange ToS not properly configured in the sandcastle exchange
Description: Some configuration settings is missing here.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6591 [Taler] wallet (Android App) minor have not tried 2020-09-08 23:10 2023-04-11 18:26
Reporter: Florian Dold Platform:  
Assigned To: avalos OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Android wallet should support aborting partially failed payments
Description: The wallet-core API now supports aborting failed payments (and obtaining a refund of partial spends) via "abortFailedPayWithRefund".

See 0006590 for general UX issues regarding this, especially for what happens if this refund fails (currently if will be retried "infinitely" with increasing retry timeout).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017004)
Florian Dold   
2020-10-08 17:08    		Based on Mumble discussions: We should avoid making this too complex in the UI.

=> A pending payment should have one "cancel" button, and the "abortFailedPayWithRefund" should be replaced with a simpler "cancelPayment" method that "does the right thing" and recovers as much funds as possible.
(0019858)
Florian Dold   
2023-02-17 02:35    		We now have a generic "abortTransaction" request and DD37 specifies the transaction lifecycle.
(0019872)
avalos   
2023-02-17 21:01    		What's the first version of wallet-core to support it?
(0019883)
Florian Dold   
2023-02-19 23:32    		0.9.1 definitely supports it
(0020073)
avalos   
2023-04-11 18:26    		This pretty much depends on DD37, which I'm already working on implementing in `dev/ivan-avalos/dd37` branch. I still need some wallet-core features to be implemented before I can finish my client-side DD37 work, but once it's all done, it will be possible to abort partially failed payments, only when DD37 says it's possible.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5867 [Taler] wallet (WebExtension) minor have not tried 2019-08-31 14:23 2023-04-11 18:04
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: interaction between refunds and payment re-play unclear
Description: When an article is refunded and the merchant offers to pay for a new instance of it (with a new order ID), the wallet will still try to replay the payment for the refunded payment. This will just lead to the "can't view article, it has been refunded" page of the merchant.

The wallet should probably provide some escape hatch and offer the user to make a payment for the new contract in case there is a refund for the matching old payment.

All these cases should be written down somewhere, also to make it easier for merchants.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019866)
sebasjm   
2023-02-17 15:09    		I think that we may want to have 2 kind of order/payment/refund interaction.

(a) Fungible asset: like the right to read the article in the demo
 * Any paid order will work
 * Having a refunded order is like no having an order at all
 * If no order or order refunded, show the paywall

(b) non-Fungible asset: like buying a drink online
 * There is 1-to-1 match between an order an a product
 * The merchant need to see the order to know which product is
 * If the order is refunded, is ok for the merchant to inform that this product is no longer accessible

I think the demo shop example is (a) but behaving like (b)
(0020026)
Florian Dold   
2023-04-05 17:36    		Assigning to Sebastian as he's currently looking over DD7.
(0020072)
Florian Dold   
2023-04-11 18:04    		From the discussion with Christian and Sebastian: This is something we need to address before 1.0, but we need to address this without introducing some completely new feature.

Maybe the wallet just needs to disable repurchase detection when there is a refund.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7760 [Taler] wallet (Android App) major always 2023-03-09 15:21 2023-04-11 16:39
Reporter: sebasjm Platform:  
Assigned To: grote OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: making a deposit with lower case country (in the IBAN field) throws an error
Description: The UI allows to send the deposit.
The deposit then fails because the exchange throws 404

Log

03-09 10:56:10.069 29726 29759 V taler-wallet-backend: got back response: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "response",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "operation": "getPendingOperations",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": 168,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "result": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "pendingOperations": [
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "exchange-update",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": "exchange-update:http:\/\/exchange.taler\/",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isDue": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "timestampDue": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678372689000
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isLongpolling": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "givesLifeness": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "exchangeBaseUrl": "http:\/\/exchange.taler\/"
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "exchange-check-refresh",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": "exchange-update:http:\/\/exchange.taler\/",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isDue": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "timestampDue": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678455489000
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isLongpolling": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "givesLifeness": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "exchangeBaseUrl": "http:\/\/exchange.taler\/"
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "exchange-update",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": "exchange-update:https:\/\/exchange.demo.taler.net\/",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isDue": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "timestampDue": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678372663000
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isLongpolling": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "givesLifeness": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "exchangeBaseUrl": "https:\/\/exchange.demo.taler.net\/"
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "exchange-check-refresh",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": "exchange-update:https:\/\/exchange.demo.taler.net\/",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isDue": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "timestampDue": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678455463000
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isLongpolling": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "givesLifeness": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "exchangeBaseUrl": "https:\/\/exchange.demo.taler.net\/"
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "type": "deposit",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "id": "deposit:BMREECH4CM2187PKTZT6WJTKYQES4ZEWMCRN4NZEX4M025D6FNCG",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isDue": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "timestampDue": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1.678370181094625E12
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "isLongpolling": false,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "givesLifeness": true,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "depositGroupId": "BMREECH4CM2187PKTZT6WJTKYQES4ZEWMCRN4NZEX4M025D6FNCG",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "lastError": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "code": 7005,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "when": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678370169701
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "hint": "Unexpected HTTP status 400 in response",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "requestUrl": "http:\/\/exchange.taler\/coins\/2M7G9JJRKMF1AM5PRKP1B8H9RCC858FWZDD4J37K3VXEB2PD1CMG\/deposit",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "requestMethod": "POST",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "httpStatusCode": 400,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "errorResponse": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "code": 26,
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "hint": "A parameter in the request was malformed.",
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "detail": "Country code `de' not supported\n"
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: }
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "retryInfo": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "firstTry": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1678370133368
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "nextRetry": {
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "t_ms": 1.678370181094625E12
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: },
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: "retryCounter": 6
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: }
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: }
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: ]
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: }
03-09 10:56:10.069 29726 29759 V taler-wallet-backend: }
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019943)
grote   
2023-03-09 17:43    		What's the fix here? Force all characters in the IBAN to uppercase? Or show an error to the user if they enter lower-case?
(0019944)
sebasjm   
2023-03-09 19:15    		The exchange will fail to validate the iban using this https://git.taler.net/exchange.git/tree/src/util/iban.c

There is a country table and a checksum validator.

Forcing uppercase seems ok, i think.
(0019955)
grote   
2023-03-10 21:33    		A C validator? Shouldn't it be the job of wallet core to validate/fix those?

However, I can do uppercase for now.
(0019971)
grote   
2023-03-21 17:47    		So I did uppercasing, but entering random stuff now gives me an IBAN checksum is wrong error. I would really expect wallet-core to have a validator method for wallets instead of each wallet having to implement their own.
(0019990)
Florian Dold   
2023-03-29 21:07    		As discussed on Mattermost, wallet-core v0.9.3-dev.10 now supports the "validateIban" request.
(0020068)
grote   
2023-04-11 16:39    		IBAN gets validated in https://git.taler.net/taler-android.git/commit/?id=f5aced13fda3132d5ee3a6947fe95f7b7b22b98a

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7799 [Taler] wallet-core feature always 2023-04-11 16:04 2023-04-11 16:04
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: wallet-core should be more lazy with downloading exchange /keys
Description: Downloading and validating the /keys response is resource-hungry when we have many built-in exchanges.

Also, it makes network requests without direct user interaction, see https://gitlab.com/fdroid/fdroiddata/-/issues/2964
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7728 [Taler] wallet (Android App) minor have not tried 2023-02-24 19:58 2023-04-10 22:45
Reporter: Florian Dold Platform:  
Assigned To: avalos OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: "confirm with bank" button stays in transaction history even when withdrawal is complete
Description: Something is not updated correctly here.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019910)
avalos   
2023-02-28 17:15    		What do you mean by “transaction history”? The transactions list? As far as I know, the “confirm with bank” button hasn't been merged there yet. Currently, it is only present in the transaction details.
(0019911)
avalos   
2023-02-28 17:20    		Nevermind, the “confirm with bank” button was already merged. However, there's a pending refactoring of the button. Now I'm using a Jetpack composable for the button, and it has improved logic.
(0019912)
avalos   
2023-02-28 17:35    		I can confirm that the new composable action button is updating correctly.
(0019974)
grote   
2023-03-21 22:18    		@avalos do we need to merge anything to resolve this? Are composable versions of this button strictly needed for the fix?

@florian I remember that Christian wasn't so keen on having that button in the transaction list at all. Maybe easier to just remove it?
(0020016)
Florian Dold   
2023-04-04 18:26    		Decided today on Mumble: We leave out the button in the transaction list. Instead we show a badge, ideally based on the state and substate when DD37 support is available in wallet-core.
(0020043)
avalos   
2023-04-10 08:39    		I removed the action button from the transaction list in dev/ivan-avalos/master, please give it a check. I still think it would be a good idea to put the composable action button in the transaction details, as it has a more flexible handling of user actions, and it won't affect performance noticeably in the release version, as things are significantly optimized.
(0020057)
grote   
2023-04-10 22:45    		Buttons was removed in c2283c02428005a8ce0dc00df72535e27f7892d9

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7673 [Taler] wallet (WebExtension) minor always 2023-02-10 16:58 2023-04-10 16:46
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: unable to reproduce  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: retry on kyc shows an error
Description: when doing a retry the last error of the operation is shown in the global error message.

should this be hidden since it is going to be shown in the tx error?

something should be done to prevent duplicate error message
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Selection_410.png (54,862 bytes) 2023-02-10 16:58
https://bugs.gnunet.org/file_download.php?file_id=1358&type=bug
png
Notes
(0020055)
sebasjm   
2023-04-10 16:46    		could not reproduce in the latest version

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7568 [Taler] wallet (WebExtension) minor have not tried 2023-01-12 16:28 2023-04-10 16:44
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: implement the new semantic of aborting/cancel/forgetting/resuming a tx
Description: check the extendedStatus field
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019835)
sebasjm   
2023-02-14 15:33    		https://git.taler.net/docs.git/tree/design-documents/037-wallet-transactions-lifecycle.rst

If aborted is an end state, resuming a aborted tx should create a new one.
WDYT?
(0019853)
Florian Dold   
2023-02-16 22:24    		I don't think "aborted" should be an end state. Having multiple versions of basically the same transaction would be very confusing.
(0019864)
sebasjm   
2023-02-17 13:53    		Well, my argument for using aborted transaction as and end state is because running again the transaction may be done based on different conditions and the old aborted tx have important information that should not be lost.

Maybe we should put some examples

 * On withdraw, the transaction may be aborted from the bank or from the wallet. This information need to be saved. If the withdrawal was initiated from the bank, resuming won't be possible because I understand resuming the withdrawal as creating a new manual withdraw.
 * Aborted transfer or invoices can't reuse purse, so it will need to pay that fee again. Am I correct?
* Aborted payment, when restarted again, will have different contract. Old payment tx will have the amount spend (fees) and refund associated.
(0019865)
Florian Dold   
2023-02-17 14:51    		I think the details in DD37 should clarify this.

All your examples would be non-resumable aborted transactions, so effectively we *are* creating new transactions in these cases. It just has nothing to do with the resume mechanism. So we practically agree here?

The only place where resuming aborted transactions makes sense if the abort wasn't destructive. For example, aborting a withdrawal where the money was already wired.
(0020054)
sebasjm   
2023-04-10 16:44    		Closing this since DD37 is in progress

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7741 [Taler] wallet-core major have not tried 2023-03-05 02:15 2023-04-10 16:42
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: "continue with mobile wallet" flow doesn't work for payments
Description: When I pay with my mobile phone for an order (blog shop demo) that was claimed by the WebExtension wallet (after showing the QR code with the "continue with mobile wallet" link), nothing happens in the WebExtension.

Instead, I would expect the WebExtension to also navigate to the now paid article.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020053)
sebasjm   
2023-04-10 16:42    		same as withdrawal, there is no transaction yet and wallet-core is not polling the state of the payment

this is going to be fixed with the implementation of DD 37

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6907 [Taler] wallet-core minor have not tried 2021-06-22 13:14 2023-04-10 15:50
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: operations should support cancellation tokens
Description: The wallet implementation currently doesn't handle cancellation and timeouts nicely. Most operations should take a cancellation token and pass that to other operations that are invoked.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018985)
Florian Dold   
2022-08-02 18:10    		To clarify: When the user clicks "Delete" on a transaction, any asynchronous work related to that transaction in wallet-core should be cancelled. This is not strictly needed for correctness, but is overall nicer behavior.
(0020052)
sebasjm   
2023-04-10 15:50    		this issue needs to be reviewed.

I think is covered by DD 37

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7719 [Taler] wallet (WebExtension) major always 2023-02-23 15:50 2023-04-10 15:41
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: withdraw call to action should check if mobile withdrawal has been initiated
Description:  * set "Automatically open wallet based on page content"
 * initiate a withdrawal
 * choose "withdraw to a mobile phone"

Complete the withdrawal with the mobile

webex should update and move to the bank confirmation page.

When the confirmation is done with the browser, mobile app should then be updated (do not ask again for "confirm with the bank")
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020051)
sebasjm   
2023-04-10 15:40    		this will be fixed with the implementation of DD 037

there is no polling in the withdrawalgroup (to the bank status) because there is not transaction/operation yet in the wallet.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7533 [Taler] wallet (WebExtension) major always 2022-12-25 18:49 2023-04-10 15:38
Reporter: davidak Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 0.9  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Unable to add a new bank account to wallet
Description: So i can't get money back to bank.
Tags:
Steps To Reproduce: 1. Open wallet balance
1. Click "Send"
1. Put in amount like 5 and click "deposit" to bank
1. "There is no account to make a deposit for currency KUDOS"
1. Click "Add"
1. Fill out your bank details
1. "We can not validate the account so make sure the value is correct."
Additional Information: Wallet Core
0.9.0 673e7a417d043cd6b0644d2a7a52d1fdbc5345ee
Web Extension
0.9.0.35 673e7a417d043cd6b0644d2a7a52d1fdbc5345ee
Attached Files: Screenshot from 2022-12-25 18-43-54.png (43,415 bytes) 2022-12-25 18:49
https://bugs.gnunet.org/file_download.php?file_id=1288&type=bug
png
Notes
(0020050)
sebasjm   
2023-04-10 15:38    		fixed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7691 [Taler] wallet-core major always 2023-02-13 20:52 2023-04-10 15:36
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: getting refund in the demo frontend get refund = 0
Description: This may be due to the coins that the user had in the wallet.

Step to reproduce:
1- withdraw some coins
2- pay some articles
3- try to get some refunds

Refund fee will apply, given the low value of the article and relative high fee the total refund will equals to 0
Worse, the total refund may not be always the same (even if the article is the same price) since the coins may be small with relative high refund fee.

Exchange configuration:
# curl https://exchange.demo.taler.net/keys | jq '.denominations[] | {fee_withdraw, fee_deposit, fee_refresh, value}'

{
  "fee_withdraw": "KUDOS:0.01",
  "fee_deposit": "KUDOS:0.01",
  "fee_refresh": "KUDOS:0.01",
  "value": "KUDOS:0.1"
}
{
  "fee_withdraw": "KUDOS:0.01",
  "fee_deposit": "KUDOS:0.01",
  "fee_refresh": "KUDOS:0.01",
  "value": "KUDOS:2"
}
{
  "fee_withdraw": "KUDOS:0.01",
  "fee_deposit": "KUDOS:0.01",
  "fee_refresh": "KUDOS:0.01",
  "value": "KUDOS:10"
}
{
  "fee_withdraw": "KUDOS:0.01",
  "fee_deposit": "KUDOS:0.01",
  "fee_refresh": "KUDOS:0.01",
  "value": "KUDOS:1"
}
{
  "fee_withdraw": "KUDOS:0.01",
  "fee_deposit": "KUDOS:0.01",
  "fee_refresh": "KUDOS:0.01",
  "value": "KUDOS:5"
}

Here if what is remaining in the wallet is just KUDOS:0.01 then the refund is always be 0 !!!
Maybe the wallet should do a refresh?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020031)
Florian Dold   
2023-04-05 18:27    		This seems to be about the denomination structure of the exchange.

I'm not sure what wallet-core should do differently here or how refreshing would help.
(0020049)
sebasjm   
2023-04-10 15:36    		Agree that this may be more related to the exchange fee structure, but the experience is bad for the user since is unexpected. Trying to get a refund and the effective amount of the transaction is 0, not a refund. Bad exchange and wallet should handle it.

Maybe this can also be solved by with the help for the merchant => with the feature of the merchant being able to pay the refund fee.

Regarding the refresh operation, the situation in my mind was:
 * the contract was paid with a coin with high refund fee because coin-selection doesn't not optimize by refund_fee when doing a payment.
 * if the denomination to be refund is not the best, maybe it can be changed/refreshed before refund so it will pay less fee

This situation is possible:
 1 start a wallet with high amount
 2 create an order of low amount
 3 pay a refund
 4 go to 2

At the beginning, refund of the order will be X and after a while refund will be less (and maybe 0) even if the order is the same.
What change here are the coins being used to pay, smaller coins with higher relative refund fee.

Here, a refresh operation could make the refund stable? in terms of fees

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7452 [Taler] wallet-core feature have not tried 2022-11-14 02:58 2023-04-10 14:52
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: extend GetExchangeTos wallet operation to be reuse for backup or auditor
Description: Wallet will be accepting ToS from other service, it will be useful to reuse the same logic.

Currently I need something similar for backup providers.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019986)
Florian Dold   
2023-03-28 20:28    		I actually do not think that these operations are sufficiently similar enough to abstract them out.

The exchange ToS is human-readable text with an Etag, while the sync ToS is structured JSON without any versioning.
(0020001)
sebasjm   
2023-04-01 16:53    		What is the difference between the ToS that backup service provider and auditor uses?

Can we make a standard way of creating, serving, querying and displaying ToS for every service so we no need to build particular solutions for every service?

I think that the exchange implementation is good enough to be replicated, and we can reuse the same logic in the wallet (and ui)
(0020004)
Florian Dold   
2023-04-03 19:19    		The main problem here is that the ToS of different services (exchange vs. auditor vs. sync) do not share a lot of structure:

* auditor: do we even have ToS here yet?
* exchange: multi-language, multi-format human-readable document, ETag for version tracking
   (also, we might want to stop storing the ToS document, and only store which ETag was accepted by the user, as there's not a real need to review the exchange ToS while offline)
* sync: JSON format to explain fees of the service, unversioned

In general it's not a good idea to create an abstraction over things that are too different.
(0020042)
Christian Grothoff   
2023-04-09 21:46    		I'm confused by Florian's comment: the ToS of the different services use *exactly* the same code server-side, and should follow the same structure. Sure, the auditor doesn't yet have a ToS, but that's likely a matter of time. exchange, sync, merchant & anastasis, all use the same logic with ETag and support returning in format requested by the client. They are also all versioned, so the same abstraction makes sense client-side.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7672 [Taler] documentation text have not tried 2023-02-10 16:07 2023-04-09 20:06
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: spec wallet-core transaction lifecycle in a design document
Description: Based on the extendedStatus, we should document which transitions are possible and what they mean.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019825)
Florian Dold   
2023-02-13 19:42    		Generic states and transitions are documented, I'm waiting for feedback on that before documenting everything for the specific transaction types.
(0019856)
Florian Dold   
2023-02-17 02:18    		The basic spec of all transactions is done, but there are various "XXX" comments indicating questions, and the whole thing needs a few more passes and some review.
(0020041)
Christian Grothoff   
2023-04-09 20:06    		I've done an extensive pass over the document now. Note that I disagree with supporting auto-refunds in p2p payments, so they are left half-baked in the spec. Also likely tons of stuff left to discuss, but Florian's turn now :-)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7365 [Taler] exchange API (HTTP specification) feature N/A 2022-09-18 11:33 2023-04-08 10:02
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: KYC fee is never charged / not speced or implemented
Description: The taler-exchange-offline tool (already) has a means to specify a KYC fee, and in principle the "/kyc-check" endpoint could generate a 402 payment required for the KYC process. However, the detailed 402 response is unspecified and also not implemented.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019170)
Christian Grothoff   
2022-09-22 15:36    		There's now a high-level hint of the exchange possibly returning a 402 in the /kyc-check spec.
(0019224)
Christian Grothoff   
2022-10-18 19:17    		Discussion today: have different KYC fees per trigger.
(0019225)
Christian Grothoff   
2022-10-18 19:27    		Charge KYC fees either to reserve (incl. wallet's long-term reserve for balance trigger) or to outgoing wire amount.
(0019226)
Christian Grothoff   
2022-10-18 19:27   
(Last edited: 2022-10-18 19:28) 		As long as frees cannot be paid, transaction is simply on hold until KYC threshold is gone below or balance goes high enough to pay KYC fee.
(0019697)
Christian Grothoff   
2023-01-21 21:21    		Given that AML may trigger KYC, I think the _only_ case where we legitimately can and should charge a KYC fee is if a client explicitly asks for it -- e.g. because they want to get attributes signed for invoicing.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7271 [Taler] exchange API (HTTP specification) feature N/A 2022-07-05 11:27 2023-04-08 10:01
Reporter: Christian Grothoff Platform: i7  
Assigned To: OS: Debian GNU/Linux  
Priority: low OS Version: squeeze  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: exchange-to-exchange wad transfers are not implemented
Description: This is a feature for W2W payments across exchanges. Places in the code that are related are marked with this bug number.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7737 [Taler] merchant backend API (HTTP specification) feature always 2023-03-02 13:55 2023-04-08 10:01
Reporter: sebasjm Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: merchant with a wallet should be able to fill a reserve for tipping
Description: wallet support starting a deposit with a payto URI and right now it fills a contract with some empty values
but this deposit will make a wire transfer to the exchange without the reserveId

The exchange could detect if "merchant_payto_uri" in the DepositRequest of https://docs.taler.net/core/api-exchange.html#deposit is the same of the exchange account and then it could reuse some fields to get the reserve id (maybe the order_id?)

With this there is no need of a wire transfer and it make the transaction efficient
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019916)
Christian Grothoff   
2023-03-02 15:41    		Actually, we should use the P2P transfer feature for this. That requires then no changes at the exchange. All we need is for the merchant backend/SPA to generate an 'invoice' (pull payment request) using its tipping reserve private key!

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6952 [Taler] documentation text have not tried 2021-07-23 13:42 2023-04-08 10:00
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: document how public /pay handles refunded coins
Description: The current implementation allows them, but excludes the refunded amount from the total payment amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018008)
Florian Dold   
2021-07-23 14:18    		From our workshop discussion: The merchant should actually just *reject* /pay requests with refunded coins, as due to the exchange API, such payments can never work in the first place. Once a coin is refunded, it can't be spent on the same h_contract_terms again.

The merchant code should not accommodate with extra, complex logic for an input that will lead to an error at the exchange anyway.
(0020028)
Florian Dold   
2023-04-05 18:21    		Actually it turns out that the exchange doesn't properly document how /deposit handles refunded coins for the same h_contract_terms.

While trying to experiment with the exchange's behavior, I stumbled on 0007792.
(0020029)
Florian Dold   
2023-04-05 18:22    		Assigning to Christian to review the exchange docs for coin deposit/refund, which in turn informs the documentation for the merchant's /pay endpoint.
(0020040)
Christian Grothoff   
2023-04-08 09:59    		56e7647..991e5d2 clarifies the /deposit (and /batch-deposit) endpoints with respect to coin re-use.
991e5d2..a7dd26c clairfies the /pay endpoint hopefully making it clearer that you must not use the same coin-pub a second time for a purchase of the same contract after a /refund for the same purchase.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7267 [Taler] exchange major always 2022-06-30 10:31 2023-04-08 09:56
Reporter: oec Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.5  
Summary: TEH_make_coin_known needs proper conflict handling and evidence gathering
Description: Right now, TEH_make_coin_known calls TEH_RESPONSE_reply_coin_insufficient_funds in the cases TALER_EXCHANGEDB_CKS_DENOM_CONFLICT and TALER_EXCHANGEDB_CKS_AGE_CONFLICT. This is not correct because that function does not gather the required evidence for the noticed conflicts.

We need a new conflict resolver/evidence gatherer function for those cases. It must take into account the usage of the coin in deposits, p2p or refunds (and maybe other circumstances?)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0018951)
oec   
2022-06-30 10:33    		And we need test cases for those situations, too!
(0018952)
oec   
2022-06-30 10:40    		Also, other places that call TEH_RESPONSE_reply_coin_insufficient_funds might require similar treatment

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7747 [Taler] exchange minor have not tried 2023-03-07 13:13 2023-04-08 09:46
Reporter: Florian Dold Platform:  
Assigned To: Christian Grothoff OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 0.9.3  
    Target Version: 0.9.3  
Summary: sample exchange ToS HTML is giant
Description: For some reason, the ToS converted to HTML is unacceptable large (>600KB), when it is just simple, plain text.

It is so large, that it doesn't fit into one Android IPC message (with JSON encoding/escaping overhead)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019924)
Christian Grothoff   
2023-03-07 13:17    		Why does the Android wallet request the HTML version? It is so huge as it packs various JS+CSS to make it render nicely. The Android wallet should be asking for RST or TXT, not HTML!
(0019985)
Florian Dold   
2023-03-28 20:20    		One issue is that the exchange returns the giant HTML response *by default*, either when no "Accept:" header is specified, or there is no match for the requested content type.

But I currently don't understand why wallet-core is not requesting either "text/plain" or "text/markdown", I'll have to look into this.
(0019989)
Florian Dold   
2023-03-29 21:01    		Okay, so I've fixed a bug in qtart that caused *duplicate* "Accept: application/json" and "Accept: text/plain" headers to be added, which was clearly wrong.

However, I still think it's bad behavior of the exchange to default to returning HTML when there is no matching ToS for the requested MIME type or no Accept header was given.
(0019991)
Christian Grothoff   
2023-03-30 03:11    		Well, what do you think should be the default? HTML is usually the default for the Web, but I guess we could default to text/plain as well...
(0020039)
Christian Grothoff   
2023-04-08 09:46    		cbabddf0..677ac4a5 changes the default to text/plain.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7743 [Taler] demobank-ui minor have not tried 2023-03-05 02:22 2023-04-08 00:00
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: "Confirm with bank" flow does not work with current demobank-ui
Description: There is no way to tell the demobank-ui to continue with a certain withdrawal. Also, the confirm_transfer_url generated by the libeufin demobank doesn't contain any reference to the account that created the withdrawal operation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019987)
sebasjm   
2023-03-29 14:39    		changed required
 * sandbox should set `confirm_transfer_url` to [1] in these endpoints [2]
 * spa should show an message if it is confirming a transfer with an account different than the current user

optionally: if transfer_user !== current_user then ask password, this require sandbox to check of auth header when doing abort or cancel withdrawal operation

[1] https://docs.taler.net/core/api-bank-access.html#get-$BANK_API_BASE_URL-accounts-$account_name-withdrawals-$withdrawal_id
endpoint contains account name in the path
it will be nice to have the accountName in the response object so SPA will not need to parse the path and potentially break in the future (also remove /accounts/${account_name} from the enpodint)
endpoints (get, abort, cancel) do not require credentials so it will be possible to call them without asking for the password


[2] https://docs.taler.net/core/api-bank-integration.html#withdrawing
(0020021)
sebasjm   
2023-04-04 20:30    		new docs https://git.taler.net/docs.git/commit/?id=3273debb32a00825e7c77b8468d09d070ff8f9cd

which describe the new behavior of sandbox so confirm_transfer_url will have the withdrwal operation id that will redirect to the correct UI in the demobank SPA
(0020037)
sebasjm   
2023-04-08 00:00    		at 877a4bb1328661ae2e97d764c26e2bc0ff1f46fe

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6077 [Taler] wallet-core feature N/A 2020-02-04 22:13 2023-04-06 14:45
Reporter: Christian Grothoff Platform: i7  
Assigned To: Florian Dold OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: sync support needed in wallet core
Description: The operations that should be provided (here described as command-line options for the CLI wallet) are:

0) sync --info-by-url $URL: obtain fee structure and other high level terms (warranty, etc.)
1) sync --create $URL: setup a new sync account (and pay for it!)
2) sync --info: show meta data of current account (fees, paid until, warranty, etc.)
3) sync --show: display a URI (taler://sync/$URL/$SECRET) with the information needed to join a sync group / download a backup
4) taler-wallet-cli taler://sync/$URL/$SECRET: join the sync group (download, merge, upload to notify other members of join)
5) sync [nothing]: synchronize NOW with the active sync/backup service (try upload, if fail download, merge, upload)
6) sync --reserve $AMOUNT: reserve $AMOUNT money (in the respective currency) for *this* wallet
7) sync --leave ($AMOUNT)* leave the sync group, taking $AMOUNT funds out of the joint funds. $AMOUNT may be
   specified multiple times for different currencies.

Let me know if something is unclear, or extend/add to the list in case I missed something.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0016834)
Florian Dold   
2020-09-04 09:06    		The CLI for this looks mostly good to me (modulo questions below). Except that the "--..." options should actually subcommands. But that's a pervasive usability problem in many binaries of GNUnet and Taler, because the library we use in C for CLI parsing doesn't handle subcommands nicely </rant>.

Regarding starting the implementation of sync: what we actually need is primarily the wallet-core JSON API for all those things. I'll write these docs after we've clarified some other issues. The CLI will follow from that.

# 1. Balances

1.1 How does this affect the balance, both in terms of API and UI? WIll we only show the "reserved" amount?
1.2 Do balances now need to include some timestamp(s) that show how current they are? Sync otherwise might lead users into thinking they have more money than they actually do ...
1.3. How does this affect the coin selection for payments? What happens if the current wallet's reserved balance is too low, but the sync group's balance is high enough to pay?

# 2. Funds reservation

2.1 Does the funds reservation imply a sync, or is it only done locally? Do other devices somehow acknowledge the reservation?

# 3. Device identifiers and encryption

3.1. I'm assuming in the first implementation, a "rogue" device won't be able to be kicked out of the sync group, right? So we don't do any encryption with the some per-device key, we just use the sync key.

# 4. Payments

4.1. Does the user need to confirm the payment to create the sync group? What if the contract terms contain a different amount than what's advertised by the sync server?
4.2. Does the user need to confirm subsequent payments for the sync server to extend the service duration?
4.3. What happens if two wallets in a sync group pay to extend the sync service? Will the 402 always give the same order (=> other wallets receive "order already claimed)?
(0016836)
Christian Grothoff   
2020-09-04 10:06    		1.1: sync may cost money, if it does, it's a purchase.
1.2: I'd say no. We could store the # devices in the sync group, and if >1 we could do a GET request against the sync service at a reasonable frequency (say on Wallet start, unless started "just before"?). I'd not show a timestamp.
1.3: We grab from the sync group and POST to sync as soon as possible (but after the payment)
(0016837)
Florian Dold   
2020-09-04 11:38    		Regarding 1.1: This question wasn't related to how the *payment* for sync will show up, but how being in a sync group will affect the balance that is shown. Or to rephrase the question: How will reserving funds from the sync group affect the balance display?

Will it even affect the balance display / API response, or is it an internal thing completely transparent to the user, and just used to reduce (not completely prevent!) spending conflicts?
(0016838)
Christian Grothoff   
2020-09-04 12:55    		1.1: I'd say not at all. We should show the overall balance, sync groups should be managed "behind the scenes".
(0016849)
Christian Grothoff   
2020-09-04 14:49    		2.1: Funds reservation is 'soft' anyway, it just means that a wallet will preferentially spend certain coins over others. So I would say any wallet in a sync group can 'grab' a coin (or even assign it to another wallet in the sync group, i.e. on withdrawal), and the latest grab counts (so grabs must have: coin_pub + wallet_id + timestamp). I'd treat grabs like any other wallet-operation (withdraw, pay, refresh) in terms of sync behavior: randomized reduction in the time to the next backup per operation might be a reasonable strategy.

3.1: Why not have a header (encrypted with sync key) that has a list of all participating wallets and then a backup key encrypted *to* all wallet private keys, followed by the actual wallet data encrypted with the backup key? Sounds not too hard, and why not do it right immediately?

4.1a: Yes, but simply have the normal dialog contain the word "confirm payment" in the button and the amount next to it. No need for a 'full' regular pay dialog IMO.
4.1b: That's a protocol violation. Treat it as such and tell the user the sync server failed to respond properly.

4.2: I'd have a checkbox 'auto-renew'. If payment is not possible OR if auto-renew is off, 1 month before expiration we should have an alert on the main screen about the impending expiration of the backup enabling manual renewal.

4.3: We should always force a sync between auto-renew claiming and payment to prevent this. The sync server cannot tell if you want to extend by +1 year, so it will create a fresh order. So simply claim, sync, and if you do not find another claimed order in the DB, then pay (or pay the earliest claimed order in the freshly sync'ed DB).
(0016856)
Florian Dold   
2020-09-04 16:34    		2.1. brings me to the crypto. Why not just use a HKDF and libnacl/libsodium crypto_(secret)box? Pulling in AES (and using it in what mode? ;-) ) will add more, potentially unaudited dependencies and is *much* easier to use incorrectly.
(0016862)
Christian Grothoff   
2020-09-05 00:14    		2.1: nothing against HKDF+cryptobox for the 'inner layer', but we need some 'outer layer' to allow adding/removing wallets from the sync group, including telling a wallet that it has been removed. So I don't think we can do without some DH between each group member's private key and some ephemeral key chosen by the last wallet to publish the backup.
(0016958)
Florian Dold   
2020-09-10 08:09    		After thinking about it some more: How would the per-wallet key work with Anastasis? Isn't that fundamentally incompatible?
(0016959)
Christian Grothoff   
2020-09-10 09:19   
(Last edited: 2020-09-10 09:22) 		Easy solution: Imagine W1 / W2 / W3 are the per-wallet keys and A is the Anastasis key (A_priv in Anastasis) and the actual symmetric encryption key of the main wallet state is K.

Then, we could store W1_pub, W2_pub, W3_pub, A_pub and an _encrypted_ K in the sync data preamble encrypted with DH(W1,A), DH(W2,A), DH(W3,A).

Note that K can here not change on every encryption, so we'd need an additional IV (or IMO better: salt and KDF via salt) before encryption with traditional AEAD/GCM.

Kicking a wallet out of the device group requires changing K, and so a new Anastasis policy upload. But that is rare and thus should be Anastasis-compatible.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7793 [Taler] other minor have not tried 2023-04-05 18:40 2023-04-05 18:40
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: use token auth for SPAs instead of storing credentials plain-text in local storage
Description: What we currently do is obviously not very nice from a security perspective.

Instead of using the plain-text user/password credentials, there should be a /login endpoint that then returns a bearer token.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6954 [Taler] merchant backoffice SPA feature have not tried 2021-07-23 14:20 2023-04-05 18:37
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: none OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: post-1.0  
Summary: create sample deployment to test external authentication
Description: We currently have only tested the SPA with merchant-internal token authentication.

We should create a very simple test deployment (with fixed auth information in, say, nginx) to make sure that the SPA handles external auth properly (both conceptually and in the implementation).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3476 [Taler] wallet-core feature have not tried 2014-07-01 18:49 2023-04-05 18:36
Reporter: Florian Dold Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: confirmed Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: evil exchange testsuite
Description: There should be an "evil" exchange testsuite, which tries to trigger edge- or error cases in the customer implementation.

Preferably, the result of these test cases should be that the customer can always construct a cryptographic proof that demonstrates the exchange's failure. This is of course only possible for byzantine failures, and not for denial-of-service.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0012906)
Christian Grothoff   
2018-03-27 17:30    		With Twister, we now have in principle the infrastructure in place for this, but we naturally need to modify the (existing?) wallet tests to trigger the Twister at the right times. This sounds like it would be best done in May or June as a collaboration between Marcello and Florian.
(0013233)
Christian Grothoff   
2018-09-17 11:31    		Changing to be against wallet, as this is about testing the wallet and the wallet thus needs to do the required twister instrumentation. (Do we have a separate bug for the merchant backend? Do we need one?)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7270 [Taler] exchange API (HTTP specification) feature N/A 2022-07-05 11:25 2023-04-05 18:35
Reporter: Christian Grothoff Platform: i7  
Assigned To: oec OS: Debian GNU/Linux  
Priority: normal OS Version: squeeze  
Status: assigned Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.6  
Summary: extension support is not implemented everywhere consistently
Description: Places in the code related to where extension support is known to be missing are (to be) marked with this bug number.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0019353)
oec   
2022-11-04 14:02    		Commit 752f10273860d2496fc3eb1e03de6ad4451e7c0f and 680ae81d860eb9bde951a3f95c0da06c111b66f8 fixes most of the places, and tests pass.

Missing: add tests with policy_details set.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7498 [Taler] exchange API (HTTP specification) major always 2022-11-28 14:19 2023-04-05 18:34
Reporter: oec Platform:  
Assigned To: oec OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.0  
Summary: fee structure considerations (was: Incoherent calculation of fees during withdraw)
Description: With the latest wallet webextension (commit 3577227cc0ff0f9e0c422ae34c4407d88e98ec21) there is an inconsistency with the transaction fee calculation:

A withdraw amount of '10' leads to an transaction fee of '-0.13'.
A (higher) withdraw amount of '10.01' leads to a transaction fee of (only) '-0.01'.

Is this the result of a miscalculation or the fee-structure of the denominations?
Tags:
Steps To Reproduce: A)
1. On the withdraw form, I enter '10' as the value.
2. On the next dialog, I see '-0.13' as the transaction fee.

B)
1. On the withdraw form, I enter '10.01' as the value.
2. On the next dialog, I see '-0.01' as the transaction fee.
Additional Information: - exchange config attached.
Attached Files: 2022-11-28-141823_715x727_scrot.png (40,220 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1278&type=bug
png

2022-11-28-141747_681x742_scrot.png (44,078 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1279&type=bug
png

c.conf (5,030 bytes) 2022-11-28 14:19
https://bugs.gnunet.org/file_download.php?file_id=1280&type=bug
Notes
(0019485)
sebasjm   
2022-11-28 15:58    		Well, I see that if you wire transfer 10.01, the exchange will give you 1 coin of 10 with the fee of 0.1 (as seen in the config)

If you wire transfer 10, it will discount 0.01 for every coin used an that will depend on the configuration.

I don't see any bug here.
(0019486)
oec   
2022-11-28 16:20   
(Last edited: 2022-11-28 16:38) 		Here is why this is broken, IMHO:

1. A user enters '10' to receive an amount of '10' because he/she needs that much.
2. On the next dialog page the user sees that he/she won't receive '10' but only '9.87' due to fees of '0.13'
3. But the user wants _10_ not, 9.87, so goes back and enters '10.13' instead, to include the fees.
4. But now, surprisingly, the result is '10.11' and the fees seem to be _lower_ for a _higher_ amount.

As a user I find this incoherent. Why should the user care about the demonination-structure and additive model for fees in the exchange?

I think the following are potential, orthogonal solutions:

a) Add to the withdraw form an option to either _include_ or _exclude_ the fees in the amount to be withdrawn. That way, the user wouldn't be confused in first place.

b) Change the fee mechanism for withdraw in the exchange to be based on the total _amount_ to be withdrawn, not the particular _denominations_ needed for that amount.
(0019487)
oec   
2022-11-28 16:34   
(Last edited: 2022-11-28 16:34) 		... c) Make the fees for denomations additive: D1 = N*D2 => fee(D1) = N*fee(D2). The auditor can check that, too.
(0019496)
Christian Grothoff   
2022-12-05 10:34    		Well, let's see about (c):
1) Obviously, the lowest possible fee must be the lowest denomination, let's say that is 0.01 KUDOS.
2) Then for a 0.01 KUDOS coin, the deposit fee must be 0.01 KUDOS.
3) By your math, the fee for a coin of value X must then be X.
Consequently, you can only pay fees, but never merchants. See the problem?
(0019498)
oec   
2022-12-05 14:22    		Not if the fee(v) = q*v with 0 < q << 1 and we only round up to D_0 at the end of the calculation, no?

However, I agree that (b) and (c) don't discourage the withdrawal of many small denominations.
(0019499)
Christian Grothoff   
2022-12-05 14:35    		There are more problems with (c): the fees end up either too low for our business model (where microtransactions are where we can make real profits), or too high to be competitive with traditional payment systems for larger amounts. Imagine q=1%. Then for a 1cent transaction, you may make too little profit. But for a 1000 EUR transaction, your fee is already insanely high. Logarithmic fees are actually good for Taler, it makes us competitive in all markets.
(0019500)
oec   
2022-12-05 15:53    		That leaves option a) above.
(0020033)
Florian Dold   
2023-04-05 18:34    		I think we should write down these considerations somewhere outside of the bug tracker.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6548 [Taler] wallet-core tweak have not tried 2020-09-01 14:34 2023-04-05 18:32
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet should handle (accidental!) double spending and have integration test for it
Description: ... which can be caused by a restore from backup.

The wallet should respond appropriately.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
6016 [Taler] wallet-core minor have not tried 2019-12-26 21:43 2023-04-05 18:32
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet should recover from payments where the exchange reports an invalid coin
Description: These cases include:

 * coin is double-spent
 * coin is of a denomination that is not offered by the exchange anymore (due to exchange DB reset)

The wallet has to report this error and offer the possibility to re-try the payment using a different set of coins (if balance is sufficient).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0017845)
Florian Dold   
2021-05-12 16:28    		The double-spending scenario is now covered and has a test case. The "selected denomination is now outdated" scenario still needs a test case.
(0019039)
Christian Grothoff   
2022-08-25 20:46    		P2P payments still need to worry about this as well.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7701 [Taler] wallet-core minor have not tried 2023-02-17 12:57 2023-04-05 18:29
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: implement abort semantics from DD37 for withdrawals
Description: This will lead to clearer messages in the UI with regards to what happens when a withdrawal is aborted (or deleted afterwards).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7687 [Taler] wallet-core major always 2023-02-13 20:23 2023-04-05 18:29
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: high OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: cancel withdrawal from wallet when withdrawal in progress should not lose money
Description: First case (a)

 1.- initiate a bank withdrawal
 2.- upon math challenge, abort the withdrawal
expected: wallet shows "operation was cancelled by the bank"
current: forever pending

Doing the same operation with manual withdrawal: it make sense to cancel the operation from the wallet since it was initiated by the wallet.
No change needed

Second case (b)

 1.- initiate withdrawal (bank or manual)
 2.- complete the challenge, confirming the wire transfer
 3.- abort the operation in the wallet
expected: exchange returns what was not withdrawn from the wallet
current: no message is shown to the user of the bank that the money is going to be back, this should also consider the scenario that the wallet never withdraw the money and the reserve is timed out
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020032)
Florian Dold   
2023-04-05 18:29    		The two cases described here are just 0007435 and 0007701

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7319 [Taler] exchange API (HTTP specification) feature always 2022-09-02 22:04 2023-04-05 18:25
Reporter: sebasjm Platform:  
Assigned To: Florian Dold OS:  
Priority: low OS Version:  
Status: resolved Product Version: git (master)  
Product Build: Resolution: duplicate  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: The sender should be able to cancel an invoice or transfer before the recipient pays or withdraws
Description: As a sender of a transfer, I want to be able to cancel and get the money back (without fee) before the recipient withdraws
As a sender of an invoice, I want to be able to cancel and avoid the contract to be paid before the recipient pays.

From email discussion:

"we could add a DELETE endpoint to the exchange for this. But, a
bit tricky: we'd need the wallet to do a long-polling GET while showing
the pending transaction anywhere in the UI to notice removal and then
hide it. Also, if we truly DELETE on the exchange side (which seems
best), we'd have no data to share with the recipient (or auditor) about
the deletion, so we'd only have the refresh fees (and a malicious actor
may not refresh) and maybe the purse fees"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019545)
Christian Grothoff   
2022-12-30 00:36    		Exchange part is done, next is wallet-core.
(0020030)
Florian Dold   
2023-04-05 18:25   
(Last edited: 2023-04-05 18:25) 		There are separate bugs open now for the implementation in wallet-core (0007584 and 0007583), so let's mark this one as resolved, as it was originally about the exchange.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7584 [Taler] wallet-core feature have not tried 2023-01-13 02:35 2023-04-05 18:25
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: implement aborting p2p pull payments
Description: This should use the new API from the exchange.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7561 [Taler] qtart feature have not tried 2023-01-10 15:35 2023-04-05 17:44
Reporter: Florian Dold Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.4  
Summary: make taler-wallet-cli runnable under qtart
Description: Some small helpers are still missing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019851)
Florian Dold   
2023-02-16 13:59    		Almost done, it works but the native taler-wallet-cli should still be added as an optional build target to the quickjs-tart build system.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7100 [Taler] wallet-core minor have not tried 2021-11-20 12:13 2023-04-05 17:43
Reporter: ms-mantis Platform:  
Assigned To: Florian Dold OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: Suggested exchange expected, in contrast to it being optional.
Description: The Bank Integration API specifies the "suggested_exchange" field of the "GET /withdrawal-operation/$id"
as optional. The wallet however interrupts one withdrawal in case this information is missing.

Logs:

withdrawInfo {
  amount: 'EUR:5',
  defaultExchangeBaseUrl: undefined,
  possibleExchanges: []
}
no suggested exchange!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020027)
Florian Dold   
2023-04-05 17:43    		Fixed in 451400b3a. The taler-wallet-cli handle-uri subcommand now accepts a --withdrawal-exchange option.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7473 [Taler] wallet (Android App) minor always 2022-11-17 18:20 2023-04-05 17:35
Reporter: sebasjm Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: feedback Product Version: git (master)  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: The app should navigate to the article after payment: (I need manually go back)
Description: If the user is using mobile to read the articles on demo and tries to read one the wallet opens with the payment dialog.

After the payment is completed, the user should be redirected to the article again.

From an email

> Yes, open fulfillment URL in browser. However, there is a small issue:
> if I scanned the QR code from a desktop-browser, we'd open the URL in a
> different browser (and the session-bound payment is bound to the browser
> on my desktop!). So we shouldn't auto-navigate here at all, and merely
> go to the page with the order details where the user can click on a
> button to open the page.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0019435)
grote   
2022-11-17 18:33    		I am not sure I understand. The quoted text says "we shouldn't auto-navigate here at all", but you want to auto-navigate after payment?
(0019438)
sebasjm   
2022-11-17 20:03    		The comment is describing a scenario when the QR code is scanned from the android wallet but the article is going to be read in the desktop.

So, from the desktop:
 - go the shop
 - try to read an article
 - the qr code is shown
 - pay it with the mobile wallet
 - after being paid the wallet should show the tx is completed
 - the shop in the desktop browser should detect that the order has been pay and render the article

Here the article is not shown in the mobile browser.

Alternative scenario is when the article is being accessed from the mobile browser, pay and the the wallet should redirect again to the article.
(0019440)
grote   
2022-11-17 20:41    		So you want after all payments that the Android wallet opens the fullfillment Uri without asking?
(0019443)
sebasjm   
2022-11-18 16:37    		You mean like "you are going to be redirected to" type of question?

Maybe, I'm not sure. In the first scenario (when the redirect needs to be made, reading from mobile and paying with the same device) the user is coming FROM the article to the wallet to pay. It sounds reasonable that the user will want to go back to the article and the fulfillment url will redirect the user to that.
(0019583)
grote   
2023-01-05 21:27    		OK, but how do we reliably detect that the user is coming from an article they want to go back to? On Android, we don't get informed by the browser where the user is coming from, so we only see the taler:// Uri. Maybe there's something in that Uri that indicates the desire to auto-go-back to fulfillment?

Btw. a feature like this could have security implications as you can force the user to visit a certain site.
(0019593)
Christian Grothoff   
2023-01-06 14:58    		I see. Yes, I guess we should add an argument to the taler://-URI that tells the mobile phone that it scanned a QR code on an 'external' system and thus should not navigate back itself. Something like "?nav=yes" would do, right? The QR code is where we need things to be compact, so there I would leave it out. I think the merchant can easily be modified to append such an argument when offering a link for clicking.

All agree?
(0019605)
sebasjm   
2023-01-07 14:59    		I prefer not to add an extra parameter in QR more, there should be a default behavior that cover both use cases in a good enough experience.

My suggestion:
 * after payment is done we add a successful payment screen with
  -- "ok" button (go back to the wallet)
  -- "close" (close the wallet)
  -- "continue to" (follow the fulfillment url)

That I think solve what grote raise as security issue (we are not redirecting without user consent)
Also, in the use-desktop-pay-with-mobile scenario the user will see the successful screen, the browser will reload showing the article, and can use the "close" button (since the wallet is just being summoned for the payment)
If the scenario is navigating-with-mobile-and-payment, the "continue to" button or link will redirect to the article using the fulfillment url

The "ok" button there if the user want to check balance before closing.

What about that? (main idea: convention over configuration)
(0019606)
Christian Grothoff   
2023-01-07 17:24    		Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error. So telling the wallet that the payment is for an article on another device (media-break) is an important hint to drive the right UX.

I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-).

Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile. Here, we'll need to open the browser, the browser will trigger the wallet, and then the wallet's repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser.

Still, with my extra taler://-URI argument, all of this is possible and we don't show the user 'strange' paths that don't work.
(0019607)
sebasjm   
2023-01-07 22:35    		> Not good, as 'continue to' would be shown but would NOT work! The payment is session bound, so the browser would open but shown an error.
Well, this is bad.
AFAIK the merchant front-office has a volatile session that is used to bound the payment with the article, if that session is lost the user will need to pay again?

If I ever payed for an article I would like to go back again even if I lost the session, isn't? That would mean that fulfillment URL should work in any setup. Like carrying the orderId and a prove of ownership in the request params (session-less)

> Now, the really funky case is where the user opened in a browser, paid by mobile, and then _later_ wants to go back to the article on the mobile.
This seems equal to the "continue to" plus a delay before clicking.

> I'm not sure the redirecting without user consent is an issue. The user consented to actually spend money already. If I can get you to do that, it's probably OK if I can ask you to open a web page ;-)

Sending a user to another app or external site (other than the wallet) should be warned.
Merchant input should be considered untrusted from the wallet perspective and this lead to open-redirect issues
https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

> repurchase detection has to change the payment in the merchant backend to the new session on the mobile and go back to the browser
I don't have very clear how the repurchase work. Is this some missing feature what you are describing?
(0019608)
Christian Grothoff   
2023-01-07 23:01    		Repurchase detection is exactly the feature you are looking for, and is implemented. Basically, if you did already pay for an article, but in a different session, you are first asked to pay again. But once you try, the wallet detects that you did already pay before, and simply proves to the merchant that you paid before, and asks the merchant to change the session ID on the purchase to the current session. BUT what this means is that if the user switches devices, they will get asked to pay again first, and have to scan the QR code with the wallet (or see some jumping around if the browser can auto-trigger the wallet) to allow the wallet to see the repurchase and rebind the session.
(0020025)
Florian Dold   
2023-04-05 17:35    		I don't think that Christian's approach can work. How would the merchant decide whether it is a "media break" or not?
When I click on an article in the blog demo, the merchant doesn't know whether I'm gonna pay with the browser wallet or the phone wallet.

I'm proposing a different user experience: When going to the fulfillment URL, the merchant checks if there is a session mismatch.
If the session matches, the article is rendered.
On a mismatch, it offers to instead view the article in this browser. It then shows the QR code page.

That's one more step, but it IMHO makes the user experience much clearer.

And maybe the wallet can also add additional information to the fulfillment URL to make clear that this is a repurchase.

IMHO we need to go back to the drawing board for the blog shop article, because it's currently both horribly complicated *and* not fully working.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7791 [Taler] wallet (WebExtension) minor have not tried 2023-04-05 11:10 2023-04-05 17:06
Reporter: Florian Dold Platform:  
Assigned To: sebasjm OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 0.9.3  
Summary: wallet UI should show better error message when suggested exchange is not reachable
Description: Right now, when we are:
* withdrawing the first time and do not have an exchange for the currency yet, and
* the exchange is not reachable

the wallet shows a rather confusing error message, namely that there is no matching exchange *and the bank did not suggest one*, even though that is false.

Instead, we should show that we can't contact the exchange.

This might need some wallet-core support to get error messages from contacting possibly relevant exchanges.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0020024)
sebasjm   
2023-04-05 17:06    		8eee38d55936c194637ecead302dde69ec0b9897

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
7740 [Taler] wallet-core minor always 2023-03-05 02:11 2023-04-05 11:07
Reporter: Florian Dold Platform: