View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009244 | Taler | mechant backend | public | 2024-10-02 19:11 | 2024-10-07 16:35 |
| Reporter | Florian Dold | Assigned To | Florian Dold | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Target Version | 0.14 | Fixed in Version | 0.14 | ||
| Summary | 0009244: merchant should refuse order creation when it would trigger a DEPOSIT limit | ||||
| Description | Creating this order would lead to an order that the user can't possibly pay for. | ||||
| Tags | No tags attached. | ||||
| related to | 0009171 | resolved | Florian Dold | merchant kyc integration test [4h] |
| related to | 0009218 | resolved | Florian Dold | merchant's /private/kyc endpoint does not update KYC status after AMLO decision |
|
|
Hmm. taler-merchant-http_private-post-orders.c actually has code for exactly this (see: get_acceptable). Do you have a test to easily reproduce this? |
|
|
Can be reproduced easily by $ taler-harness run-integrationtests kyc-merchant-deposit But that test currently dies because of the assertion for 0009245. Do you need a separate test that just triggers the order creation or can 0009245 be fixed first? |
|
|
From what I see here at *taler-merchant-httpd_private-post-orders.c:2253*: >> if (1 == TALER_amount_cmp (&oc->parse_order.brutto, &oc->set_exchanges.total_exchange_limit)) << the merchant backend determines that a hard limit of *TESTKUDOS:5* applies, and the order is *exactly for 5 TESTKUDOS, so it is allowed. If I change the test to allow only orders that are strictly below, it seems to me that the test fails differently (but still fails). So I think this is: 1) test failure: the order total must be strictly above the limit, and 2) test failure: even if I change this in the merchant backend, the test still fails. Please confirm/refute! |
|
|
The config has the following rule: [KYC-RULE-R1] OPERATION_TYPE = deposit ENABLED = yes EXPOSED = yes IS_AND_COMBINATOR = yes THRESHOLD = TESTKUDOS:0 TIMEFRAME = 1d NEXT_MEASURES = M1 So I'm not sure why you're saying that a hard limit of TESTKUDOS:5 applies. This is about a *deposit* limit, not a hard limit. The order creation should still fail, since wallets won't be able to pay for the order until the merchant does KYC. |
|
|
Latest Git fixes the issue (we only checked hard limits, not soft zero limits). You also must upgrade the exchange. However, test still fails, despite the merchant now clearly returning 451. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-10-02 19:11 | Florian Dold | New Issue | |
| 2024-10-02 19:11 | Florian Dold | Status | new => assigned |
| 2024-10-02 19:11 | Florian Dold | Assigned To | => Christian Grothoff |
| 2024-10-02 19:17 | Florian Dold | Relationship added | related to 0009171 |
| 2024-10-02 19:31 | Florian Dold | Relationship added | related to 0009218 |
| 2024-10-02 19:54 | Christian Grothoff | Note Added: 0023428 | |
| 2024-10-04 15:02 | Florian Dold | Note Added: 0023439 | |
| 2024-10-06 17:46 | Christian Grothoff | Note Added: 0023452 | |
| 2024-10-06 17:47 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-10-06 17:47 | Christian Grothoff | Status | assigned => feedback |
| 2024-10-07 10:33 | Florian Dold | Note Added: 0023462 | |
| 2024-10-07 10:33 | Florian Dold | Assigned To | Florian Dold => Christian Grothoff |
| 2024-10-07 16:00 | Christian Grothoff | Assigned To | Christian Grothoff => Florian Dold |
| 2024-10-07 16:00 | Christian Grothoff | Note Added: 0023466 | |
| 2024-10-07 16:01 | Christian Grothoff | Status | feedback => assigned |
| 2024-10-07 16:27 | Florian Dold | Status | assigned => resolved |
| 2024-10-07 16:27 | Florian Dold | Resolution | open => fixed |
| 2024-10-07 16:35 | Christian Grothoff | Fixed in Version | => 0.14 |
