View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007568 | Taler | wallet (WebExtension) | public | 2023-01-12 15:28 | 2023-09-23 13:09 |
| Reporter | sebasjm | 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 | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.3 | Fixed in Version | 0.9.3 | ||
| Summary | 0007568: implement the new semantic of aborting/cancel/forgetting/resuming a tx | ||||
| Description | check the extendedStatus field | ||||
| Tags | No tags attached. | ||||
| related to | 0006590 | closed | Florian Dold | clarify UX for (partially) failed payments |
| https://git.taler.net/docs.git/tree/design-documents/037-wallet-transactions-lifecycle.rst If aborted is an end state, resuming a aborted tx should create a new one. WDYT? | |
| I don't think "aborted" should be an end state. Having multiple versions of basically the same transaction would be very confusing. | |
| Well, my argument for using aborted transaction as and end state is because running again the transaction may be done based on different conditions and the old aborted tx have important information that should not be lost. Maybe we should put some examples * On withdraw, the transaction may be aborted from the bank or from the wallet. This information need to be saved. If the withdrawal was initiated from the bank, resuming won't be possible because I understand resuming the withdrawal as creating a new manual withdraw. * Aborted transfer or invoices can't reuse purse, so it will need to pay that fee again. Am I correct? * Aborted payment, when restarted again, will have different contract. Old payment tx will have the amount spend (fees) and refund associated. | |
| I think the details in DD37 should clarify this. All your examples would be non-resumable aborted transactions, so effectively we *are* creating new transactions in these cases. It just has nothing to do with the resume mechanism. So we practically agree here? The only place where resuming aborted transactions makes sense if the abort wasn't destructive. For example, aborting a withdrawal where the money was already wired. | |
| Closing this since DD37 is in progress | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-01-12 15:28 | sebasjm | New Issue | |
| 2023-01-12 15:28 | sebasjm | Status | new => assigned |
| 2023-01-12 15:28 | sebasjm | Assigned To | => Florian Dold |
| 2023-01-12 15:28 | sebasjm | Assigned To | Florian Dold => sebasjm |
| 2023-01-12 15:30 | sebasjm | Relationship added | related to 0006590 |
| 2023-02-10 15:05 | Florian Dold | Summary | implement the new semantic of aborting/cancel/forgetting a tx => implement the new semantic of aborting/cancel/forgetting/resuming a tx |
| 2023-02-14 14:33 | sebasjm | Note Added: 0019835 | |
| 2023-02-14 14:33 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-02-14 14:33 | sebasjm | Status | assigned => feedback |
| 2023-02-16 21:24 | Florian Dold | Note Added: 0019853 | |
| 2023-02-17 01:54 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-02-17 01:54 | Florian Dold | Status | feedback => assigned |
| 2023-02-17 12:53 | sebasjm | Note Added: 0019864 | |
| 2023-02-17 12:53 | sebasjm | Assigned To | sebasjm => Florian Dold |
| 2023-02-17 12:53 | sebasjm | Status | assigned => feedback |
| 2023-02-17 13:51 | Florian Dold | Note Added: 0019865 | |
| 2023-02-17 13:52 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2023-04-04 13:54 | Florian Dold | Target Version | git (master) => 0.9.3 |
| 2023-04-10 14:44 | sebasjm | Note Added: 0020054 | |
| 2023-04-10 14:44 | sebasjm | Status | feedback => informing |
| 2023-04-10 14:44 | sebasjm | Resolution | open => fixed |
| 2023-04-13 18:37 | Florian Dold | Category | wallet (WebExtensions) => wallet (WebExtension) |
| 2023-09-23 13:07 | Christian Grothoff | Fixed in Version | => 0.9.3 |
| 2023-09-23 13:09 | Christian Grothoff | Status | informing => closed |