View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010960 | Taler | merchant portal webui | public | 2026-01-31 20:04 | 2026-03-20 23:55 |
| Reporter | Christian Grothoff | Assigned To | sebasjm | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | text | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.5 | Fixed in 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. | |
| > "Confirmed" means that this exact wire transfer exists in the "Confirmed" tab. So I think we can just leave that. Duplicated info, let's just return only unconfirmed wire transfer (By definition they are "new" which were not yet checked) on the /incoming endpoint. After confirmation it will automatically be returned on the other endpoint. I can't filter on the UI because of pagination. > "verified" and "confirmed", which both have 3 states: YES/NO/ALL I'm going to remove "confirmed" from /incoming, is duplicated info. Also, all request will be with "confirmed": NO (maybe you want to remove it from the protocol). In this way the "incoming" table will only have "new wire transfer that needs to be checked against you bank transfer" very important to be prominent. If empty it disappears. I prefer only show a "verified" and "expected" filter which only show with YES/NO/ALL to filter both lists. If "verified" : false this is an error, something needs to be fixed between merchant and exchange. A bug maybe? Is there a reason that is not a bug? The "verified" filter should work in both request /incoming and /transfer, merchant can still confirm a wire transfer even if is not verified. Right? > Please also confirm that the page supports pagination. Yes, it does. Regarding the expected. I could hide this column and only show it if the filter is "ALL". Should the merchant be able to POST wire transfer ? Right now there is no form for that (it was removed) so I don't see how this could be present. | |
| It is not duplicated info, because the "Confirmed" tab would show completely different data. These are NOT two different views of the same list! (There is a reason why you have two different endpoints!) And yes, the "confirmed" is deprecated (as I indicated above), and once it wouldn't break clients, I do intend to remove the field from the protocol entirely. Same for "verified". They are both there right now just to ensure clients that rely on them do not crash, but they are already NOT meaningful anymore! And no, the "verified" filter makes no sense on the "transfers" list. | |
| d8c0ea2ca..1d3ca6ef6 | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-31 20:04 | Christian Grothoff | New Issue | |
| 2026-01-31 20:04 | Christian Grothoff | Status | new => assigned |
| 2026-01-31 20:04 | Christian Grothoff | Assigned To | => sebasjm |
| 2026-01-31 20:06 | Christian Grothoff | Additional Information Updated | |
| 2026-01-31 20:09 | Christian Grothoff | Additional Information Updated | |
| 2026-01-31 20:10 | Christian Grothoff | Description Updated | |
| 2026-01-31 20:15 | Christian Grothoff | Note Added: 0027510 | |
| 2026-01-31 20:27 | Christian Grothoff | Note Added: 0027511 | |
| 2026-01-31 20:29 | Christian Grothoff | Note Added: 0027512 | |
| 2026-02-05 11:18 | sebasjm | Note Added: 0027586 | |
| 2026-02-05 11:31 | sebasjm | Note Edited: 0027586 | |
| 2026-02-05 13:21 | Christian Grothoff | Note Added: 0027590 | |
| 2026-02-05 14:46 | sebasjm | Status | assigned => informing |
| 2026-02-05 14:46 | sebasjm | Resolution | open => fixed |
| 2026-02-05 14:46 | sebasjm | Note Added: 0027595 | |
| 2026-03-10 12:37 | Christian Grothoff | Fixed in Version | => 1.5 |
| 2026-03-20 23:55 | Christian Grothoff | Status | informing => closed |
| 2026-08-23 14:18 | Florian Dold | Category | merchant backoffice SPA => merchant portal webui |