View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007357 | Taler | wallet (WebExtension) | public | 2022-09-11 04:51 | 2023-02-21 16:39 |
| Reporter | sebasjm | Assigned To | sebasjm | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.2 | Fixed in Version | 0.9.2 | ||
| Summary | 0007357: all call-to-action should redirect to transaction details after starting | ||||
| Description | do not make the user wait, just redirect as soon it can be confirmed that the transaction is valid. This way will make easier to have a standard flow for every action. We need the transaction id from wallet-core on: * AcceptWithdrawalResponse * AcceptManualWithdrawalResult * CreateDepositGroupResponse * ConfirmPayResult * ApplyRefundResponse * AcceptTipResponse (missing) * acceptPeerPushPaymentResponse (missing) * AcceptPeerPullPaymentResponse (missing) * InitiatePeerPullPaymentResponse * InitiatePeerPushPaymentResponse | ||||
| Tags | No tags attached. | ||||
| related to | 0007339 | feedback | Florian Dold | withdrawal triggered on insufficient balance does not work in demo (due to fees) |
| related to | 0007332 | closed | sebasjm | UX for withdrawing bitcoin is awkward |
|
|
every response now returns a txId except for refund. Refund should return an id build from: TransactionType.Refund + purchaseId + execTime. But execTime is known in the moment of the creation. Should we move away from execTime as part of the refund id? Could we introduce a refundGroupId to be created before the tx starts? |
|
|
You mean "unknown at the moment of creation", right? And you're specifically talking about applyRefund, right? There are various cases here: (1) we were able to check for a refund, and there is a new one (2) we were able to check, but there is no new refund (3) we were unable to check for a refund (merchant down, no network, ...) For case (1), we already do know the executionTime of the new refund. But what would you suggest returning for (2) and (3) in the first place? Neither an execution time nor a refundGroupId makes sense here. |
|
|
> You mean "unknown at the moment of creation", right? Yes, typo. > Neither an execution time nor a refundGroupId makes sense here. That's because applyRefund tries to apply for a refund _if it find one_, which I think the more correct procedure is: 1.- check if there is refund (webex does queryAndSaveAwaitingRefund throught prepareRefund) 2.- show to the user the information about how much refund is getting (and maybe in the future how this affect the contract: show return item? is able to see the article he/she had?) 3.- applyRefund should process that known refund, avoiding receiving more refund that didn't accept/check already |
|
|
Okay, we could indeed introduce a new "refundGroupId" if that helps. The only limitation here is that if we accept a "refund group", all previous refunds are also applied. Do these always belong to the new refund group? For example: (1) User buys order XYZ (2) Merchant gives partial refund at time t1 (3) Merchant gives another partial refund at time t2, where t2 > t1. (4) Wallet queries for refunds In that case, what refund groups do you think should be created? (a) one refund group that covers both increments (b) two refund groups I think (a) is a bit difficult to handle with backup/sync, but probably doable. And (b) is not that much different from just having the executionTime as the key. What do you think? |
|
|
(a) I think refund should be grouped in the wallet by the user interaction, not how the merchant made it. And this will address my main concern: the wallet will get the refund that was rendered in the screen. |
|
|
After getting a refund the wallet web extension redirect to the purchase with the outdated transaction information, so it's always wrong. We need the refund id to show updated information after accepting refund. |
|
|
Okay, maybe a stupid question, but we can't we just redirect the user to the details of the *order* that was refunded, since this should also contain information about refunds received? IMHO it's okay if checking the refund creates "zero or more" new transactions. I'm not a big fan of grouping refunds by when the user obtained them and I'd rather not make a big change in how refunds work (and all the baggage that comes with it, such as way more complex merging in backup/sync). |
|
|
This is the current behavior right now since wallet-core returns `makeTransactionId(TransactionType.Payment, proposalId)` in the appyRefund response. Is not working nice since the function returns before the refund is updated. When the user is redirected the tx status query returns the purchase without the refund applied even if the applyRefund is successful. |
|
|
Can we expose some additional field on the payment transaction that a refund is currently being checked (and emit a notification once that's done)? Would that help? |
|
|
As discussed internally, after accepting the refund the purchase will be marked as "no refund is pending, but one refund is in progress" so the UI redirect the user to the purchase tx with proper information |
|
|
The wallet now exposes the refundQueryActive flag in the payment transaction. We also emit a notification ("refund-finished") when we successfully applied a refund. Let me know if the UI needs anything else here! |
|
|
applyRefund now returns the latest refund applied. |
|
|
all operation return tx id fixed 5ad96b178ee022199877b89683ceb0e930761b9d |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-09-11 04:51 | sebasjm | New Issue | |
| 2022-09-11 04:51 | sebasjm | Status | new => assigned |
| 2022-09-11 04:51 | sebasjm | Assigned To | => sebasjm |
| 2022-09-11 04:51 | sebasjm | Relationship added | related to 0007339 |
| 2022-09-12 19:41 | sebasjm | Relationship added | related to 0007332 |
| 2022-09-13 15:36 | Christian Grothoff | Assigned To | sebasjm => Florian Dold |
| 2022-09-16 16:01 | sebasjm | Note Added: 0019137 | |
| 2022-09-16 17:13 | Florian Dold | Note Added: 0019138 | |
| 2022-09-16 19:40 | sebasjm | Note Added: 0019139 | |
| 2022-09-19 18:19 | Florian Dold | Note Added: 0019154 | |
| 2022-09-19 18:20 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2022-09-19 18:20 | Florian Dold | Status | assigned => feedback |
| 2022-09-20 04:21 | sebasjm | Note Added: 0019156 | |
| 2022-11-16 18:52 | sebasjm | Priority | normal => high |
| 2022-11-16 18:52 | sebasjm | Target Version | git (master) => 0.9.1 |
| 2022-11-16 18:53 | sebasjm | Note Added: 0019427 | |
| 2022-11-16 18:53 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-01-10 18:36 | Christian Grothoff | Target Version | 0.9.1 => 0.9.2 |
| 2023-02-12 20:39 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-02-12 20:41 | Florian Dold | Note Added: 0019809 | |
| 2023-02-13 13:54 | sebasjm | Note Added: 0019814 | |
| 2023-02-13 13:54 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-02-13 13:58 | Florian Dold | Note Added: 0019815 | |
| 2023-02-13 14:00 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-02-13 19:45 | sebasjm | Note Added: 0019826 | |
| 2023-02-13 21:25 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-02-13 21:26 | sebasjm | Status | feedback => confirmed |
| 2023-02-14 11:19 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-02-14 11:19 | Florian Dold | Status | confirmed => assigned |
| 2023-02-14 11:19 | Florian Dold | Note Added: 0019830 | |
| 2023-02-17 18:41 | Florian Dold | Target Version | 0.9.2 => 0.9.3 |
| 2023-02-20 17:20 | sebasjm | Note Added: 0019887 | |
| 2023-02-20 17:25 | sebasjm | Status | assigned => resolved |
| 2023-02-20 17:25 | sebasjm | Resolution | open => fixed |
| 2023-02-20 17:25 | sebasjm | Note Added: 0019888 | |
| 2023-02-20 17:49 | Florian Dold | Target Version | 0.9.3 => 0.9.2 |
| 2023-02-21 16:39 | Christian Grothoff | Fixed in Version | => 0.9.2 |
| 2023-02-21 16:39 | Christian Grothoff | Status | resolved => closed |
| 2023-04-13 20:37 | Florian Dold | Category | wallet (WebExtensions) => wallet (WebExtension) |
