Daily updates from Odoo
Saturday, June 21, 2025
14 changes
10 changes
Enhancements to existing features
Point of Sale no longer shows old IoT Box setup notifications that are no longer relevant. This reduces confusion for users during device setup and keeps the interface focused on current actions.
Original PR description
We used to display notifications like "We're waiting for your IoT Box to send its devices", that no longer make sense. This commit remove those notifications. Task: 4853242
Blackbox devices can now be recognized correctly by default in IoT setups, without needing an extra Belgian POS blackbox module installed. This avoids them being mistaken for weighing scales, making device setup more reliable for affected businesses.
Original PR description
In order to detect blackboxes as blackboxes instead of adam scales, without installing `pos_blackbox_be` module, we added it to the list of modules from which we download driver. Task: 4787403
Resolved issues and error corrections
This fix makes the IoT payment terminal library download process handle system access changes more safely. It prevents avoidable setup errors when installing or updating the required Worldline payment component, improving reliability for connected payment devices.
Original PR description
The call to the script downloading and extracting `libeasyctep.so` was returning a traceback if it failed to remount the system readonly. We moved the rw/ro mounting logic from the sh script to the python call to avoid this. Task: 4852374
Fixes an issue where adding or changing a cover image on a Knowledge article could fail. Users can now use the Add Cover action as expected, restoring a smoother article editing experience.
Original PR description
There was an issue with Knowledge article cover selection where a user would not be able to change the cover. The issue was introduced with https://github.com/odoo/enterprise/commit/d89f6ddbc4e4402592f31b41db0174dbf3154036 refactoring. This commit restores the proper `arg` format for the `update` function. opw-4845517
Bank reconciliation no longer shows blank action buttons when all reconciliation models have been deleted. This prevents users from clicking a broken button and encountering an error during accounting reconciliation.
Original PR description
Reproduce: 1. Install Accounting 2. Accounting > Bank: Click on some unreconciled statement line There are some buttons like "Internal Transfer" representing reconciliation models. 3. Delete all…
Reproduce:
1. Install Accounting
2. Accounting > Bank: Click on some unreconciled statement line There are some buttons like "Internal Transfer" representing reconciliation models.
3. Delete all reconciliation models.
4. Accounting > Bank: Click on some unreconciled statement line There is a button w/o label. Clicking on it gives an error. (In debug mode the button generation gives an error already) There should be no buttons at all
The issue is that the `get_available_reconcile_model_per_statement_line` can return sth like this in case no reconcilation model was found for statement lines with id 18, 19, 20, 21.
```python
{
18: [{'id': None, 'display_name': None}],
19: [{'id': None, 'display_name': None}],
20: [{'id': None, 'display_name': None}],
21: [{'id': None, 'display_name': None}]
}
```
Since the javascript code assumes that `{'id': None, 'display_name': None}` actually represents a reconciliation model, the error occurs.
After this commit `{'id': None, 'display_name': None}` entries should not appear anymore. In the example an empty dictionary would be returned
task: NoneMiscellaneous changes
**Version:** 16.0 **Steps to reproduce:** - Install industry_fsm_sale - Create two tasks without linking them to a Sale Order - Go to list view and select those tasks - Click "Create Invoice" **Issue:** When the user selects tasks from the list view that are not linked to any Sale Order and tries to create an invoice, a traceback occurs. **Cause:** At least one linked Sale Order record is required when generating an invoice. If the selected tasks are not associated w
Original PR description
**Version:**
16.0
**Steps to reproduce:**
- Install industry_fsm_sale
- Create two tasks without linking them to a Sale Order
- Go to list view and select those tasks
- Click "Create Invoice"
**Issue:**
When the user selects tasks from the list view that are not linked to any Sale Order and tries to create an invoice, a traceback occurs.
**Cause:**
At least one linked Sale Order record is required when generating an invoice. If the selected tasks are not associated with any Sale Order, the process fails.
**Fix:**
This commit raise a red toast notification if none of the selected tasks are linked to a Sale Order. This helps the user understand the issue and prevent traceback..
task-4594178`
Forward-Port-Of: odoo/enterprise#87822
Forward-Port-Of: odoo/enterprise#83661Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module Community PR: https://github.com/odoo/odoo/pull/2133
Original PR description
Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module Community PR: https://github.com/odoo/odoo/pull/213379 Forward-Port-Of: odoo/enterprise#87993 Forward-Port-Of: odoo/enterprise#87204
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type: Expense * Period: [this month] * Budget Lines: [a line with an analytic account (AA) in 2 plans] - Open the budget **Issue 1:** Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount. The PO line and
Original PR description
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type:…
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type: Expense * Period: [this month] * Budget Lines: [a line with an analytic account (AA) in 2 plans] - Open the budget **Issue 1:** Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount. The PO line and the Budget button appear in red, but it shouldn't because the analytic distribution of the line doesn't match all the accounts defined on the budget line. The line will not impact the budget, but it appears in red, which is confusing. **Cause 1:** When computing the budget lines linked to the PO line, the domain that is used is only taking into account the plans that are set on the PO line, ignoring the plans that are not set. For the Budget button, all the PO lines are used instead of just those having the correct analytic distribution. **Issue 2:** - Create a PO at the current date with 2 lines: 1) a line with the same AA than the budget line and an amount higher than the budget amount 2) a line with the same AA than the budget line and an amount lower than the budget amount - Save the PO The first line should be red, but it is not. **Cause 2:** When computing the budget lines linked to the PO lines, only the last PO line has its value set. opw-4757067 Forward-Port-Of: odoo/enterprise#87884
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:** - enable "analytic accounting" setting - Unarchive MTO route - Create a new product - In the inventory page check MTO and Manufacture routes - click on the Bill of materials smart button and create a new BOM - add a component and an operation - Create another product, set "produc
Original PR description
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:**…
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:** - enable "analytic accounting" setting - Unarchive MTO route - Create a new product - In the inventory page check MTO and Manufacture routes - click on the Bill of materials smart button and create a new BOM - add a component and an operation - Create another product, set "product type" as service - in the "create on order" field select "project & task" - create a new quotation with these two products and confirm - click on the "manufacturing" smart button - in the work orders page click on the "open work order" button at the right of the line - click on add a line - set a duration of 30:10 and clik elsewhere on the screen - save - click on the "analytic account" smart button - select the only line and click on the "gross margin" smart button **Current behavior:** There is a single line with an amount of 0.01 **Expected behavior:** The price should reflect the hourly rate of the employee for the task (that's 50.28 with a 100$/hours rate for instance) **Cause of the issue:** There is two issue here. First Issue : When clicking on save on the widget, this will modify the time_ids field of the mrp.workorder this will create a new mrp.workcenter.productivity with the values we wrote. Consequently, on the vals_list when the create method is triggered duration is set to the duration we wrote (so here 30.17) Because of this, when the _compute_duration is the triggered previous_durations will be [30.17] and _create_analytic_entry will be called with a parameter of 30.17 https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L14 Therefore, inside _create_analytic_entry duration will be 0 and amount will also be 0 This issue does not happen if the duration is set by changing the "real duration" in the "work orders" page of the manufacturing order. This is because when doing it this way, we modify the duration of the mrp.workorder which triggers the set_duration_method which also creates a new mrp.workcenter.productivity but here the _prepare_timeline_vals returns a dictonary without a duration field https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workorder.py#L352-L353 Second Issue: The line we see with a 0.01 amount is actually created before we save. It's created from the onchange method when we change the duration on the form. The onchange of duration triggers an onchange of start date which gets the value of duration and triggers of recomputation of duration https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L522-L531 As a consequence, _compute_duration is called. self.duration is initially not rounded so in our exemple previous duration will be equal to 30.1666666666668 https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L11 However after the call to super()._compute_duration(), self.duration will be rounded thanks to the use of convert to duration inside the super method https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L472 So when doing the difference here inside _create_analytic_entry https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L38 duration will be 5.555555555556424e-05 and amount will be -0.005555555555556424 which results in the creation of this line with an amount of 0.01 **fix:** Calling the creation of account.analytic.line from the compute method leads to other problems : For instance, if a line is added in the "open work order" widget and we change the end date but change our mind and don't save the line, the duration will have been computed and a new account analytic line will have been created Whereas calling the method _create_analytic_entries from create() and write() ensures it's only called when the model is saved opw-4715690 Forward-Port-Of: odoo/enterprise#85517
This [commit](https://github.com/odoo-dev/enterprise/commit/43088c9c7cd40fe1c8a088e959a0c8b510990061#diff-58e5e345ff4395ccf7e6c13178e3c909cb18204ffcdceaa7352bd67b9d3432c8) changed the group on the Transfers menuitem button as specified by the specs of its tasks but it was later removed from the specs altough kept in the changes. We realized we did not want that change now and this commit addresses that. task-none Forward-Port-Of: odoo/enterprise#88019
Original PR description
This [commit](https://github.com/odoo-dev/enterprise/commit/43088c9c7cd40fe1c8a088e959a0c8b510990061#diff-58e5e345ff4395ccf7e6c13178e3c909cb18204ffcdceaa7352bd67b9d3432c8) changed the group on the Transfers menuitem button as specified by the specs of its tasks but it was later removed from the specs altough kept in the changes. We realized we did not want that change now and this commit addresses that. task-none Forward-Port-Of: odoo/enterprise#88019
3 changes
Enhancements to existing features
The stock barcode expiry workflow test was updated to account for the confirmation step shown when expired products are received. This helps ensure the system continues to handle expired product receipts as expected without disrupting barcode operations.
Original PR description
Adapt test to expect and confirm the expiration confirmation wizard as we are receiving expired products. task-4040821
Resolved issues and error corrections
This fixes an error in Website Studio that occurred when users added a form and chose the model selection action. The missing shared function is now registered, so the form setup flow works as expected.
Original PR description
Since [1] when actions were converted to classes, the `selectModel` method is called through the dependencies/shared function mechanism. Unfortunately, the function could not be found because it was not registered as a shared function. This commit adds the function to the list of shared functions. Steps to reproduce: - Install website_studio - Drop a form - Pick the "Mode models" action => There was an error because `selectModel` could not be found. [1]: https://github.com/odoo/enterprise/commit/1f8b599a23330b03bffd898d85fe74a0f0eeda1f task-4367641
Miscellaneous changes
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653 Forward-Port-Of: odoo/enterprise#88080 Forward-Port-Of: odoo/enterprise#82949
Original PR description
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653 Forward-Port-Of: odoo/enterprise#88080 Forward-Port-Of: odoo/enterprise#82949
1 change
Miscellaneous changes
This pull request adds a new file named minh.txt. It appears to be a minor repository-only change with no described business process or user-facing impact.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr