View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010577 | Taler | merchant backend | public | 2025-11-10 21:54 | 2026-11-02 17:28 |
| Reporter | htgoebel | Assigned To | Resolution deadline | ||
| Implementer | Christian Grothoff | Reviewer | Florian Dold | ||
| Release signed by | Christian Grothoff | Deployed by | vecirex | ||
| Verifier | htgoebel | Communicator | |||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | 30 | Actual effort (hours) | 0 | ||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | implementing | Resolution | open | ||
| Target Version | post-1.0 | ||||
| Summary | 0010577: Refund needs identifier or such | ||||
| Description | When managing orders and refunds by a web-shop or ERP system, one needs to keep orders and refunds in sync between the ERP system and the backend. For orders this is done by the API returning an order-ID. For refunds there is no such thing. An ERP system can just guess the mapping passed on the data. Expected: Some way to identify the refund. Propsed solution: Since the RefundDetails already contain a timestamp, I propose to add an optional timestamp field to RefundRequest (much like OrderCommon.timestamp). While still not 100% perfect due to duplicate refunds at the very same time, I expect this to be good enough. | ||||
| Tags | No tags attached. | ||||
| We could just return the row ID of the refund operation, that'd be unique. | |
| Note that a single refund may result in multiple DB entries, one per coin impacted. So this would be multiple row IDs. | |
| I'm pushing on this, since I have concrete user story: Orders and refunds are managed by the ERP system. Now (for whatever reason) a refund is created directly in the Merchant Backend. Any refund created this way needs to be mirrored in the ERP system to ensure accounting matches the Merchatn Backend. For this, the ERP system needs some refund identifier. The refund timestamp would be okay, since refunds are always related to a order. Since the RefundDetails already include a timestamp. I propose to return this timestamp - or return a RefundDetails struct. | |
| I'm aware you have a use-case. I don't like timestamps for this, time is not always monotonous. Fixing this properly will take more time than I have right now, but happy to discuss *clean* designs. | |
| The RefundDetails already include a timestamp. I propose to return this timestamp - or return a RefundDetails struct. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-11-10 21:54 | htgoebel | New Issue | |
| 2025-11-11 11:29 | Christian Grothoff | Note Added: 0026372 | |
| 2025-11-11 11:41 | Christian Grothoff | Status | new => implementing |
| 2025-11-11 11:41 | Christian Grothoff | Target Version | => 1.6 |
| 2025-11-11 11:41 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2025-11-11 11:41 | Christian Grothoff | Status | implementing => assigned |
| 2025-11-11 11:41 | Christian Grothoff | Status | assigned => implementing |
| 2025-11-22 07:50 | Christian Grothoff | Note Added: 0026577 | |
| 2025-11-28 21:14 | Christian Grothoff | Summary | Refund needs identifier or such => Refund needs identifier or such [4d] |
| 2025-12-07 00:00 | Christian Grothoff | Target Version | 1.6 => post-1.0 |
| 2025-12-21 19:01 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2026-01-26 06:04 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2026-01-26 06:04 | Christian Grothoff | Status | implementing => assigned |
| 2026-01-26 06:05 | Christian Grothoff | Status | assigned => implementing |
| 2026-02-07 12:45 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2026-06-30 11:02 | htgoebel | Note Added: 0029026 | |
| 2026-06-30 21:34 | Christian Grothoff | Note Added: 0029031 | |
| 2026-07-19 10:45 | htgoebel | Note Added: 0029194 | |
| 2026-08-12 23:06 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2026-08-12 23:06 | Christian Grothoff | Status | implementing => assigned |
| 2026-08-12 23:06 | Christian Grothoff | Status | assigned => implementing |
| 2026-11-02 17:25 | Christian Grothoff | Assigned To | Christian Grothoff => |
| 2026-11-02 17:25 | Christian Grothoff | Implementer | => Christian Grothoff |
| 2026-11-02 17:25 | Christian Grothoff | Reviewer | => Florian Dold |
| 2026-11-02 17:25 | Christian Grothoff | Release signed by | => Christian Grothoff |
| 2026-11-02 17:25 | Christian Grothoff | Deployed by | => vecirex |
| 2026-11-02 17:25 | Christian Grothoff | Verifier | => htgoebel |
| 2026-11-02 17:28 | Christian Grothoff | Estimated effort (hours) | => 30 |
| 2026-11-02 17:28 | Christian Grothoff | Summary | Refund needs identifier or such [4d] => Refund needs identifier or such |