Daily updates from Odoo
Navigate
Branch
Wednesday, April 9, 2025
31 changes
Enhancements to existing features
Manufacturing work orders can now have their status edited more flexibly, reducing situations where teams are stuck with irreversible state changes. This simplifies day-to-day shop floor management and makes future improvements easier to support.
Original PR description
- Allow manual editing of work order states to provide greater flexibility. - Simplify work order status computation, reducing rigid state dependencies. - Minimize state recalculations, ensuring a more straightforward and maintainable codebase. - Address pain points where state transitions were irreversible and difficult to modify. - Facilitate easier application of future changes and enhancements. Task: [4289826](https://www.odoo.com/odoo/966/tasks/4289826) https://github.com/odoo/odoo/pull/194841 https://github.com/odoo/upgrade/pull/7405
This update replaces bulky three-dot menu icons with a cleaner Odoo icon style across several apps. The change improves visual consistency in key menus without changing functionality.
Original PR description
*: account_reports, appointment, knowledge, l10n_us_reports, planning, sign, social, social_crm, spreadsheet_edition, web_studio - requires : https://github.com/odoo/odoo/pull/204473 ----------------------- This PR replaces all the existing occurrences of `fa-ellipsis-*` with the new `oi-ellipsis-*` icons. Prior to this PR, we were relying on Font Awesome ellipsis icons which comes with squared dots that look quite bulky. As the ellipsis icon is shown in some key places, we decided to slightly tweak it to improve the visual result. Note that the fa-ellipsis-* still exist and remain available but in order to maintain the consistency, we highly recommend to use `oi-ellipsis-v` and `oi-ellipsis-h` from now on. task-4551038
The update removes or hides settings and features that only apply to certain regions, such as EU or SEPA-related options, when users are outside those regions. This makes Odoo screens clearer and reduces confusion by showing businesses only the options that are relevant to their country.
Original PR description
*= delivery_sendcloud. This **PR** enhances clarity for users by removing settings and features that are irrelevant to their region. Currently, certain elements specific to the EU or SEPA are displayed globally, which can confuse users in other regions where these features do not apply. By hiding these irrelevant elements, the interface becomes more streamlined, improving usability and aligning the modules more closely with user expectations. **task**-4356567 **Community PR**: https://github.com/odoo/odoo/pull/189315 **Upgrade PR**: https://github.com/odoo/upgrade/pull/6885
Website appointment bookings now reuse existing customer and sales lead information when possible instead of creating duplicates. Returning visitors are more likely to keep the same salesperson across bookings, improving continuity for customers and reducing clutter in the sales pipeline.
Original PR description
This commit introduces a mechanism to re-use leads and partners records when appointments are booked on the website. Indeed, before these changes, new partners and new leads were always created, leading to data duplication. This also allows us to re-assign the same salesperson when you book several appointments, easing the sales process and maintaining a single contact point. It was split in 3 different commits: - improve the appointment alert display -> Small UI tweaks - link public visitors and booked calendar events -> Similarly to what we do with event.registrations, which allows us to re-use the calendar.event partner record on subsequent bookings - auto-assign salesperson and re-use leads See underlying commits for details. task-4247031
A Studio automated test was updated to match recent wording changes for set and not set filter operators. This helps keep quality checks aligned with the current product behavior and reduces the risk of false test failures.
Original PR description
We adapt a studio test to the changes brought by https://github.com/odoo/odoo/pull/205180
Partner-specific internal instructions from stock picking records are now visible directly in barcode operations when they have been set. This helps warehouse teams see relevant handling guidance without leaving the barcode workflow, reducing missed instructions and extra navigation.
Original PR description
The partner-specific internal instructions displayed on the stock picking view are now also visible on barcode operations view (if such instructions were set by the user). Task ID: [4268689](https://www.odoo.com/odoo/project/966/tasks/4268689)
The Spanish chart of accounts and related balance sheet reports have been updated to align with 2024 legal requirements. This helps companies using Spanish localization keep their accounting reports compliant with current regulations.
Original PR description
This commit update the Spanish Charts of Accounts, to respect the 2024 legal requirements linked:https://github.com/odoo/odoo/pull/203974 task-4512619
The chat window now shows a more polished “is typing” status for instant messages. This small visual improvement makes conversations feel clearer and more professional for users communicating through WhatsApp.
Resolved issues and error corrections
Self-ordering now correctly shares one order when multiple guests scan the same table and choose to pay after the meal. This avoids duplicate or conflicting orders and gives staff and diners a clearer restaurant ordering experience.
Original PR description
When self ordering is setup with pay after meal, and two users scans the same table. The order is now shared between the two users. Taskid: 4489980 X-original-commit: 98f0534
This fixes an issue where completing a manufacturing order through the barcode app could record the full planned component quantity even when only part was actually consumed. Businesses will now see more accurate component usage and inventory records for completed production orders.
Original PR description
Current Behavior ================ When using barcode application, If only a partial quantity of a component is consumed in the production of the final product and the production is confirmed, the…
Current Behavior ================ When using barcode application, If only a partial quantity of a component is consumed in the production of the final product and the production is confirmed, the backend incorrectly reflects the full consumption of the component. Expected behavior ================= Only the consumed quantity of the component should be reflected in the backend, not the full quantity, when the final product is fully produced using a partial component. Steps To Produce ================ - Create a production order for 10 units of a final product, consuming 10 units of a component, and confirm the production. - In the barcode application, add 10 units of the final product and 5 units of the component. - In the backend, the component consumption still shows 10 units, even though only 5 were consumed. Issue ===== With the introduction of PR https://github.com/odoo/enterprise/pull/71776, New move lines were being created and linked to the production if the component's move had a quantity done less than the demand, even if the production was fully completed. Fix === Move lines will now only be created if part of the final product is produced. If the production is fully completed, no new move lines will be created. Task: [4558547](https://www.odoo.com/odoo/my-tasks/4558547)
Code cleanup and technical improvements
Customer recipients are no longer automatically added as followers when sending appointment, HR, and direct debit communications. This keeps followers focused on internal users while making customer recipients clearer and more intentional in messages and templates.
Original PR description
Since [1] customers are given as default or suggested recipients for communications. Both chatter and templates proposes them by default. Followers should now be mostly be internal users that want to receive news from a record while customers should be actively displayed and chosen. In this PR calendar mainly is updated. We know correctly use attendees when mailing events instead or relying always on followers and forced subscription. See also [2] and [3] that already worked on that specific issue. Task-4655022 [1] odoo/odoo#185240 [2] odoo/odoo#201514 [3] odoo/odoo#204326
This change tidies an internal mail testing helper by making it private. It does not change product behavior for users, but helps keep the test code clearer and easier to maintain.
Original PR description
part of task-4712367. community: https://github.com/odoo/odoo/pull/205186
Miscellaneous changes
If an order is send to the preparation display from a retail shop `false` was shown as card name. This was because `floating_order_name` is not used in retail shops. New behavior from retail shop: - Order card name is `tracking_number (pos_reference)` New behavior from restaurant: - Order card name is `floating_order_name` or `Direct Sale` or `table_number`. taskId: 4711882 Forward-Port-Of: odoo/enterprise#83028
Original PR description
If an order is send to the preparation display from a retail shop `false` was shown as card name. This was because `floating_order_name` is not used in retail shops. New behavior from retail shop: - Order card name is `tracking_number (pos_reference)` New behavior from restaurant: - Order card name is `floating_order_name` or `Direct Sale` or `table_number`. taskId: 4711882 Forward-Port-Of: odoo/enterprise#83028
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this
Original PR description
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/178142 opw-3841495 Forward-Port-Of: odoo/enterprise#82866 Forward-Port-Of: odoo/enterprise#69036
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user having another company : base.demo_company_fr This creates the following error message when running the tests: ```Py FAIL: TestDocumentsControllers.test_upload_internal_multi_company_defaults Traceback (most recent call last): File "/home/odoo/src/enterprise/documents/tests/test_controllers.p
Original PR description
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user…
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user having another company : base.demo_company_fr
This creates the following error message when running the tests:
```Py
FAIL: TestDocumentsControllers.test_upload_internal_multi_company_defaults
Traceback (most recent call last):
File "/home/odoo/src/enterprise/documents/tests/test_controllers.py", line 953, in test_upload_internal_multi_company_defaults
self.assertEqual(self.user_admin.company_ids, main_company | comp)
AssertionError: res.company(28, 1, 110) != res.company(1, 110)
```
with the following command :
```bash
python3 odoo-bin --addons-path="addons/,../enterprise/" -d test_4507424 -i documents,accountant,l10n_fr_account --test-tags .test_upload_internal_multi_company_defaults
```
(make sure to use the correct python3, odoo-bin, and addons-path)
This commit fixes the test by removing the constraint that self.user_admin can only have 2 companies
After this commit, the test is successful with the same configuration and execution command
opw-4700255
opw-4507424
Forward-Port-Of: odoo/enterprise#82869Issue ===== When displaying the Barcode move line form view on mobile, a traceback can happen. How to reproduce ================ - Open the Barcode app on a mobile device (or use devtools to simulate a mobile device;) - Create a new receipt; - Click on "Add Product" and select a product with an existing quant; - Confirm then re-open the move line's form view -> Traceback. Cause of the issue ================== In mobile view, the product's quants displayed in the move line form vie
Original PR description
Issue ===== When displaying the Barcode move line form view on mobile, a traceback can happen. How to reproduce ================ - Open the Barcode app on a mobile device (or use devtools to simulate a mobile device;) - Create a new receipt; - Click on "Add Product" and select a product with an existing quant; - Confirm then re-open the move line's form view -> Traceback. Cause of the issue ================== In mobile view, the product's quants displayed in the move line form view are displayed as kanban record. This kanban view template use the `many2one_uom` widget but doesn't include the `product_id` field which make this widget not usable. By the way, those records are not editable so it makes no sense to use this widget in this case. To fix the issue, remove the widget where it is not needed/not usable. Community PR: odoo/odoo#204252 Forward-Port-Of: odoo/enterprise#82684 Forward-Port-Of: odoo/enterprise#82640
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82912 Forward-Port-Of: odoo/enterprise#81644
Original PR description
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82912 Forward-Port-Of: odoo/enterprise#81644
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/203713 --- I confirm I have signed
Original PR description
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/203713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#83065 Forward-Port-Of: odoo/enterprise#82351
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These of
Original PR description
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These offers, though, don't need that safety net, and can thus just be ignored. If their stock needs to be sync someday, the stock cron will take care of these. opw-4684657 opw-4684605 Forward-Port-Of: odoo/enterprise#83023
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347
Original PR description
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347 Forward-Port-Of: odoo/enterprise#82682
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692
Original PR description
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
Original PR description
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
This PR excludes the employees that started after the 30/06 of the 13th month. They are not elligeable as they started more than 6 months before the payment of the bonus. As part of this PR, the computation of the correct tax rate has been fixed. The amount is bounded so that a tax rate can always be computed. task-4583139 Forward-Port-Of: odoo/enterprise#79923
Original PR description
This PR excludes the employees that started after the 30/06 of the 13th month. They are not elligeable as they started more than 6 months before the payment of the bonus. As part of this PR, the computation of the correct tax rate has been fixed. The amount is bounded so that a tax rate can always be computed. task-4583139 Forward-Port-Of: odoo/enterprise#79923
Steps: - Navigate to Management > Time Off > Gantt View. - Click on a pill to open the popover. Issues: - The date format in the title showed 30/10/2025 instead of 03/10/2025. - Causing inconsistency between the title and the Gantt view. Fix: Updated date formatting to ensure the title and popover both display dates are same in the MM/DD/YYYY format with leading zeros. Task - 4660785 Forward-Port-Of: odoo/enterprise#81890
Original PR description
Steps: - Navigate to Management > Time Off > Gantt View. - Click on a pill to open the popover. Issues: - The date format in the title showed 30/10/2025 instead of 03/10/2025. - Causing inconsistency between the title and the Gantt view. Fix: Updated date formatting to ensure the title and popover both display dates are same in the MM/DD/YYYY format with leading zeros. Task - 4660785 Forward-Port-Of: odoo/enterprise#81890
This pull request (PR) facilitates the integration of Odoo with the Uruguayan electronic billing system, allowing automatic synchronization of vendor bills every 10 minutes. Synchronized bills are created in "Draft" status for user review, complete with attached PDF and XML files. Also this pull request allows to create vendor bills from XML files on uruguayan journals. **Key Features**: - **_Automatic Bill Creation_**: Bills are generated in "Draft" status to enable manual verification a
Original PR description
This pull request (PR) facilitates the integration of Odoo with the Uruguayan electronic billing system, allowing automatic synchronization of vendor bills every 10 minutes. Synchronized bills are…
This pull request (PR) facilitates the integration of Odoo with the Uruguayan electronic billing system, allowing automatic synchronization of vendor bills every 10 minutes. Synchronized bills are created in "Draft" status for user review, complete with attached PDF and XML files. Also this pull request allows to create vendor bills from XML files on uruguayan journals. **Key Features**: - **_Automatic Bill Creation_**: Bills are generated in "Draft" status to enable manual verification against vendor invoices and attachments. - **_Necessary Configuration_**: 1) The database must connect to Uruware. 2) A Uruguayan company must be set up with an appropriate chart of accounts. 3) Notifications must be activated in the Uruguayan billing system. **Important Considerations**: - Errors during synchronization will still create invoices in "Draft" with error messages for user review. - Invoice lines are created without products; if a vendor doesn’t exist, it will be automatically created based on RUT. - Any unregistered taxes will be flagged. **Technical Overview**: - **_Notification Mechanism_**: Notifications for each received CFE are managed through a web service, allowing users to check, request details, and discard notifications. - **_Synchronization Process_**: Notifications are read and processed sequentially, with each CFE generating a corresponding document in Odoo. Notifications must be discarded to continue processing. Related Tasks: Adhoc Task: 43467 LATAM Task: 1249 Forward-Port-Of: odoo/enterprise#71234
Forward-Port-Of: odoo/enterprise#83047
Original PR description
Forward-Port-Of: odoo/enterprise#83047
account_intrastat_report.xml: missing SUCode for xml report generation in l10n_de_intrastat build_error-160011 Forward-Port-Of: odoo/enterprise#81066
Original PR description
account_intrastat_report.xml: missing SUCode for xml report generation in l10n_de_intrastat build_error-160011 Forward-Port-Of: odoo/enterprise#81066
See community PR odoo/odoo#204757 for the bugfix. This commit adds a step to the scale tour to check that the computed price in the popup matches the expected value. The tour is also refactored slightly to make use of POS test helpers. task-4702650 Forward-Port-Of: odoo/enterprise#82873
Original PR description
See community PR odoo/odoo#204757 for the bugfix. This commit adds a step to the scale tour to check that the computed price in the popup matches the expected value. The tour is also refactored slightly to make use of POS test helpers. task-4702650 Forward-Port-Of: odoo/enterprise#82873
This doesn't end up blocking any flow, but it's confusing to have the warning there. l10n_br_edi_avatax_data is deliberately cleared after EDI, because it's no longer needed afterwards. opw-4673601 Forward-Port-Of: odoo/enterprise#82925
Original PR description
This doesn't end up blocking any flow, but it's confusing to have the warning there. l10n_br_edi_avatax_data is deliberately cleared after EDI, because it's no longer needed afterwards. opw-4673601 Forward-Port-Of: odoo/enterprise#82925
Discounts on non recurring products were being recomputed every time the subscription was paused and resumed. Added a protecting similar to action_confirm in order to prevent this behavior. opw-4440500 Forward-Port-Of: odoo/enterprise#82858
Original PR description
Discounts on non recurring products were being recomputed every time the subscription was paused and resumed. Added a protecting similar to action_confirm in order to prevent this behavior. opw-4440500 Forward-Port-Of: odoo/enterprise#82858
This commit fixes an issue with the public sidebar. When you unfold an article the unfolding method was never linked to all the elements needed to unfold any children article. Now when clicking on the unfold button, we are adding the event on each children of the unfolded articles. Forward-Port-Of: odoo/enterprise#82349 Forward-Port-Of: odoo/enterprise#82003
Original PR description
This commit fixes an issue with the public sidebar. When you unfold an article the unfolding method was never linked to all the elements needed to unfold any children article. Now when clicking on the unfold button, we are adding the event on each children of the unfolded articles. Forward-Port-Of: odoo/enterprise#82349 Forward-Port-Of: odoo/enterprise#82003