Tuesday, June 25, 2024
4 changes · 17.0
Enhancements to existing features
When creating a new preparation display, it will now start with an empty backlog instead of showing all past orders. This ensures new displays only show orders created after they are set up, providing a cleaner and more organized workflow for restaurant staff.
Original PR description
Steps to reproduce: - Create a preparation display - Create orders to appear in it - Create a new preparation display Behavior: - Past orders before the creation of the preparation display still appear. Intended behaviour: - New preparation display needs to be empty. Reference: opw-4008808
This update significantly improves the speed of the POS preparation display system by filtering out completed orders before processing them, rather than processing all orders and filtering afterward. This eliminates unnecessary work when many orders are already done, resulting in dramatic performance improvements—up to 114x faster in scenarios where most orders are completed.
Original PR description
## Changes in the pos_preparation_display/models/preparation_display_order.py: The previous code used to have low selectivity in the initial recordset returned by the search function. Then the…
## Changes in the pos_preparation_display/models/preparation_display_order.py: The previous code used to have low selectivity in the initial recordset returned by the search function. Then the records were filtered on their state inside the for loop which increased the number of get requests to view the order stages. This approach caused a bottleneck in the following situation: - All the records are in the done stage and will be processed to filter them out, but not viewed which takes a lot of resources and no result in the end. - Some of the records are in the done stage, This would add an overhead to the processing of the function with irrelevant records to filter out the done orders. Solution: - Reduce the recordset being returned in the first place from the search function by adding filters to return only the ones in progress by running an `_read_group` function that returns the orders that do not have a completed stage in the current preparation display. This recordset is then added to the new orders that still do not have stages and are in the current preparation display as well. ## Changes in the pos_preparation_display/models/preparation_display.py: The previous code would process all the records to be in the done state even though they could be already done. This approach causes an issue in the following situation: - All the records are archived, but pressing on archive all again, processes all the records again with no benefit added. Solution: - Same as above, reduce the recordset to return the orders still in progress only. Also note that the reset was limited for 1000 records only and with the previous setup, pressing archive multiple times would result in the same processing over the same 1000 records, Which is why the limit was removed ## Benckmark | | Before| After| Orders done | Number of records |Speed up |---|----|-----|------|---------|--------- Time | 15 s | 12 s | No | 170k |1.25x Time | 6 s | 302 ms | yes| 170k |19x This speed up is because all of the records are archived and put in the done state thus not selected by the _read_group function in the first place. Under different circumstances the speed up would differ on the ratio between done and not done orders. But under the assumption that the number of orders on the display order at a single time, the speed up is considerable. ## Reference opw-3865664 Forward-Port-Of: odoo/enterprise#62996
Users can now change their CodaBox password that was initially provided during setup. A new password change wizard has been added to make this process simple and secure. This improvement gives users more control over their account security for Belgian bank connections.
Original PR description
This commit allows the user the password provided by IAP during the first connection. A new wizard has been added for this. task-id: 3857241 IAP: https://github.com/odoo/iap-apps/pull/790
This update adds comprehensive test coverage for three important GST treatment scenarios in India's GSTR-1 reporting: deemed exports, composition schemes, and UIN holders. These new tests ensure the system correctly handles these specific GST categories, improving the reliability and accuracy of GST compliance reporting for Indian businesses.
Original PR description
**Before this PR:** There were no test cases written for the following three GST treatments: deemed export, composition and UIN holder. **After this PR:** Test cases have been added for the deemed export, composition and UIN holder GST treatments. **task**-3892511 Forward-Port-Of: odoo/enterprise#63333