View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010889 | Taler | specification | public | 2026-01-19 11:56 | 2026-01-20 11:48 |
| Reporter | Christian Grothoff | Assigned To | Bohdan | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 1.4 | ||||
| Summary | 0010889: add "tip" to contract terms | ||||
| Description | I think we should make "tip" a first-class (optional) member of the contract terms (per choice in v1 -- different currencies!), instead of adding it to the "products" list: it is not a product, so having it there is confusing (and creates issues for internationalization). Instead, I think this is something wallets should just understand and render accordingly. | ||||
| Tags | No tags attached. | ||||
|
|
Note: the 'amount' in the contract terms should be understood to be the total, so *including* the tip. Hence that semantic remains unchanged as the amount to pay. |
|
|
Absolutely agree, 2 questions from my side though: 1. Can I make the Tip to be struct Tip{ Taler_amount tip_amount; char*? tip_description; // So when I or someone else will need to encode some info (like waiterId we can do it without breaking existing code?) char*? user_return_message_to_restaurant; // Not sure about this, but might be oookay, for the use-case I describe lower } 2. I don't really understand how this has to be done... (per choice in v1 -- different currencies!). Will the merchant have to enter a tip for each currency when the order is created? What happens if I come from the template when the user said, I want just this tip... I can make it support an array of tips, but don't really get the checks I have to do... (1. I get an array always, 2. This array has to be of struct Tip, 3. Tip currencies is a subset of Choices currencies) I P.S. With Ivan, we thought that it would be best if a new template type (fixed_contract) were there, then on the wallet side, we can just say oh here you can close the order in one tap, or you can add a tip for the choice you want... Pretty much the wallet will just have to post using template + claim + post order id pay, but for the user, it will still be just one tap interaction to pay for the order. For tips, I think just one step will be added(tap on the percentage you like, or enter the amount yourself), and then pay with one tap. In this case the tip is really user-driven, like when(hm... where the user can enter a tip from their phone, and not on the terminal or some shitty screen... I think some eats ) P.S.S. I think with you we also discussed similar, but that was quite a bit time ago And then pretty much just an idea for future versions. |
|
|
i think it really should just be "tip: Amount". No good to duplicate the type name in the member name. If the tip is to go to a specific waiter, that'll be handled in the backend via the money pots, not something for the user to enter. Yes, we may (soon?) also add the tip_money_pot then to the template, but that's a backend-internal thing. As for the currency, it makes no sense for the user to enter tips in multiple currencies, so what the code already does is something else: if a tip is provided, we drop all choices that are not matching the currency of the tip. If the template would work in multiple currencies, the wallet can of course allow the user to first select the currency before entering the amount, but then we'll just create an order with ONLY the tip-currency choice(s) left. Also note that I put the tip as part of the *common* fields for all templates, so yes, you can already use it with other template types (incl. fixed-order and paivana). And sure, we might add additional template types (like fixed-contract) in the future. But let's not get ahead of ourselves just now -- one feature at a time. Same for tip_description/message: maybe later, it's another feature, let's introduce those things *slowly*. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-19 11:56 | Christian Grothoff | New Issue | |
| 2026-01-19 11:56 | Christian Grothoff | Status | new => assigned |
| 2026-01-19 11:56 | Christian Grothoff | Assigned To | => Bohdan |
| 2026-01-19 11:57 | Christian Grothoff | Note Added: 0027281 | |
| 2026-01-20 10:25 | Bohdan | Note Added: 0027285 | |
| 2026-01-20 11:48 | Christian Grothoff | Note Added: 0027289 |
