View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009954 | Taler | merchant portal webui | public | 2025-05-13 21:49 | 2026-09-19 14:40 |
| Reporter | Bohdan | 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 | tweak | Reproducibility | always |
| Status | informing | Resolution | fixed | ||
| Product Version | 1.0 | ||||
| Target Version | 1.6 | Fixed in Version | 1.6 | ||
| Summary | 0009954: The order which has status claimed can't be deleted using Backoffice | ||||
| Description | c | ||||
| Steps To Reproduce | 1) Claim the order with Taler wallet. 2) Go to the backoffice, and try to delete the order with existing buttons. | ||||
| Tags | No tags attached. | ||||
| Well, that's kind-of on purpose to avoid a bad UX at the wallet. But maybe we can improve the SPA UI here. | |
| which delete button ? AFAIK there was never a way to delete on merchant backoffice. this needs to be converted into a feature if we want to delete orders in ANY place. AFAIK merchant backend removes them on GC | |
| So, in the end, do we want to allow such a possibility? On one side, we can unlock inventory, on the other side, but at the same time, the UX of wallet users can suffer. In my understanding, the percentage of cases where it brings value is higher than cases when the wallet actually decides to pay for something, a bit later than the merchant decides to delete the order. | |
| Exactly: the locked inventory can be a big problem, if stocks are low and the order was abandoned (but possibly with a long pay deadline!). Now, yes, this can cause UX issues in the wallet (wallet tries to pay, order is gone), but the wallets already must handle this. Furthermore, the idea is to *warn* the (merchant) user that a wallet MAY still be trying to pay and that deleting it may disrupt some user's flow. But the seller may know best (like: customer *did* walk away), and similarly the PoS may know best (bad order entered, customer changed their mind), and we absolutely MUST have a way to unlock the inventory in this case. | |
| ACK I will add the delete when unclaimed or claimed but still unpaid -> useful when the customer walks away. Also I agree that the locked product is an issue but I think it does not solve the problem nicely in others situations when there is no customer walking away or the merchant just forget to be neat and tidy. I propose merchant portal help to fix the problem when it raises, on the order creation. so in https://docs.taler.net/core/api-merchant.html#get-[-instances-$INSTANCE]-private-orders, add: locked_products – Optional. List of products id. Only returns orders that have a lock with any of the products on the list. Merchant portal can show a dialog after receiving 410 (out of stock) explaining that can delete those orders (older first, paid=no) inplace without interrupting the current order creation. This will be also useful for automated processes. | |
| Tested with latest merchant webui, deletion of claimed order works after checking the "force deletion" checkbox. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-13 21:49 | Bohdan | New Issue | |
| 2025-05-14 18:32 | Christian Grothoff | Note Added: 0024908 | |
| 2025-05-14 18:32 | Christian Grothoff | Status | new => implementing |
| 2025-05-14 18:32 | Christian Grothoff | Target Version | 1.0 stretch goals => 1.5 |
| 2025-12-07 09:41 | Christian Grothoff | Severity | minor => text |
| 2025-12-07 09:41 | Christian Grothoff | Severity | text => tweak |
| 2025-12-21 21:07 | Christian Grothoff | Target Version | 1.5 => 1.8 |
| 2026-02-26 21:10 | Christian Grothoff | Assigned To | => sebasjm |
| 2026-02-26 21:10 | Christian Grothoff | Status | implementing => assigned |
| 2026-02-26 21:10 | Christian Grothoff | Status | assigned => implementing |
| 2026-04-16 18:34 | sebasjm | Note Added: 0028402 | |
| 2026-04-16 18:34 | sebasjm | Assigned To | sebasjm => |
| 2026-04-16 18:34 | sebasjm | Status | implementing => feedback |
| 2026-04-16 18:34 | sebasjm | Assigned To | => Bohdan |
| 2026-04-16 18:34 | sebasjm | Status | feedback => assigned |
| 2026-05-17 20:26 | Bohdan | Note Added: 0028631 | |
| 2026-05-17 20:27 | Bohdan | Assigned To | Bohdan => Christian Grothoff |
| 2026-05-17 20:27 | Bohdan | Status | assigned => feedback |
| 2026-05-17 20:30 | Christian Grothoff | Note Added: 0028632 | |
| 2026-05-17 20:30 | Christian Grothoff | Assigned To | Christian Grothoff => sebasjm |
| 2026-05-17 20:30 | Christian Grothoff | Status | feedback => implementing |
| 2026-05-17 20:31 | Christian Grothoff | Relationship added | has duplicate 0011404 |
| 2026-05-18 12:01 | sebasjm | Note Added: 0028644 | |
| 2026-08-23 14:18 | Florian Dold | Category | merchant backoffice SPA => merchant portal webui |
| 2026-08-27 08:34 | Florian Dold | Status | implementing => informing |
| 2026-08-27 08:34 | Florian Dold | Resolution | open => fixed |
| 2026-08-27 08:34 | Florian Dold | Note Added: 0029653 | |
| 2026-09-19 14:38 | Christian Grothoff | Target Version | 1.8 => 1.6 |
| 2026-09-19 14:40 | Christian Grothoff | Fixed in Version | => 1.6 |