Daily updates from Odoo
Navigate
Branch
Monday, June 16, 2025
63 changes
23 changes
Enhancements to existing features
This update standardizes date values to use full ISO formatting, ensuring months and days are always written with two digits. It reduces the risk of date parsing errors in payroll, accounting, appointments, manufacturing, and localization processes.
Original PR description
ISO format does not accept single digit months or days. odoo/odoo#214350
Receipts are now available by default and easier to create directly from invoice forms. Users can also find receipts more quickly with new list filters, while companies can apply default receipt taxes through localization setup.
Original PR description
Problem --------- Currently, receipts are well implemented but highly hidden in the depth of Odoo. Users are required to activate the option to see and create receipts. Objective --------- Make it…
Problem
---------
Currently, receipts are well implemented but highly hidden in the depth of Odoo. Users are required to activate the option to see and create receipts.
Objective
---------
Make it easier for users to create and use receipts.
Solution
---------
- Create a new JS widget that mixes the `dynamic_selection` and the radio widgets to only display possible move types on the move form:
- From `in_invoice` to `in_receipt` and inversely;
- From `out_invoice` to `out_receipt` and inversely. And remove the old views as those are not necessary anymore.
- Add filters to the list view to easily retrieve the receipts.
- Remove the two different security groups; receives are now always available.
- Add company default receipt taxes that will be used by default on receipt (over product and account default taxes) to, once again, ease the user experience. Those default taxes are not available from the UI because we don't want to cumbersome the settings any more; instead, they shall be set up in the localization company templates.
task-4677472This update improves how project templates are selected and displayed across field service, helpdesk, timesheets, sales, planning, and project scheduling. Business users should see more relevant template choices, fewer unnecessary fields or views, and a smoother setup flow when creating or managing service projects.
This update adds testing to confirm that AI-generated HTML field content is properly cleaned before use, helping prevent unsafe or unwanted content from being stored or displayed. It also increases the API call timeout, making AI field processing more reliable when responses take longer.
Original PR description
Purpose ======= Add test about sanitization for HTML properties. Increase the timeout limit when calling the API. Task-4712395
Code cleanup and technical improvements
This update reorganizes how WhatsApp and VoIP identify internal users by moving that logic to the user model. It should make the behavior more consistent across related communication features, with no expected change for day-to-day users.
Original PR description
Enterprise counter-part. Part of task-3208257 https://github.com/odoo/odoo/pull/214021
This update clarifies which automated test steps intentionally move users to a new page. It helps make testing more predictable across appointment, documents, helpdesk, point of sale, ecommerce, planning, and signing workflows, reducing false test issues without changing day-to-day user behavior.
Original PR description
In this commit, we add willUnload to steps that require it to explicitly declare that the step will cause the page to be unloaded.
Miscellaneous changes
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float
Original PR description
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float before applying `int()` to convert the value to an integer. This ensures accurate rounding for exported payment amounts. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4858205) opw-4858205 Forward-Port-Of: odoo/enterprise#87703 Forward-Port-Of: odoo/enterprise#87597
Some aggregation expressions used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses terms from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. This was done
Original PR description
Some aggregation expressions used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses terms from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. This was done in https://github.com/odoo/odoo/commit/bbba54a08c56e0a4d040fc8035996d9d7cafedad for the monthly Luxembourgish tax report ; but some other occurrences needed to be fixed. Forward-Port-Of: odoo/enterprise#87492
Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; ot
Original PR description
Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; other values as SLEV are not supported by that format anyway. opw-4535542 Forward-Port-Of: odoo/enterprise#87441 Forward-Port-Of: odoo/enterprise#86996
**Before this commit:** - If the user had a website with a theme, then exporting from `Studio Export` would fail if no changes were made to the view via `web_studio`. **After this commit:** - The export now completes successfully, even when there are no changes made in the view through `web_studio`. task-4815179 Forward-Port-Of: odoo/enterprise#87655 Forward-Port-Of: odoo/enterprise#86972
Original PR description
**Before this commit:** - If the user had a website with a theme, then exporting from `Studio Export` would fail if no changes were made to the view via `web_studio`. **After this commit:** - The export now completes successfully, even when there are no changes made in the view through `web_studio`. task-4815179 Forward-Port-Of: odoo/enterprise#87655 Forward-Port-Of: odoo/enterprise#86972
This commit fixes the alignment of the copy button in ai chats for user messages. --- Behaviour Before this Fix --- The copy button would be aligned on the left side of the chat window while the user message would be on the right side. --- Changes Done for the Fix --- Previously, the flex-reversed class was added in the contentContainer div, which includes the message and its actions. That was removed and now the flex-row-reversed class is added when the chat is not AI. When the chat is
Original PR description
This commit fixes the alignment of the copy button in ai chats for user messages. --- Behaviour Before this Fix --- The copy button would be aligned on the left side of the chat window while the user message would be on the right side. --- Changes Done for the Fix --- Previously, the flex-reversed class was added in the contentContainer div, which includes the message and its actions. That was removed and now the flex-row-reversed class is added when the chat is not AI. When the chat is AI, the flex-row-reversed class is added but this time only for the actions div. --- Behaviour After the Fix --- The copy button is now aligned on the right side, under the user's message. Task-4840542 Forward-Port-Of: odoo/enterprise#86764
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894 Forward-Port-Of: odoo/enterprise#87470
Original PR description
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894 Forward-Port-Of: odoo/enterprise#87470
- Fix error when trying to `Mark as Ready` an order coming from `pos_urban_piper` when using it with a Belgian blackbox. - Now we also correctly send a NS (Normal Sale) to the blackbox. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87648
Original PR description
- Fix error when trying to `Mark as Ready` an order coming from `pos_urban_piper` when using it with a Belgian blackbox. - Now we also correctly send a NS (Normal Sale) to the blackbox. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87648
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into consideration anymore when auto-creating reconciliation rules. This is done as it can be very restrictive. I.e. for parking fees. - We had an issue where on choosing an account that leads to the creation of a new reconciliation model, the existing lines that should now use the new rule won't show
Original PR description
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into…
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into consideration anymore when auto-creating reconciliation rules. This is done as it can be very restrictive. I.e. for parking fees. - We had an issue where on choosing an account that leads to the creation of a new reconciliation model, the existing lines that should now use the new rule won't show it in the UI. This was partially fixed in https://github.com/odoo/enterprise/commit/6a6f4231b60d4c46267b1422bbe3308d1183fcff as it runs the matching algorithm on creation, but on the JS side, we should also reload those lines. This is taken care of here. Also, for general reconciliation rules: - Matching amounts for reco rules now have `or equal to` for the `greater than` and `lower than` selections. - The query that matched the amounts for the reconciliation used the absolute value of the line amount. This was done before as it was thought the users wouldn't care about the sign, but now we think it makes more sense to remove the absolute for some cases. For example, a rule with (Is lower than 0) should match the payable lines only. task-4863744 Forward-Port-Of: odoo/enterprise#87432
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096 Forward-Port-Of: odoo/enterprise#87628 Forward-Port-Of: odoo/enterprise#83681
Original PR description
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096 Forward-Port-Of: odoo/enterprise#87628 Forward-Port-Of: odoo/enterprise#83681
Currently, when the user language is arabic and we try to select the booking tab inside pos, a traceback appears. Steps to reproduce: ------------------- * Make sure shop has activate the booking feature * Set appointment type to "Table" * Set user language to arabic * Open pos session * Open the booking tab > Traceback: ... invalid isoformat string Why the fix: ------------ `.toFormat` was responsible for the "translation" of the date to arabic. opw-4817845 Forward-Port-Of: o
Original PR description
Currently, when the user language is arabic and we try to select the booking tab inside pos, a traceback appears. Steps to reproduce: ------------------- * Make sure shop has activate the booking feature * Set appointment type to "Table" * Set user language to arabic * Open pos session * Open the booking tab > Traceback: ... invalid isoformat string Why the fix: ------------ `.toFormat` was responsible for the "translation" of the date to arabic. opw-4817845 Forward-Port-Of: odoo/enterprise#87121
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow
Original PR description
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow customers to select the current date Reference-https://github.com/odoo/enterprise/commit/32b5db6242a0a9cf43002e3723442be7d0cd210a opw-4844754 Forward-Port-Of: odoo/enterprise#86908
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#86597 Forward-Port-Of: odoo/enterprise#43574
This commit will put the accounting date in optional hide while the invoice date is put as optional show. Also adding a button to view the move. Removing the default filter on the set account wizard. task-4860306 Forward-Port-Of: odoo/enterprise#87347
Original PR description
This commit will put the accounting date in optional hide while the invoice date is put as optional show. Also adding a button to view the move. Removing the default filter on the set account wizard. task-4860306 Forward-Port-Of: odoo/enterprise#87347
In this commit: Improved recognition of multiple invoices in bank statement line when: - Bank statement line and invoices have the same `partner_id`, the amount matches their combined total, and `payment_ref` contains all invoice references - When any 2 of the 3 criteria are satisfied Also, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such mat
Original PR description
In this commit: Improved recognition of multiple invoices in bank statement line when: - Bank statement line and invoices have the same `partner_id`, the amount matches their combined total, and `payment_ref` contains all invoice references - When any 2 of the 3 criteria are satisfied Also, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such match exists, the system proceeds to reconcile it based on a second matching criterion such as amount and/or partner. Also enable full-text search for invoice references within `payment_ref` (e.g., "INV/2025/00027" found in "Payment for INV/2025/00027"). Task: 4797388, 4791517, 4852948 Co-authored-by: hatr-odoo <hatr@odoo.com> Co-authored-by: igbe-odoo <igbe@odoo.com> Forward-Port-Of: odoo/enterprise#86496
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product. - Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved - Click on the wheel icon > Split production > Split in 2 - On the MO-001, SN1 is reserved - Open
Original PR description
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as…
### Steps to reproduce:
- Install both mrp and quality_control
- Create 2 products:
- FP (Final Product)
- COMP (Component) tracked by SN > pu SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.
### Cause of the issue:
Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.
### Fix:
Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.
opw-4656240
Forward-Port-Of: odoo/enterprise#87555
Forward-Port-Of: odoo/enterprise#84606**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to reproduce:** - In settings, enable the "packages" settings - Navigate to Inventory/Configuration/Warehouse Management/ Operations Types - Select "Internal Transfers", in the "Barcode App" page for Source Location, select Mandatory Scan - for "Destination Location" select "after each product"
Original PR description
**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to…
**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to reproduce:** - In settings, enable the "packages" settings - Navigate to Inventory/Configuration/Warehouse Management/ Operations Types - Select "Internal Transfers", in the "Barcode App" page for Source Location, select Mandatory Scan - for "Destination Location" select "after each product" - create a new storable product - Navigate to Inventory/Operations/Physical Inventory - Create a new line and select stock as the location - Select your product - In the package column, create a package and give it a name - Set a quantity > Apply - Open the barcode app, select operations and then internal transfers - Click on New and then Scan WH-Stock and the package name: PACK **Current behavior:** The validate button is higlighted in green and clickable **Expected behavior:** Because we didn't scan a destination location it shouldn't be green and clickabel **Cause of the issue:** When a package barcode is scanned, when _processBarcode calls _processPackage https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007 Inside _processPackage barcodeData.stopped is set to true (1) and this.selectedLineVirtualId is set to false (2) https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533 Because of (1) _processBarcode returns here https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011 and doesn't reach the part of the method where _selectLine is called https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182 (Inside _selectLine the value of selectedLineVirtualId is defined https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274 ) So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is false when a package is scanned When the validate method is called when the user clicks on validate, the method uses the value of this.selectedLine https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779 Because this.selectedLineVirtualID is false, get selectedLine returns false https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309 So the if condition is false, the method is allowed to run and the error notification is not triggered **Fix:** After scanning a package there is no selectedLine so we need another condition opw-4590345 Forward-Port-Of: odoo/enterprise#87446 Forward-Port-Of: odoo/enterprise#83710
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to t
Original PR description
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to the default pdf and xml buttons name and remove _custom_options_initializer overwrite function task-4830113 Forward-Port-Of: odoo/enterprise#86984
40 changes
New functionality added to Odoo
Odoo now supports withholding taxes when registering payments, helping businesses in countries where taxes are withheld at payment time rather than invoice time. This adds a shared localization feature with related settings, payment lines, translations, and tests, while also avoiding unintended effects on unrelated country tax setups.
Original PR description
Adds a new module allowing for the support of withholding taxes at the time of registering a payment. task-3614935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Point of Sale order lines now show the unit of measure, such as kg, next to the quantity. This helps meet EU weighing scale certification requirements and gives staff clearer information when selling weighed products.
Original PR description
This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU. task-4869128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The POS now compares the certified scale checksum with the current one and warns users if they no longer match. This helps businesses quickly identify when a connected scale may no longer meet certification requirements, reducing compliance and transaction risks.
Original PR description
Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed. After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user. task-4873162
The Asset app now hides the Add Properties option when it cannot be used on asset model records. If users try to add properties to an asset without an associated asset model, they now see a clearer error message, reducing confusion and support effort.
Original PR description
This commit introduces two improvements to the 'Add Properties' button in the cog menu of the Asset model: 1. Hides the button if the record has state = 'model'. Previously, the button was available but no action was triggered. 2. Raises an error message if the button 'Add Properties' is clicked in an asset without an asset model associated. Previously, only a warning with the unclear message "You need edit access on the parent doument to update these property fields" was shown. task-4822091
Users can now upload requested documents directly from the Documents list view, matching the existing options in kanban and activity views. This makes document collection more consistent and reduces the need to switch views to complete requests.
Original PR description
Users can upload request documents from the kanban and the activity views. This commit extends this feature to the list view. task-4745800
This change updates U.S. payroll setup to include additional state-specific employer tax and surcharge rates for Alabama, Colorado, and Washington. It helps payroll teams calculate wages and employer contributions more accurately in line with local requirements.
Original PR description
Added salary rules for state: - US: Alabama ESA rate - US: Colorado Support Surcharge rate - US: Colorado Solvency Surcharge rate - US: Washington EAF Rate task-4814709
Resolved issues and error corrections
Some mail conversation data can occasionally reference a participant whose contact profile is no longer available in the browser. This fix skips those incomplete entries when identifying the conversation counterpart, preventing unnecessary crashes and keeping messaging usable.
Original PR description
There are several flows where the persona of a member might not (or no longer) be known in JS. These members should simply be ignored when computing the correspondent of a channel rather than crashing.
Reversed point-of-sale orders in the Indian localization now receive the correct place of supply information. This helps ensure tax and compliance details remain complete when POS orders are reversed.
Original PR description
Before this commit: - The `_compute_l10n_in_state_id` method only considered `pos_session_ids` when assigning the state for Indian POS moves. - Reversed POS orders were ignored, leading to missing `l10n_in_state_id`. After this commit: - Added `reversed_pos_order_id` to the `@api.depends` decorator. - Updated domain to include moves with `reversed_pos_order_id`. Ensures correct place of supply is computed for reversed POS orders as well. OPW: 4862639
The website mega menu now shows as a single-column layout when using sidebar or hamburger header styles, preventing broken navigation displays. The menu size setting is also hidden for these header styles because it does not apply, making configuration clearer for website editors.
Original PR description
Steps to reproduce: - Enter website edit mode. - Click the header. - Select "Sidebar" in the template options. - Save the page. - Click Site > Menu Editor in the backend navbar. - Add a "Mega menu" to the menu and save the dialog. - In the sidebar, open the "Mega menu". - Bug: The layout is broken. The mega menu should be displayed in a single column, but it's displayed in three columns. In this commit, we fix the issue by forcing the columns width of the mega menu to 100% when the header is set to "Sidebar" or "Hamburger". This commit also hides the "Size" option of the mega menu when the header template is set to "hamburger" or "sidebar", as it has no effect with either of these headers. task-4830118
Manufacturing orders now keep components in the intended bill of materials order when a kit is included. This prevents confusing or incorrect component move sequencing, making production lists match how products were defined.
Original PR description
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1…
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.
Steps to reproduce:
- Create a product P1 with a BoM that includes:
- Component 1 (sequence = 1)
- Component 2 - KIT (sequence = 2), which itself contains:
- Component 2-1 (sequence = 1)
- Component 2-2 (sequence = 2)
- Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.
Observed behavior:
- The generated stock moves are ordered as:
1. Component 1
2. Component 3
3. Component 2-1
4. Component 2-2
Expected behavior:
- The stock moves should respect the BoM line sequence:
1. Component 1
2. Component 2-1
3. Component 2-2
4. Component 3
Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430
Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.
opw-4809095This fix makes an automated website event test wait until editing is properly finished before moving on. It reduces random test failures caused by timing differences, helping keep quality checks stable without changing customer-facing behavior.
Original PR description
The test `test_website_event_tour_admin` fails randomly depending on the processing speed available. When clicking on `a[title='Back to All Events']`, if the website happens to still be in edit mode, the click will be prevented: https://github.com/odoo/odoo/blob/18.0/addons/website/static/src/client_actions/website_preview/website_preview.js#L424-L438 We can use the clickOnSave function made specifically for this. It ensures exiting edit mode before continuing. --- runbot-223022
Delivery options that require product tags are now shown when an order contains at least one product with one of the required tags. This prevents valid shipping methods from disappearing at checkout and helps customers complete purchases more reliably.
Original PR description
Versions -------- - 18.0+ Feature doesn't exist in earlier versions. Steps ----- 1. Create a product with a tag; 2. create another product with a different tag; 3. create a delivery method with these 2 tags as Must Have Tags; 4. add one product to the cart in eCommerce; 5. go to checkout. Issue ----- Delivery method isn't available for selection. Cause ----- While the "Must Have Tags" description states that the method should be available if at least one product on the order has at least one of these tags, the `_match_must_have_tags` method requires *all* of the `must_have_tags` to be present in the order. Solution -------- Instead of using `all`, use `any` when matching must-have tags. opw-4836137
Customers can now reorder bundled combo products from the portal without the bundle being split into separate items. The reorder window also shows availability for the full combo, helping customers understand whether the bundled product can be fulfilled.
Original PR description
Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and…
Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and attempt to reorder the same. - Combo products are broken into separate lines rather than shown as a single combo. - Stock information for the combo is not available, as the items are treated independently. Issue: - Combo products are displayed as separate lines in reorder modal - Also stock management of combo products is not there Cause: - The `/my/orders/reorder_modal_content` controller route lacks logic to handle combo products. The reorder modal builds the cart lines assuming all items are standalone, disregarding combo grouping and related stock aggregation. Solution: - Extend the `/my/orders/reorder_modal_content` route logic to correctly identify and process combo products as single bundled entities. - Update the reorder modal in `website_sale_stock` to incorporate combo-specific stock handling, ensuring accurate availability feedback for the entire combo. - This ensures that the reorder experience mirrors the original order composition and improves stock visibility for bundled products. opw-4731014 Affected Version-18.0
This fix prevents errors when an invoice line is linked to multiple sales order lines. It uses the analytic distribution from the first linked sales line so invoice creation can continue reliably.
Original PR description
In odoo/odoo#199763, `_related_analytic_distribution()` was introduced to pass the existing analytic distribution in a sale order line to an invoice line. However, sale_line_ids is a Many2Many field, so to avoid singleton errors in the case of multiple SOLs, only the analytic distribution of the first sale order line is passed. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a crash when users group a pivot view by a custom task property and insert it into a spreadsheet. The spreadsheet now loads the needed property details so the pivot can open correctly, improving reliability for reporting workflows.
Original PR description
Steps to reproduce: - add a property on Tasks - open a pivot view - group by this property - insert in spreadsheet => boom The pivot cannot be loaded because the property is not a real field. Hence it's not loaded by `fields_get` and we are missing the property metadata (type) We need to load the definition independently and we push it to the fields. It's a hack but it seems to work. opw-4858129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where product images added through the website editor could not be adjusted later with the image editing tools. Store teams can now resize or modify those images directly in the website editor, improving product page maintenance.
Original PR description
**Steps to reproduce:** - Install eCommerce app - Go to the shop of the website - Activate the editor - Click on 'New' in the top right - Create new product with image - Image is automatically converted to 1920x1920 (unless given in webp format) - Try to edit the product image later on - The ImageTools editor options are not available **Issue:** When using the `New` -> `Product` flow of the website editor, the user can't modify the given image, and as the image tools are disabled it can't manually do it when the product is saved. **Fix:** Added necessary fields to the html element of the product image when computing `'ir.qweb.field.image'` so that it can be processed like the other images created with building blocks. To achieve this, the original image file related to the current product image needs to be fetched. opw-4561958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures combo product choices are checked for company compatibility even when existing combo items were not edited directly. It prevents users from saving product combinations that could later cause multi-company errors or inconsistent product availability.
Original PR description
to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible…
to_reproduce: --- 1. Create a combo product (no company set) 2. Create a combo choice (no company set) 3. Add a product with company restrictions 4. Multi-company error appears: "Incompatible companies on records" 5. Set company on combo choice and product template - error resolves 6. Remove company from both combo choice and combo product template 7. Save succeeds despite invalid company configuration problem: --- - During combo choice updates, only the modified combo items are included in vals['combo_item_ids'], while existing unchanged combo items are not added to the validation scope. https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L68 - The company validation logic only checks items present in the vals, missing the existing combo items that should also be validated for company consistency. https://github.com/odoo/odoo/blob/b13c686dbd6a887a251143efca1c18e7a4fb631a/addons/web/models/models.py#L1092 solution: --- - Add another check on combo items opw-4844678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
Original PR description
The account type `Caixa` (Cash) and `Depósitos à Ordem` (Demand deposits) were missing from the Portuguese localization. Changed translations in pt.po for the template_chart.py context. Steps to reproduce: - install the accountant and l10n_pt module. - select a Portuguese company. - in the Chart of Accounts, notice there is no account named `Caixa` and `Depósitos à ordem`. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4829413) opw-4829413
This fix makes work order duration calculations ignore tiny microsecond differences when recording productivity time. It prevents occasional test and rounding failures caused by insignificant timing fluctuations, improving reliability without changing business workflows.
Original PR description
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start` of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test. To fix it, we simply set the microsseconds of the end date to zero. This bug was introduced in: https://github.com/odoo/odoo/pull/80319/commits/15fef27edb3ec437d1dbec33481c5d778795bc59 Runbot failure example: https://runbot.odoo.com/odoo/runbot.build.error/226657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users with approved temporary lock date exceptions can now reset tax closing entries for covered periods without being incorrectly blocked. The change also applies the correct lock rules, including stricter hard locks and parent company lock dates, helping finance teams avoid unnecessary disruption while preserving controls.
Original PR description
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to…
Current behavior before commit: When resetting a closing entry from a tax-locked period, the system raises a lock date error, even if the user has a temporary lock date exception allowing them to bypass the restriction. Root Cause: The method only checks the company's permanent tax_lock_date, without considering temporary user-level exceptions. As a result, even if an exception is granted, the system still raises a lock error based on the permanent date. Additionally, the hard lock date (which overrides all other lock types and doesnt allow exceptions) and parent company lock date are ignored. Fix: Replaced the direct lock date check with _get_lock_date_violations(), which: - Correctly considers user-specific temporary lock date exceptions. - Returns violations based on effective lock rules (including hard lock). - Provides a more generic error message. Steps to reproduce: - Use a tax report with carryover values (e.g. Belgian VAT return, line 81). - Post a refund using a tax that maps to the carryover (e.g. 21% M). - Generate a closing entry. - Set the company’s tax_lock_date to a date covering the refund. - Grant a temporary lock date exception to the user, covering the same date. - Try to reset the closing entry → Lock date error is raised (incorrectly). opw-4715100
Manufacturing orders now list components from kit-style bills of materials in the same order defined by the business. This prevents component lists from appearing out of sequence, making production preparation clearer and less error-prone.
Original PR description
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM. Steps to reproduce: - Create a product P1…
When exploding a BoM that includes phantom (kit) components, the resulting list of components moves was not respecting the sequence order defined in the BoM.
Steps to reproduce:
- Create a product P1 with a BoM that includes:
- Component 1 (sequence = 1)
- Component 2 - KIT (sequence = 2), which itself contains:
- Component 2-1 (sequence = 1)
- Component 2-2 (sequence = 2)
- Component 3 (sequence = 3)
- Create a Manufacturing Order for P1.
Observed behavior:
- The generated stock moves are ordered as:
1. Component 1
2. Component 3
3. Component 2-1
4. Component 2-2
Expected behavior:
- The stock moves should respect the BoM line sequence:
1. Component 1
2. Component 2-1
3. Component 2-2
4. Component 3
Root cause:
- When exploding phantom BoMs, child lines were appended at the end of the processing queue, causing out-of-order moves:
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L416-L418
https://github.com/odoo/odoo/blob/d64b108db54c02098c9e95f58fa3278007c92642/addons/mrp/models/mrp_bom.py#L430
Solution:
- Insert the child BoM lines at the beginning of the processing queue (`bom_lines`), sorted by their sequence field, to ensure correct processing order.
opw-4809095Users trying to fetch a Shopee shipping label for a delivery that is not connected to a Shopee shop will now see a clear error message instead of a technical crash. This helps staff understand what is wrong and prevents confusing system tracebacks during shipping operations.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery order with one unit of P1, not linked to any sale order
- Go to the delivery order list view
- Select the created delivery order
- Click on Action → Fetch shipping label
Problem:
A traceback is triggered:
```
ValueError: ValueError('Expected singleton: shopee.shop()') while
evaluating
'records._fetch_shipment_label()'
The above server error caused the following client error:
```
The `_fetch_shipment_label` function expects at least one item, but
we don't check it via a user error, because we're supposed to call
`_sync_shopee_pickings` instead, where all these filtering and checks
are done
opw-4812360Portal users using a shared project folder link can now upload documents without being blocked by an access error. This ensures external collaborators can contribute files as intended when upload permissions are granted.
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062
The Data Cleaning module now uses a unique identifier for its model form, preventing it from being overwritten during installation. This ensures the expected configuration screen is available and avoids missing setup options for users.
Original PR description
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning…
**Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418
This fixes an issue where uploading a file to a new document request could silently fail the first time. Users can now attach documents successfully on their initial upload attempt, reducing confusion and repeated work.
Original PR description
Steps to reproduce - install documents - create a document request from "New" menu - try to upload document for that request Observation: when trying to upload for the first time, nothing is…
Steps to reproduce - install documents - create a document request from "New" menu - try to upload document for that request Observation: when trying to upload for the first time, nothing is uploaded, second time, document is uploaded successfully Issue - when uploading file, a rpc is made to `get_document_max_upload_limit` method from `loadMaxUploadSize` https://github.com/odoo/enterprise/blob/c2785a89b06e90dbc31c711c7e1e637679fcb323/documents/static/src/core/document_service.js#L18-L20 - Due to this call, the files (FileList object) from previous request (original request) are lost and there is nothing left to upload. https://github.com/odoo/enterprise/blob/c2785a89b06e90dbc31c711c7e1e637679fcb323/documents/static/src/core/document_service.js#L375-L378 - On subsequent attempts, the maxUploadSize is memoized and no further RPC is made, so the issue does not reoccur. Fix - Clone the files array before making the loadMaxUploadSize() call to preserve the original file objects. opw-4725113
Miscellaneous changes
When we are in the org chart, and click on the cap of an employee to see the manager information, if the manager of the employee is themselves, there's an traceback error. We can fix it by disabling the cap if the you are your own manager. To Reproduce on Runbot: 1. Go to an employee in Employee module. 2. Make sure the manager field has themselves as the manager 3. Click on the org chart 4. Click on the cap icon, and you'll see the error. opw-4716216 Forward-Port-Of: odoo/odoo#207483
Original PR description
When we are in the org chart, and click on the cap of an employee to see the manager information, if the manager of the employee is themselves, there's an traceback error. We can fix it by disabling the cap if the you are your own manager. To Reproduce on Runbot: 1. Go to an employee in Employee module. 2. Make sure the manager field has themselves as the manager 3. Click on the org chart 4. Click on the cap icon, and you'll see the error. opw-4716216 Forward-Port-Of: odoo/odoo#207483
Commit [1] added a compatibility layer when we switched to Bootstrap 4. That compatibility layer actually still exists in master, even though we are now using Bootstrap 5. A specific rule was forcing input-group elements on one row... which conflicts with the fact that invalid feedbacks are supposed to wrap on the next row. This commit fixes that by re-enabling the wrap, when such a feedback is displayed only. In master, the rule should probably be removed, hoping outdated layouts were update
Original PR description
Commit [1] added a compatibility layer when we switched to Bootstrap 4. That compatibility layer actually still exists in master, even though we are now using Bootstrap 5. A specific rule was forcing…
Commit [1] added a compatibility layer when we switched to Bootstrap 4. That compatibility layer actually still exists in master, even though we are now using Bootstrap 5. A specific rule was forcing input-group elements on one row... which conflicts with the fact that invalid feedbacks are supposed to wrap on the next row.
This commit fixes that by re-enabling the wrap, when such a feedback is displayed only. In master, the rule should probably be removed, hoping outdated layouts were updated to Bootstrap 4+ correctly at this point (not even sure what exactly is broken by not forcing the input-group on one row).
Steps to reproduce:
- Add a form in your website page
- Add a date field (this is an input-group)
- Make it required
- Save
- Open the HTML editor(*) and add an invalid-feedback in that field
- Save
- Send your form without filling it => the input-group is broken
(*) starting from 18.4, there is a standard use case on the /my/security
page. There might be unknown usecases between 16.0 and 18.4.
[1]: https://github.com/odoo/odoo/commit/7aa473e09944bc5c1aba2dbcd611097dd36db6c5
Related to task-3959739
Forward-Port-Of: odoo/odoo#214029This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c and flatten the background color of the body element instead. Scenario: - set a color to the body different than white - add snippets to have a height higher than the viewport - go down in the page Result: the background color is only set up to the viewport height. Cause: Before 18.0, the body takes 100% of the page height because we are scrolling over the #wrapwrap element. In 18.0 with 189a7c96e6e26825d
Original PR description
This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c and flatten the background color of the body element instead. Scenario: - set a color to the body different than white - add…
This reverts the fix of commit 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c and flatten the background color of the body element instead. Scenario: - set a color to the body different than white - add snippets to have a height higher than the viewport - go down in the page Result: the background color is only set up to the viewport height. Cause: Before 18.0, the body takes 100% of the page height because we are scrolling over the #wrapwrap element. In 18.0 with 189a7c96e6e26825dc05c0c6466576fe63aa091e, we are scrolling over the body element, that combined with the body having a height of 100% makes the body element being positionned from 0 to viewport height, and it's not present below that. Also to set background of the whole page, the browser uses the body background if there is no background on the html element, so even if the body didn't cover the whole page, we were getting the body color on the whole page. So the change in 2597d6f4c33fe2ae8a60e11059c2630ac8aff58c that set the html element to white, causes the background color to only be applied to up to the viewport height, with the background being blank below that. Fix: set the body background color to the flattened rgb color. opw-4863179 opw-4863724 Forward-Port-Of: odoo/odoo#213858
**Step to reproduce:** 1. Install `l10n_iq` and `res_partner`. 2. Create a contact with Iraq as the country and assign any state. 3. Create an invoice for that customer. **Observation:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Issue:** - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. **Solution:** - Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org
Original PR description
**Step to reproduce:** 1. Install `l10n_iq` and `res_partner`. 2. Create a contact with Iraq as the country and assign any state. 3. Create an invoice for that customer. **Observation:** - State codes appear as numbers (e.g., 01, 02, 03...) which are not ISO-compliant. **Issue:** - State codes in the CSV file were defined as simple numbers instead of proper ISO codes. **Solution:** - Updated all state codes to match the official ISO 3166-2:IQ codes. (Reference: https://www.iso.org/obp/ui/#iso:code:3166:IQ) - For Arabic names, appended `-AR` to the code (e.g., IQ-BG-AR) for Arabic-specific entries. opw-4808778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213972
### Description: Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues. ### Fix: `_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM. A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_
Original PR description
### Description: Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues. ### Fix:…
### Description: Deleting manufacturing orders (MOs) is slow due to unoptimized code. The methods `_action_cancel` and `_compute_picking_ids` are the main performance issues. ### Fix: `_compute_picking_ids`, is improved by moving its search outside the loop and grouping by `group_id`, reducing the amount of calls to the ORM. A `skip_activity` context check is added in `_action_cancel` to bypass activity generation during cancellation, aligning with the existing check done later in `_log_activity_get_documents`. Also, a bug in `_action_cancel` was calling a filtering on`self`, rather than `production`, and that for each production, which was degrading the performance. ### Benchmark: | N° of MO | Before | After | |----------|--------|-------| | 80 | 15s | 1s | | 160 | 33s | 2s | | 1000 | 2:52 | 8s | ### Reference: opw-4734710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207960
Since the edited page is within an iframe, the built-in fonts used by the wysiwyg are also loaded inside the page within the iframe, which causes them to replace the one used when viewing the page as a visitor if it happens to be one of the fallback fonts. This commit avoids that by giving a distinct `font-family` to the fonts used by the wysiwyg. task-3080104 Forward-Port-Of: odoo/odoo#213868 Forward-Port-Of: odoo/odoo#112759
Original PR description
Since the edited page is within an iframe, the built-in fonts used by the wysiwyg are also loaded inside the page within the iframe, which causes them to replace the one used when viewing the page as a visitor if it happens to be one of the fallback fonts. This commit avoids that by giving a distinct `font-family` to the fonts used by the wysiwyg. task-3080104 Forward-Port-Of: odoo/odoo#213868 Forward-Port-Of: odoo/odoo#112759
Forward-Port-Of: odoo/odoo#212936 Forward-Port-Of: odoo/odoo#208639
Original PR description
Forward-Port-Of: odoo/odoo#212936 Forward-Port-Of: odoo/odoo#208639
Follow-up of [1]. - Using `invalidate_model` without giving the related field seems to be causing issues in the master version. Let's just mention what we need only to be sure. - Check the proper update of write_date.s (note that this was already done in some forward-ported versions of [1]). - Use two distinct "new dates" so that potential cache features do not make the test pass by chance, and ease debugging of the test. [1]: https://github.com/odoo/odoo/commit/4df533196d3cfdee34beb
Original PR description
Follow-up of [1]. - Using `invalidate_model` without giving the related field seems to be causing issues in the master version. Let's just mention what we need only to be sure. - Check the proper update of write_date.s (note that this was already done in some forward-ported versions of [1]). - Use two distinct "new dates" so that potential cache features do not make the test pass by chance, and ease debugging of the test. [1]: https://github.com/odoo/odoo/commit/4df533196d3cfdee34beb2ae604f569e67cf4f93 Forward-Port-Of: odoo/odoo#213851 Forward-Port-Of: odoo/odoo#213760
Versions -------- - 17.0+ Steps ----- 1. Have a partner with a `commercial_partner_id`; 2. for the `commercial_partner_id`, create an partner of type `invoice`; 3. create & confirm a sale order invoiced to the initial partner; 4. create & confirm a sale order invoiced to the invoice partner; 5. check the `credit_to_invoice` of the partner; 6. check the `credit_to_invoice` of the `commercial_partner_id`. Issue ----- The credit to invoice is twice what it should be. Cause ----
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a partner with a `commercial_partner_id`; 2. for the `commercial_partner_id`, create an partner of type `invoice`; 3. create & confirm a sale order…
Versions -------- - 17.0+ Steps ----- 1. Have a partner with a `commercial_partner_id`; 2. for the `commercial_partner_id`, create an partner of type `invoice`; 3. create & confirm a sale order invoiced to the initial partner; 4. create & confirm a sale order invoiced to the invoice partner; 5. check the `credit_to_invoice` of the partner; 6. check the `credit_to_invoice` of the `commercial_partner_id`. Issue ----- The credit to invoice is twice what it should be. Cause ----- The `_compute_credit_to_invoice` method sums up the `credit_to_invoice` on a partner's `commercial_partner_id`. By first checking the partner's credit to invoice, it searched all sale orders credited to the commercial entity. Before it can sum these, it first has to compute the `credit_to_invoice` of the `commercial_partner_id`, which retrieves the same sale orders, and hence get summed up twice. Solution -------- Only compute the `credit_to_invoice` on commercial partners by taking the intersection of `self` & `self.commercial_partner_id`. opw-4855507 Forward-Port-Of: odoo/odoo#213849
The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens; - The user types something ("A") as input and clicks somewhere else to commit its change. - The DOM is updated with the new value. - The user types something else ("B") on the same input. - The options are rebuild with the DOM value. -> "A" is displayed in the option input and "B" is lost. This is a know issue and it has been decided to no
Original PR description
The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens;
- The user types something ("A") as input and clicks somewhere else to commit its change.
- The DOM is updated with the new value.
- The user types something else ("B") on the same input.
- The options are rebuild with the DOM value.
-> "A" is displayed in the option input and "B" is lost.
This is a know issue and it has been decided to not fix it in stable as the behavior seems really unlikely to happen with human behavior and the issue is not critical.
Although it is not optimal, the tour is fixed by adding delays before doing further steps.
runbot-64572
Forward-Port-Of: odoo/odoo#213197When User removes the currency from an invoice, A traceback will appear. Steps to reproduce the error: - Install ``l10n_es`` module and switch to ``ES Company`` - Enable Multiple currency - Create an invoice > Set customer > save - Now, Remove currency and customer from an invoice Traceback: ``` ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/l10n_es/models/account_move.py#L23 This line causes
Original PR description
When User removes the currency from an invoice, A traceback will appear. Steps to reproduce the error: - Install ``l10n_es`` module and switch to ``ES Company`` - Enable Multiple currency - Create an invoice > Set customer > save - Now, Remove currency and customer from an invoice Traceback: ``` ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/l10n_es/models/account_move.py#L23 This line causes a traceback with an empty currency when the user removes the currency from the invoice. sentry-6670501631 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213731
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The c
Original PR description
In the Datev standard export, sales with foreign currency and currency indicator are exported to the wrong column. Steps to reproduce: - With a DE Company - Open Accounting / Reporting / Audit Reports / General Ledger - Click "Datev Data (ZIP)" - Open EXTF_accounting_entries.csv According to the documentation https://apps.datev.de/help-center/documents/1003221 Chapter 3. when a journal entry is in a foreign currency: - The amount in foreign currency should go into Column B - The currency code should go into Column C - The base currency amount (i.e. the company's local currency) should be shown in Columns E and F opw-4701001 Forward-Port-Of: odoo/enterprise#87366 Forward-Port-Of: odoo/enterprise#87002
Before this commit, printing the sale detail when a tax name existed in another company with the same name led to an expected singleton error. Additionally, the absence of `identification_letter` for "No Taxes" caused errors during sorting. opw-4137917 Forward-Port-Of: odoo/enterprise#69402
Original PR description
Before this commit, printing the sale detail when a tax name existed in another company with the same name led to an expected singleton error. Additionally, the absence of `identification_letter` for "No Taxes" caused errors during sorting. opw-4137917 Forward-Port-Of: odoo/enterprise#69402
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float
Original PR description
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float before applying `int()` to convert the value to an integer. This ensures accurate rounding for exported payment amounts. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4858205) opw-4858205 Forward-Port-Of: odoo/enterprise#87597
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow
Original PR description
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow customers to select the current date Reference-https://github.com/odoo/enterprise/commit/32b5db6242a0a9cf43002e3723442be7d0cd210a opw-4844754 Forward-Port-Of: odoo/enterprise#86908