Wednesday, December 4, 2024
6 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where scanning a package within a sublocation of a warehouse didn't correctly update the package's source location in Odoo. Now, the system accurately pulls the correct location ID from the stock data, preventing validation errors and ensuring accurate inventory tracking.
Original PR description
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created Forward-Port-Of: odoo/enterprise#74704
This update fixes an issue where the Accounting module wasn't usable for companies without a chart of accounts template. Now, certain fields are hidden by default, simplifying partner creation and ensuring a smoother experience for users. This change improves usability and avoids unnecessary requirements.
Original PR description
When having Accounting installed with a company without chart template, we can not create a partner as bot `property_account_payable_id` and `property_account_receivable_id` are required. With ff54822738925d5b5b952520bbfbd4a76c876809 we add a non stored computed field to handle the `required` attribute on partner view. We use this field to make the `Accounting Entries` group invisble when it is not needed. opw-4323694 Forward-Port-Of: odoo/enterprise#74994
This update resolves an issue where order completion status was incorrectly determined due to how the system tracked order stages across different display views. The fix ensures that the correct display's stage is used when evaluating order completion, preventing inaccurate status reporting. This improves the reliability of order tracking within the POS system.
Original PR description
This is a post fix for this commit: https://github.com/odoo/enterprise/commit/4c6c902651ad48b1064f1eb4eb326fa773b6b098 We need to filter the stages from the current display when we determine if orders are completed or not since if you change the stage of an order from the display 1, you will first go through `_get_pos_orders` with the display 1 and the last stage in `order_stage_id` is related to display 1. But then you go a second time in `_get_pos_order` but with display 2 and it will always says that the order is not ready since the last stage is related to display 1 and will never be equal to `second_last_stage`. opw-4265987
This update fixes a bug where orders could be duplicated across multiple preparation displays in our POS system. Previously, splitting an order on one display would cause it to reappear incorrectly on others. This change ensures that order status updates are immediate, preventing wasted preparation efforts and potential order losses, especially in environments with limited inter-station communication.
Original PR description
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1.…
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage. 6. back in the POS, create a new order (any table) 7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5 The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2. What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders. After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split. opw-4367937
This update prevents database errors during recurring invoice generation by ensuring deliveries are created in batches and handling potential failures gracefully. If delivery creation fails, an alert is created for the customer and a manual trigger option is available, improving the stability of subscription billing.
Original PR description
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery…
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update. With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail: - The error is caught as to not prevent the next batch from being triggered. - An exception activity is created on the subscription to notify the customer about the error. - A contextual action is available to manually trigger the delivery. OPW-4319019 --- When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:  --- ## Example log ``` 2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. ``` - At the beginning: `payment: post-process transactions` take ~30 secs - Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected). - `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed. --- ## A few points of information/discussion: - The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day. - The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock. - In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one. - I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions. - The exception activity does not directly notify the users via discuss, do you think I should add the option? - I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD
Features or functions removed from Odoo
This change removes a button that allowed users to reboot the IoT Box. This was required by LNE Certification to ensure consistent and scalable certification processes. The button has been removed from the IoT Box form view.
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731