View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005245 | Taler | merchant backend | public | 2018-01-04 12:37 | 2024-01-12 13: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 | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.5 | Fixed in Version | 0.5 | ||
| Summary | 0005245: make /proposal easier to use | ||||
| Description | Right now too much information that could be specified in the backend must be given in the frontend. Ideally /proposal works by only giving: * product name * amount to pay (even as string!) * fulfillment URL (* echoed nonce) All other fields (product list with single item) can then be inferred or looked up from the backend configuration. | ||||
| Tags | No tags attached. | ||||
| related to | 0005198 | closed | Christian Grothoff | merchant should check a reserve's status before adding it as a tipping reserve |
| Note that I'm not suggesting any restrictions on the current API, just some convenience features. You should still be able to specify things / override defaults if desired. | |
| As for address/location data, I had discussed with Florian using something like: [merchant-location-FOO] street = FooStreet 4 city = FooCity country = Fooland [merchant-location-BAR] street = BarStreet 4 city = BarCity country = Barland to generate the 'name->location' map in the contract. "FOO/BAR" would be the labels we can use in the rest of the contract (jurisdiction, shipping address, etc.). Naturally, the frontend must still be able to _extend_ the location set, as the customer's shipping address won't be known to the backend. So a common config might be: [merchant-location-jurisdiction] street = High Street 1 city = BarCity country = Bahamas [merchant-location-shipsfrom] street = FactoryStreet 4 city = BarCity country = China [merchant-location-billing] street = Bank Street 3 city = London country = Divided Kingdom Which would be turned into locations = { "billing" = { "street" : "Bank Street 3", "city" : "London" }, "..." = "..." } (pardon my JSON syntax, likely some brackets wrong, but you get the idea). | |
| Fixed in f52a678f | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-01-04 12:37 | Florian Dold | New Issue | |
| 2018-01-04 12:37 | Florian Dold | Status | new => assigned |
| 2018-01-04 12:37 | Florian Dold | Assigned To | => Marcello Stanisci |
| 2018-01-04 12:37 | Florian Dold | Note Added: 0012724 | |
| 2018-01-13 15:37 | Christian Grothoff | Note Added: 0012783 | |
| 2018-01-13 15:37 | Christian Grothoff | Severity | minor => feature |
| 2018-01-13 15:37 | Christian Grothoff | Product Version | => git (master) |
| 2018-01-13 15:37 | Christian Grothoff | Target Version | => 0.5 |
| 2018-01-15 12:12 | Florian Dold | Assigned To | Marcello Stanisci => Florian Dold |
| 2018-01-15 14:35 | Christian Grothoff | Relationship added | related to 0005198 |
| 2018-01-17 22:56 | Florian Dold | Status | assigned => informing |
| 2018-01-17 22:56 | Florian Dold | Resolution | open => fixed |
| 2018-01-17 22:56 | Florian Dold | Note Added: 0012794 | |
| 2018-04-15 18:35 | Christian Grothoff | Fixed in Version | => 0.5 |
| 2018-04-15 18:36 | Christian Grothoff | Status | informing => closed |
| 2024-01-12 13:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |