View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011478 | Taler | wallet (all platforms) | public | 2026-06-05 15:23 | 2026-06-16 11:47 |
| Reporter | Adrian Steiner | Assigned To | Florian Dold | ||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Target Version | 1.6 | ||||
| Summary | 0011478: Apps should automatically adopt amount from Template Link for xOTP / MDB devices [meta] | ||||
| Description | To support further work with xOTP/MDB devices, it would be beneficial if the mobile applications (iOS and Android) could directly take over and process the amount specified in the template link. Example Link: taler://pay-template/backend.demo.taler.net/instances/sandbox/xOTP_MDB?amount=KUDOS:0.1&nfc=1 Currently, this feature is not implemented in the backend/apps, meaning the 'amount' parameter is ignored and the default value from the backend is displayed instead. Expected Behavior: 1. When a template link containing an amount parameter (e.g., ?amount=KUDOS:0.1) is opened, the app should automatically parse and pre-fill that amount for the transaction. 2. The pre-filled amount must be locked and NOT changeable by the user. 3. Immediately after reading the link and parsing the data, the app should skip any intermediate steps and open the confirmation screen directly. | ||||
| Tags | No tags attached. | ||||
|
|
Looks trivial. Can we just add this? |
|
|
Adrian: is the behavior with nfc=1 implemented / spec'ed / understood? |
|
|
We should do this not only for amount, but also *summary* and *summary_editable* (and I guess amount_editable). Basically, the URL is allowed to override editable values we GET from the /template endpoint. And additionally, IF it sets "editable" to "no", then the user may no longer (!) edit in the wallet. That way, we can then even *skip* the editing dialog entirely. This can make sense for example for WOZ where the summary should be dynamic (same template, but different articles purchased) or for Adrian where the price is already fixed (just not in the template in the backend). WOZ needs this *ASAP*, so prio up! |
|
|
Just assigned this to Florian because wallet-core needs to support it |
|
|
The nfc=1 was a desired argument from Marc for the iOS app to enable the feature to return the received passkeys. This can be ignored for this issue. |
|
|
I don't see any summary_editable in the API spec (nor the taler-merchant implementation). The UIs currently consider a field editable by the user iff it is unset in the template_contract. Of course we can just take the field value from the taler://pay-template URI params. However, it's not clear when the user should still be able to edit it. Currently the priority for fields' values is the following (say for $X in {'summary', 'amount'}): 1. If template_contract.$X, everything else is ignored 2. Else, if the user provided a value for $X, use that. 3. Else, if editable_defaults.$X is provided, use that. 4. Else, creating the template will error out. Where do the values from the URI params fit into this? We can either: (a) give them highest priority, never allowing the user to edit their value (b) always allow the user to edit their value (which goes against the requirements you mentioned!) (c) add extra signaling to the protocol (some explicit {$X}_editable) setting. |
|
|
Well, yes, I misremembered, it's the "editable_defaults" in the template: https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-templates-$TEMPLATE_ID But regardless, the idea remains simple: if the template URI specifies "editable_XXX=no", that field should NOT be editable anymore. We can make it generic and apply to any key "XXX" in "editable_defaults". And yes, the URI params should have the highest priority, as they are there to improve the UX: do not prompt the user if the QR code is a bit dynamic and knows better already. The backend does *not* know and will trust the wallet did the right thing. And yes, it would be possible for a malicious wallet or user to instantiate the template by editing the values despite the QR code having some specific settings, that's OK. |
|
|
I think I understood it now. We need to differentiate two cases: a) the template is not editable, but fixed b) the template IS editable, whether it specified a default amount or not is not important - this just pre-fills the EditText with a value or zero. struct TemplateContractDetails: Codable { let summary: String? // Human-readable short summary of the contract. Editable if nil let currency: String? // specify currency when amount is nil - unspecified if nil let amount: Amount? // Total amount payable. Fixed if this field exists, editable if nil struct TemplateContractDetailsDefaults: Codable { let summary: String? // Default 'Human-readable summary' when editable: empty if nil let currency: String? // Default currency when unspecified: any if nil (e.g. donations) let amount: Amount? // Default amount when editable: unspecified if nil case a) The template specifies the amount in TemplateContractDetails ==> the talerURI amount cannot override it. case b) The template is editable (and does have a default value). Currently both wallet-core and the iOS wallet ignore the amount from the talerURI, and display the EditText (pre-filled with the default amount). What Adrian wants, is for the wallets to take the amount from the talerURI and don't let the user edit it: taler://pay-template/backend.demo.taler.net/instances/sandbox/xOTP_MDB?amount=KUDOS:0.1&nfc=1 ==> even though the template is editable (doesn't specify TemplateContractDetails.amount), wallets should NOT show the EditText, but use the amount specified in the talerURI. We can do this either in wallet-core: After the wallet calls checkPayForTemplate(url), wallet-core queries the backend, receives 'IsEditable' (no amount in TemplateContractDetails). Instead of passing the data unchanged to the wallet, wallet-core puts the amount from the talerURI into TemplateContractDetails.amount, and sets TemplateContractDetailsDefaults.amount to nil. Then all wallets think the amount is fixed. No code changes necessary - this works directly with all wallets. Or all wallets need to parse the talerURI, and themselves treat the amount there as if it came from TemplateContractDetails.amount and show the user a fixed, non-editable amount even though the template is editable. As usual, I pledge for wallet-core doing it once instead of all wallets needing to implement their own solution. |
|
|
Of course wallet-core then also needs to use the amount from the talerURI when the wallet pays... |
|
|
Yep, the simplest solution (also suggested by Christian earlier offline) is for wallet-core to adjust the template contract/editable_defaults, so that there is no need for the UIs to change anything! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-06-05 15:23 | Adrian Steiner | New Issue | |
| 2026-06-05 15:49 | Christian Grothoff | Severity | major => feature |
| 2026-06-05 15:49 | Christian Grothoff | Status | new => confirmed |
| 2026-06-05 15:49 | Christian Grothoff | Target Version | => 1.6 |
| 2026-06-05 15:50 | Christian Grothoff | Note Added: 0028789 | |
| 2026-06-05 15:50 | Christian Grothoff | Note Added: 0028790 | |
| 2026-06-05 15:51 | Christian Grothoff | Target Version | 1.6 => 1.7 |
| 2026-06-08 22:25 | Christian Grothoff | Note Added: 0028803 | |
| 2026-06-08 22:25 | Christian Grothoff | Priority | normal => urgent |
| 2026-06-08 22:25 | Christian Grothoff | Target Version | 1.7 => 1.6 |
| 2026-06-08 22:25 | Christian Grothoff | Summary | Apps should automatically adopt amount from Template Link for xOTP / MDB devices => Apps should automatically adopt amount from Template Link for xOTP / MDB devices [meta] |
| 2026-06-08 22:58 | MarcS | Assigned To | => Florian Dold |
| 2026-06-08 22:58 | MarcS | Status | confirmed => assigned |
| 2026-06-08 22:58 | MarcS | Note Added: 0028805 | |
| 2026-06-10 13:24 | Adrian Steiner | Note Added: 0028835 | |
| 2026-06-15 19:00 | Florian Dold | Note Added: 0028892 | |
| 2026-06-15 19:01 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2026-06-15 19:01 | Florian Dold | Status | assigned => feedback |
| 2026-06-15 19:05 | Christian Grothoff | Note Added: 0028894 | |
| 2026-06-15 19:06 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2026-06-16 08:34 | MarcS | Note Added: 0028906 | |
| 2026-06-16 08:50 | MarcS | Note Added: 0028907 | |
| 2026-06-16 11:47 | Florian Dold | Note Added: 0028908 |
