View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005202 | Taler | other | public | 2017-12-09 00:53 | 2020-03-31 14:04 |
| Reporter | Florian Dold | Assigned To | Florian Dold | 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 | text | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.7.0 | ||||
| Summary | 0005202: clarify and document which amount format should be used where | ||||
| Description | We have these three: 1) The JSON format { currency, value, fraction } 2) The human-readable standard decimal form TESTKUDOS:95.00 3) The pretty-printed form, where rendering and parsing and display might even depend on the user locale or other settings The bank currently uses format (2) instead of (3), which probably is not what we want. | ||||
| Tags | No tags attached. | ||||
| We spoke about splitting our glossary as user -vs- devs. So this must belong to devs'. | |
| Meta-question: do we want to preserve the JSON format? The string format is more compact, and we could avoid the entire issue by just having always the CURRENCY:value.fraction format instead of having two. | |
| Reminder sent to: Marcello Stanisci | |
| About the meta-question: I remeber someone suggested to *drop* the currency component from our amounts at some point. In that case, I would keep the JSON amount since it feels more "structured". If instead we keep the currency around, then I agree in dropping the JSON format and only have the stringified version. | |
| About the report: the bank communicates amounts to their customers with this format (just checked on a profile page and on public histories page on 'test'): 100.00 TESTKUDOS. So no semicolon used and not very unfriendly. | |
| Eh, I am thinking of dropping the currency in the database schema, but that's for a different reason. Other than _inside_ of the database, we'll keep the currency around. | |
| Oh, and how we show things to users in the user interface should not be affected at all, that should ideally be controlled by the locale. | |
| As far as I can see this is completely resolved: * public APIs always use the "EUR:2.50" format * when displayed to the user, we do "2.50 EUR", potentially with variations based on locale or currency-specific changes, such as "€2.500,50" for "EUR:2500.50" with a German locale * internally, each component uses what it wants, the C component uses an amount struct, the TypeScript wallet the { currency, value, fraction } object. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-12-09 00:53 | Florian Dold | New Issue | |
| 2017-12-09 10:07 | Christian Grothoff | Severity | minor => text |
| 2017-12-09 10:07 | Christian Grothoff | Status | new => implementing |
| 2017-12-09 10:07 | Christian Grothoff | Product Version | => git (master) |
| 2019-05-30 12:56 | Marcello Stanisci | Note Added: 0014465 | |
| 2019-07-14 09:55 | Christian Grothoff | Note Added: 0014670 | |
| 2019-07-14 09:55 | Christian Grothoff | Note Added: 0014671 | |
| 2019-07-15 16:34 | Marcello Stanisci | Note Added: 0014677 | |
| 2019-07-15 16:39 | Marcello Stanisci | Note Added: 0014678 | |
| 2019-07-15 17:31 | Christian Grothoff | Note Added: 0014684 | |
| 2019-07-15 17:31 | Christian Grothoff | Note Added: 0014685 | |
| 2020-01-07 17:49 | Florian Dold | Assigned To | => Florian Dold |
| 2020-01-07 17:49 | Florian Dold | Status | implementing => informing |
| 2020-01-07 17:49 | Florian Dold | Resolution | open => fixed |
| 2020-01-07 17:49 | Florian Dold | Note Added: 0015239 | |
| 2020-01-07 17:50 | Florian Dold | Target Version | => 0.7.0 |
| 2020-03-31 14:04 | Christian Grothoff | Status | informing => closed |