View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010960 | Taler | merchant backoffice SPA | public | 2026-01-31 21:04 | 2026-01-31 21:29 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | ||
| Priority | high | Severity | text | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.5 | ||||
| Summary | 0010960: "Verified" tab for Wire transfers shows "verified: no" | ||||
| Description | When looking at the "Wire transfers" in the "verified" tab, after explicitly *confirming* a wire transfer, the transfer shows as "Verified: no", which is wild. | ||||
| Additional Information | HTTP responses from the backend were: incoming: { "incoming": [ { "expected_credit_amount": "TESTKUDOS:1", "wtid": "31HP8RQHEGD9AV3G5NKY6XZ6CFC3N3B3P2TJ7EXR92EY94APX17G", "payto_uri": "payto://x-taler-bank/localhost/fortythree?receiver-name=fortythree", "exchange_url": "http://localhost:8081/", "expected_transfer_serial_id": 1, "execution_time": { "t_s": 1769888804 }, "validated": true, "confirmed": true, "last_http_status": 200, "last_ec": 0 } ] } transfers: { "transfers": [ { "credit_amount": "TESTKUDOS:1", "wtid": "31HP8RQHEGD9AV3G5NKY6XZ6CFC3N3B3P2TJ7EXR92EY94APX17G", "payto_uri": "payto://x-taler-bank/localhost/fortythree?receiver-name=fortythree", "exchange_url": "http://localhost:8081/", "transfer_serial_id": 1, "verified": false, -- deprecated, ignore! "confirmed": true, -- deprecated, ignore! "expected": true, "execution_time": { "t_s": 1769889615 } } ] } | ||||
| Tags | No tags attached. | ||||
|
|
Ok, looking over the protocol again, we first of all MUST ignore the now "deprecated" fields (marked in the snippets above). So for the "/transfers" endpoint, that only leaves *expected* as the boolean to render, which makes sense. This is currently shown as the "Verified" tab, which I suggest we rename to "Confirmed": /transfers only ever shows wire transfers that have been confirmed as having hit our bank account. The list then shows WTID, amount, and whether the transfer was *expected*, plus the execution date. Now, the order is weird, I would expect it to be "Date" (shorter than "Execution Date"), "Amount" (instead of "Expected credit" -- this is *confirmed* wire transfers, not expectations), "ID" (or "Subject", debatable), and finally "Expected" (almost always 'yes', most boring data). That shows data in a more canonical order (Date first) and then by importance (amount is very important), and with simpler titles. The overall caption "Incoming wire transfers" is fine, could also be "Confirmed wire transfers into bank account" -- we have the space, and might be super-clear. |
|
|
Now for the "/incoming" endpoint, I think we first of all should expose the filters "verified" and "confirmed", which both have 3 states: YES/NO/ALL. Default for both filters should probably be "ALL". Note that confusingly the "verified" filter matches the "validated" field in the response. We SHOULD fix that in the next iteration of the API... Anyway, let's first fix the GUI so we know what we're talking about here. "Confirmed" means that this exact wire transfer exists in the "Confirmed" tab. So I think we can just leave that. "Validated" is the interesting bit, it means that the amount matches the total the merchant backend expected to be settled (sum of all orders minus fees). We also need to note that the "expected credit" could be missing if we do not yet know the amount. We probably should show it as to be determined (TBD) if it is not yet known instead of leaving the table entry empty. I would again switch the column order: "Date" (anticipated or executed, we don't know, depends on "Confirmed", so just "Date" is best!), "Amount" (again, may be expected, or confirmed, or TBD!), "ID", "Confirmed", "Validated"). |
|
|
Finally, I've only tested this with a single transfer. We should probably allow the user to specify how many transfers they want to see on one page (default: 20 or 50?). Please also confirm that the page supports pagination. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-31 21:04 | Christian Grothoff | New Issue | |
| 2026-01-31 21:04 | Christian Grothoff | Status | new => assigned |
| 2026-01-31 21:04 | Christian Grothoff | Assigned To | => sebasjm |
| 2026-01-31 21:06 | Christian Grothoff | Additional Information Updated | |
| 2026-01-31 21:09 | Christian Grothoff | Additional Information Updated | |
| 2026-01-31 21:10 | Christian Grothoff | Description Updated | |
| 2026-01-31 21:15 | Christian Grothoff | Note Added: 0027510 | |
| 2026-01-31 21:27 | Christian Grothoff | Note Added: 0027511 | |
| 2026-01-31 21:29 | Christian Grothoff | Note Added: 0027512 |
