View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009521 | Taler | merchant backoffice SPA | public | 2025-02-06 13:41 | 2025-02-14 22:42 |
| Reporter | svirv1 | Assigned To | sebasjm | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Target Version | 1.0 | Fixed in Version | 1.0 | ||
| Summary | 0009521: delivery location field missing | ||||
| Description | Delivery location field is missing in order creation in SPA, but exists in backend: interface OrderCommon { // Human-readable description of the whole purchase. summary: string; // Map from IETF BCP 47 language tags to localized summaries. summary_i18n?: { [lang_tag: string]: string }; // Unique identifier for the order. Only characters // allowed are "A-Za-z0-9" and ".:_-". // Must be unique within a merchant instance. // For merchants that do not store proposals in their DB // before the customer paid for them, the order_id can be used // by the frontend to restore a proposal from the information // encoded in it (such as a short product identifier and timestamp). order_id?: string; // URL where the same contract could be ordered again (if // available). Returned also at the public order endpoint // for people other than the actual buyer (hence public, // in case order IDs are guessable). public_reorder_url?: string; // See documentation of fulfillment_url field in ContractTerms. // Either fulfillment_url or fulfillment_message must be specified. // When creating an order, the fulfillment URL can // contain ${ORDER_ID} which will be substituted with the // order ID of the newly created order. fulfillment_url?: string; // See documentation of fulfillment_message in ContractTerms. // Either fulfillment_url or fulfillment_message must be specified. fulfillment_message?: string; // Map from IETF BCP 47 language tags to localized fulfillment // messages. fulfillment_message_i18n?: { [lang_tag: string]: string }; // List of products that are part of the purchase. products?: Product[]; // Time when this contract was generated. If null, defaults to current // time of merchant backend. timestamp?: Timestamp; // After this deadline has passed, no refunds will be accepted. // Overrides deadline calculated from refund_delay in // PostOrderRequest. refund_deadline?: Timestamp; // After this deadline, the merchant won't accept payments for the contract. // Overrides deadline calculated from default pay delay configured in // merchant backend. pay_deadline?: Timestamp; // Transfer deadline for the exchange. Must be in the deposit permissions // of coins used to pay for this order. // Overrides deadline calculated from default wire transfer delay // configured in merchant backend. Must be after refund deadline. wire_transfer_deadline?: Timestamp; // Base URL of the (public!) merchant backend API. // Must be an absolute URL that ends with a slash. // Defaults to the base URL this request was made to. merchant_base_url?: string; // Delivery location for (all!) products. **delivery_location?: Location;** // Time indicating when the order should be delivered. // May be overwritten by individual products. // Must be in the future. delivery_date?: Timestamp; // See documentation of auto_refund in ContractTerms. // Specifies for how long the wallet should try to get an // automatic refund for the purchase. auto_refund?: RelativeTime; // Extra data that is only interpreted by the merchant frontend. // Useful when the merchant needs to store extra information on a // contract without storing it separately in their database. // Must really be an Object (not a string, integer, float or array). extra?: Object; } | ||||
| Tags | No tags attached. | ||||
|
|
delivery location is shown if delivery date is set |
|
|
check if the expected behavior is what we want |
|
|
I'm also not sure if this is what we want, I could imagine a case where the delivery location is fixed (by contract), but the delivery data is simply so unknown that both parties just leave it open. The protocol does NOT say that having a delivery location requires having a delivery date. Plus, at least in some cases, the location of the customer might be needed for tax purposes, even though there is no physical delivery. So I'd probably go and allow exactly what the protocol allows: setting both independently. Florian, any opinion? |
|
|
I agree that delivery location and date should be treated separately. IMO there are are many scenarios where you'd only specify one of them. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-02-06 13:41 | svirv1 | New Issue | |
| 2025-02-06 13:41 | svirv1 | Status | new => assigned |
| 2025-02-06 13:41 | svirv1 | Assigned To | => sebasjm |
| 2025-02-07 00:03 | Christian Grothoff | Severity | minor => tweak |
| 2025-02-07 00:03 | Christian Grothoff | Target Version | => 1.0 |
| 2025-02-11 16:45 | sebasjm | Note Added: 0024068 | |
| 2025-02-11 16:46 | sebasjm | Status | assigned => feedback |
| 2025-02-11 16:46 | sebasjm | Note Added: 0024069 | |
| 2025-02-11 21:27 | sebasjm | Assigned To | sebasjm => svirv1 |
| 2025-02-12 10:35 | Christian Grothoff | Note Added: 0024078 | |
| 2025-02-12 10:35 | Christian Grothoff | Assigned To | svirv1 => Florian Dold |
| 2025-02-12 14:41 | Florian Dold | Note Added: 0024079 | |
| 2025-02-12 14:41 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2025-02-12 15:33 | sebasjm | Status | feedback => resolved |
| 2025-02-12 15:33 | sebasjm | Resolution | open => fixed |
| 2025-02-14 22:42 | Christian Grothoff | Fixed in Version | => 1.0 |
