|
|
Just discussed with malsasua.
As a summary of the situation:
- There are two configuration fields for the incremental refresh, "time to refresh masterdata", and "time to force masterdata refresh"
- Normally, the blocking part of the masterdata refresh will only happen once the user completes the current ticket.
- However, the second field allows customers to define a timeout, so that once incremental refresh is done in the background, if the current order is not completed in some minutes, the blocking part of the incremental refresh is enforced anyway
- With the provided fix, this timeout is reset every time the users add a product to the basket. This is done to cover the case in which there are many products, and actually scanning them takes quite a long time. As far as we can see, this is working correctly.
- However, once the last product is scanned, if the user doesn't complete the order in the amount of minutes specified in this second field, the incremental refresh will still be enforced, as designed. We believe this is the correct behavior.
- It is very important to take into account that this timeout should be configured to a functionally logical and meaningful value. So, it should be normally configured to something like 10, or 20 minutes in most cases.
- If it is configured like this, the probability that the user takes so much time from scanning the last product, to finally being able to pay and complete the ticket, should be extremely low, and in case this happens, we believe it is a good indication that something went wrong, and the user is most probably not in the terminal at the moment, so it should be fine to force the incremental refresh at this point.
So, in our opinion, we should not implement any further change, and instead we should focus on making sure this timeout value is properly configured, and we should also clearly explain to the customer how this works in practice. |
|