View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009282 | Taler | wallet-core | public | 2024-10-19 12:21 | 2024-10-22 15:29 |
| Reporter | MarcS | Assigned To | Florian Dold | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Target Version | 0.14 | ||||
| Summary | 0009282: prepare... functions need to return scope: ScopeInfo in the result struct | ||||
| Description | When the user scans a QR code, we parse it, and call preparePeerPushCredit / preparePeerPullDebit / preparePayForUri / preparePayForTemplate... depending on the command. All these calls return an amount to receive or to pay, and a baseURL, but none returns a ScopeInfo. My current code takes the currency name of the amount to query getCurrencySpecification - but if two exchanges use the same currency name but with different currency specs, we might render the amount with the wrong spec. getCurrencySpecification was updated to take a ScopeInfo as input parameter - but we don't have that. Thus the prepare... functions need to return scope: ScopeInfo also. While you're on it, deprecate the returned baseURL (since it's either already a part of the ScopeInfo, or not needed). | ||||
| Tags | No tags attached. | ||||
|
|
Either startRefundQueryForUri (which currently only returns a transactionId), or getTransactionById must also return a ScopeInfo. Same reason: amount.currencyStr is NOT sufficient for getCurrencySpecification. |
|
|
There's one problem for calls like preparePayForUri: Payments to merchants might result in "mixed" scopes with multiple exchanges that are both accepted by the wallet but can't be represented by a single scope in the wallet. This is rare but we need to think about how we handle this. Let's say I set up my crazymerchant.fdold.eu that accepts both the exchange.taler.gls.de and fake-eur.fdold.eu If my wallet has both EUR (global) and EUR (fake-eur.fdold.eu) and a merchant accepts a payment with money from both, it's unclear what wallet-core should return or what the UI should display. One way to handle this would be to use scopeInfos: ScopeInfo[] for transactions where this can happen and show the transaction both when the user views EUR (global) and EUR (fake-eur.fdold.eu). But a single scopeInfo does not work in these cases. @Marc please comment whether scopeInfos would work for you (in the *response*, not as a restrictScope parameter). |
|
|
UI: similar to the new actions (send/request ...) - have a dropdown menu at the top of the screen so the user can choose which scope to pay with. As in actions, we can show the available amount for each scope. However, this doesn't work if the amounts of each scope are lower than the requested amount, and the payment must therefore use coins from multiple scopes for a single payment. For THAT use-case we need a whole new UI where the user can enter how much to spend from each scope - e.g. with sliders. The user drags one slider higher to increase the amount, and the other slider(s) automatically decrease, so the sum stays constant. That way we could also deal with the case where multiple currencies with different rates are used. Imagine the dealer asks for either 10€ or $12: 0€ 10€ |------------<>--------| 6.00€ $0 $12 |--------<>------------| $4.80 The user can drag the € slider to 6.00€ and the $ slider would automatically slide to (40% of $12) $4.80... API: yes, a list of scopeInfos to populate the dropdown would work. But the requested amount must be tied to the scope, so we don't need an array of scopes, but a dictionary of [scope : details] where for each scope the details has at least the amount to pay in that currency (and probably more fields). |
|
|
@Marc let's file the part with the sliders under post-1.0. For the pre-1.0, in the rare case that a transaction will have multiple scopes, it'll simply show up in both scopes' transaction lists with the same amount. Note that in the transaction list entry and preparePayForUri response, the field is called "scopes", because in the transactions list entry the field was already present (implemented by Sebastian previously). |
|
|
Scopes be supported by all relevant requests / responses now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-10-19 12:21 | MarcS | New Issue | |
| 2024-10-19 12:21 | MarcS | Status | new => assigned |
| 2024-10-19 12:21 | MarcS | Assigned To | => Florian Dold |
| 2024-10-20 12:16 | MarcS | Note Added: 0023547 | |
| 2024-10-21 19:05 | Florian Dold | Note Added: 0023554 | |
| 2024-10-21 19:05 | Florian Dold | Assigned To | Florian Dold => MarcS |
| 2024-10-22 09:57 | MarcS | Note Added: 0023556 | |
| 2024-10-22 10:03 | MarcS | Assigned To | MarcS => Florian Dold |
| 2024-10-22 15:09 | Florian Dold | Target Version | => 0.14 |
| 2024-10-22 15:29 | Florian Dold | Note Added: 0023560 | |
| 2024-10-22 15:29 | Florian Dold | Status | assigned => resolved |
| 2024-10-22 15:29 | Florian Dold | Resolution | open => fixed |
| 2024-10-22 15:29 | Florian Dold | Note Added: 0023561 |
