Syncing from upstream odoo/odoo (tmp.18.0) #34235

bt-admin · 2025-07-11T02:58:12Z

bt_gitbot

**Current behavior:** Can't create a workcenter from the operations (workorder) form view without having a BoM filled in (due to company check issue). **Expected behavior:** Can **Steps to reproduce:** Open `Manufacturing / Configuration / Operations` -> create new -> type in a new workcenter name -> hit create -> error **Cause of the issue:** in `mrp_routing_workcenter_form_view` we get some context for a `default_company_id`- it's not only unnecessary because `Mrp.Workcenter` will get a default company just fine via its its `resource.mixin` inheritance. The currently provided company comes from the BoM, thus the issue happens when the BoM has not yet been filled in on the view. **Fix:** Remove the context in the view. opw-4836904 closes #217950 Signed-off-by: Lancelot Semal (lase) <[email protected]>

Steps to reproduce the bug: - Unarchive the MTO route - Create a product P1: - Type: Storable - Route: MTO - Supplier: Vendor A - Create a sales order for 1 unit of P1 - Confirm the SO → A purchase order is created for Vendor A with 1 unit of P1 - Cancel the PO - Update the quantity on hand of P1 to 1 - Go to the delivery picking of the SO - Check availability Problem: The quantity on hand is not taken into account, and the picking remains in the "Waiting Availability" state. When the purchase order is cancelled, the stock move should switch to MTS instead of remaining in MTO. opw-4876611 opw-4874199 closes #214785 Signed-off-by: William Henrotin (whe) <[email protected]>

…ilters Steps to reproduce: - Install the hr_expense module. - Go to the Expense menu and click on "To Submit" in the My Expense dashboard. - Open any record from the list view. Observation: - You can't go back to the list view after opening a record. Cause: - A tag `menu` was added to the action to hide breadcrumbs, but it was removed all breadcrumb navigation, not able to go back. Solution: - Used a better way by passing `{ clearBreadcrumbs: true }` to stop the breadcrumb from changing when a filter is applied. opw-4790643 closes #217492 Signed-off-by: Olivier Colson (oco) <[email protected]>

Before this commit: header color of `Dialog` on mobile was "community color" or white, depending on the version of Odoo the database is running. This was creating issues in in the front-end, where the user of the website would see back-end specific colors in different `Dialog`s. This commit removes the color customization of `Dialog`'header as it was fitting a design line we had before we introduced MILK. task-4001365 closes #218238 X-original-commit: ffd9c0f Signed-off-by: Pierre Paridans (app) <[email protected]> Signed-off-by: Antoine Sougné (anso) <[email protected]>

Before this commit, the toggle-star and mark-as-read actions were visible on chatbot messages in a non-persisted livechat thread. Clicking these actions caused errors. This commit hides these actions when the message is in non-persisted state, preventing such errors. task-4743758 closes #218196 X-original-commit: c3ef869 Signed-off-by: Alexandre Kühn (aku) <[email protected]>

Issue: On 18.0 and 18.1, cancelling an `account.move` will clear the `ref` value in all situations if `hr_expense` is installed. While clearing the `ref` is necessary if unlinking an expense, this isn't the case for unrelated records. Solution: Check to see if the `expense_sheet_id` is set on the `account.move` to determine if the `ref` should also be removed. Additional Note: This flow was reworked in 18.2 via #189701, so we only need to adjust this for the affected versions. opw-4853903 closes #215477 Signed-off-by: Julien Alardot (jual) <[email protected]>

Before the commit, when a 'pick up in store' was published, the out-of-stock message was hidden to avoid confusion. However, customers want to benefit from it, and now we reintroduce it. opw-4791969 closes #218284 Signed-off-by: Valeriya Chuprina (vchu) <[email protected]>

We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. closes #218325 Task: 4926102 Signed-off-by: Max Whale (mawh) <[email protected]>

Versions -------- - 18.0+ Steps ----- 1. Enable debugging mode; 2. go to Settings / Technical / Database Structure / Attachments; 3. search for a PDF attachement; 4. open developer tools; 5. click on Record / Data. Issue ----- > Connection lost. Trying to reconnect... Traceback in logger: > `UnicodeDecodeError: 'utf-8' codec can't decode byte ...` Cause ----- Commit 5ef4c07 moved the `json_default` function from `date_utils` to `json`, with the purpose of letting it serialize objects besides `date` & `datetime`. When used for raw data of binary files like PDF, it encounters values that cannot be represented in UTF-8, and because `decode` defaults to strict error handling, an exception is thrown. Solution -------- When sending the `read` request to the ORM, only request fields of that aren't of type `binary` to ensure they're serializable. opw-4717657 closes #209702 Signed-off-by: Aaron Bohy (aab) <[email protected]>

Introduced by cc81bb5 **Steps to reproduce** 1. Create a new automatically validated attendance. 2. Set the employee, check in and check fields before saving the form. Issue: the "Extra hours" field is not computed. e.g.: if the employee has worked 1 hour more than expected, "Worked Extra Hours" equals 1:00 (ok), but "Extra hours" appears as 0:00. **Cause** The previous fix intended to avoid recomputation of the `validated_overtime_hours` field. No better way was found than to exclude records where the `overtime_hours` was different than the `validated_overtime_hours` (meaning it had been manually modified by the user). The problem comes from the fact that at creation, `validated_overtime_hours` was sent in the `vals_list` to the create with a value of 0. **Solution** Force the computation of the field at creation. closes #217967 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]>

Currently these problems can appear when an invoice is cash rounded. 1. In case we use the "Modify tax amount" (`biggest_tax`) cash rounding strategy: The rounding amount is added to the taxes in Odoo but not in the UBL XML - This affects everything that uses `_prepare_invoice_aggregated_taxes` (and not just UBL XML) 2. The generated UBL XML is invalid (for any rounding strategy). See below for details. 3. The import of the exported UBL XML does not yield back the same invoice (even after fixing the export / the previous 2 problems). Also there are some problems with the correction of tax values of imported UBL XML (`correct_invoice_tax_amount`). (They probably do not cause issues in practice but would after this fix. We adapt the correction as part of the fix for (3).) #### Runbot: How to generate problematic XML 1. Select BE Company CoA 2. Enable Cash Rounding in the settings 3. Create a cash rounding method (in the settings where cash rounding can be enabled): - precision `1.00` - strategy: any - profit / loss account: any 4. Create an invoice - Set a Belgian partner (e.g. "BE Company CoA" is okay) - Set the the cash rounding method from step 2 - Single Line with price=70.00€ and a 21% tax 5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non payment term items: - 70.00€ base - 14.70€ tax - 0.30€ rounding (depending on the cash rounding strategy the tax is set or not) 6. Confirm & Send (with BIS Billing 3.0) 7. Look at the UBL BIS 3 XML in the `Invoice` element - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ 8. This fails validation `BR-CO-15`: ``` Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). ``` (`LegalMonetaryTotal/TaxInclusiveAmount` = `LegalMonetaryTotal/TaxExclusiveAmount` + `TaxTotal/TaxAmount`) Since the cash rounding is included in `LegalMonetaryTotal/TaxInclusiveAmount` but not in `TaxTotal/TaxAmount` (or `LegalMonetaryTotal/TaxExclusiveAmount`) #### Tax value correction details (with examples) Currently we try to fix the tax amounts after importing an invoice. The function we use for that (`_correct_invoice_tax_amount`) has the following issues: - We look for `TaxTotal/TaxSubtotal` elements anywhere. But i.e. such elements can also exist inside `InvoiceLine` elements. Example: - module `l10n_dk_oioubl` file `test_xml_oioubl_dk.py` - function `test_oioubl_import_exemple_file_4` / XML file 'external/BASPRO_01_01_00_Invoice_v2p1.xml' - The tax total parsed from the document may need to be inverted. E.g. credit notes can be given as an invoice with negative amounts. See function `_get_import_document_amount_sign`. Example: - module `l10n_account_edi_ubl_cii` file `test_xml_ubl_be.py` - function `test_import_invoice_xml_open_peppol_examples` / XML file 'bis3_invoice_negative_amounts.xml' - We compare the tax total from the document only with a single line of that tax. But there can be multiple lines for a single tax. We have to use the sum of all those lines for the comparison. Example: - module `l10n_account_edi_ubl_cii` file `test_xml_ubl_au.py` - function `test_export_import_invoice` / XML file 'from_odoo/a_nz_out_invoice.xml' #### The fix This commit does the following to fix that 1. We include cash rounding lines belonging to a tax in the tax computation for the UBL XML export (or rather everything any tax computation done with `_prepare_invoice_aggregated_taxes`). 2. After fixing (1) we only have to fix the "Add a rounding line" (`add_invoice_line`) strategy. This is as follows - Subtract the cash rounding from the `LegalMonetaryTotal/TaxInclusiveAmount` - Add node `LegalMonetaryTotal/PayableRoundingAmount` with the value of the cash rounding 3. Cases - `add_invoice_line`: We create a dedicated invoice line with the amount found in node `LegalMonetaryTotal/PayableRoundingAmount` (if it is present). - `biggest_tax`: We update the amount on the tax line to match the value found in the XML. (Currently we only do this if the difference is not greater than '0.05') The fixes for the tax value correction on import are also needed for 3./`biggest_tax`. #### Runbot: example XML after the fix The export in the example then looks like this for the different cash rounding strategies - `add_invoice_line` - `TaxTotal/TaxAmount`: 14.70€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€ - `LegalMonetaryTotal/PayableRoundingAmount`: 0.30€ - `LegalMonetaryTotal/PayableAmount`: 85.00€ The validation for the `LegalMonetaryTotal/PayableAmount` is still okay since (in the example) it is just `LegalMonetaryTotal/TaxInclusiveAmount` + `LegalMonetaryTotal/PayableRoundingAmount`. - `biggest_tax` - `TaxTotal/TaxAmount`: 15.00€ - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€ - `TaxTotal/TaxSubtotal/TaxAmount`: 15.00€ - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€ - `LegalMonetaryTotal/TaxInclusiveAmount`: 85.00€ - `LegalMonetaryTotal/PayableRoundingAmount`: (not exported) - `LegalMonetaryTotal/PayableAmount`: 85.00€ #### References Also see - https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding - https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals task-4854592 X-original-commit: 3fe67ad Part-of: #217119 Related: odoo/enterprise#89439 Signed-off-by: Antoine Dupuis (andu) <[email protected]> Signed-off-by: Sven Führ (svfu) <[email protected]>

Currently rounding lines (with taxes) are not included in the tax lines in multiple places. This is fixed in this commit. See the previous commit for motivation. part of task-4854592 closes #217119 Related: odoo/enterprise#89439 Signed-off-by: Antoine Dupuis (andu) <[email protected]> Signed-off-by: Sven Führ (svfu) <[email protected]>

In ListView domain selection mode, a '+' is now shown (e.g., "10,000+") when the number of selected records exceeds the count_limit. This visually indicates that the selection goes beyond a certain limit Closes: #217094 Signed-off-by: Aaron Bohy (aab) <[email protected]>

Bug introduced in:dbd9ae1 Steps to reproduce the bug: - Create a kit product: - BoM: - Components: - 1 unit of C1 - 1 unit of C1 (same product) - Create a SO with one unit of kit - Confirm the SO - The delivery is created - Cancel the SO → the delivery is canceled. - Set the SO back to quotation and confirm again Problem: A traceback is triggered: raise ValueError("Expected singleton: %s" % record) ValueError: Expected singleton: mrp.bom.line(24, 25) When a kit's BoM contains the same product multiple times, multiple bom_line_ids match a given move. Assigning them causes an error. Additionally, cancelled moves were incorrectly considered. Solution: Filter out cancelled stock moves before accessing the bom_line_id to ensure only active moves are considered. And in the case where we have the same component multiple times, we have no choice but to link all the moves to the first bom_line, because the moves are processed separately, so we can't loop over them. opw-4919875 closes #218187 Signed-off-by: William Henrotin (whe) <[email protected]>

**Issue** The auto check out cron was using the check in time in UTC to determine the excepted working hours and the previous attendances. For example: - have an employee with a working schedule using a UTC+8 timezone. - check-in on a monday before 8am (0:00 UTC) in the employee's tz. - the auto check-out cron closes the attendance immediately because there are no working hours for the attendance's check in day in UTC (Sunday). **Change** Use the date of the check-in localized in the tz of the calendar used by the attendance's employee to determine the previous worked hours for that day and the expected worked hours. opw-4654847 closes #212594 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]>

Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 closes #218375 X-original-commit: e07ff7f Related: odoo/enterprise#89962 Signed-off-by: Max Whale (mawh) <[email protected]>

… leaves After PR 209570 , the way work intervals are computed might not reflect real working time for flexible employees, since the virtual schedule is based on a weekly span. In this PR we chose to allocate a timesheet for single day leaves corresponding to average hours per day to be consistent with hr_holidays calculation. closes #218353 Signed-off-by: Jurgen Gjini (jugj) <[email protected]>

This commit will add the amount residual in text in the note of the xml we sent to nilvera. The text need to be in uppercase. If the invoice is in another currency than Turkish Lira, we have to add two notes one for the amount in turkish lira and one in the other currency Also when the integer part or fractional part is zero it should be zero in turkish. task-4518269 closes #217910 X-original-commit: a521586 Signed-off-by: Florian Gilbert (flg) <[email protected]> Signed-off-by: Maximilien La Barre (malb) <[email protected]>

Before this commit, an error would occur when opening the product configuration popup if two pricelists shared the same name. This was due to the pricelist name being used as a key, which must be unique. This commit resolves the issue by switching to the pricelist ID as the key, ensuring uniqueness and preventing errors when duplicate pricelist names exist. opw-4882900 closes #217901 Signed-off-by: Stéphane Vanmeerhaeghe (stva) <[email protected]>

The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. - Behavior prior to this PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. And all the tax columns are based in the base not in the tax part. - Behavior after this PR. Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly, Tax columns only contains tax values, not base values. opw-4920577 "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" closes #218341 X-original-commit: 1180c80 Related: odoo/enterprise#89946 Signed-off-by: Antoine Dupuis (andu) <[email protected]>

Steps to reproduce: 1. Install l10n_in_hr_holidays and l10n_in 2. Switch to IN company 3. Create an employee related to Marc Demo in IN Company 4. Log in with Marc Demo and create a timeoff 5. Approve the timeoff by Mitchel admin 6. Open the form view of approved timeoff by Marc Demo Issue: The _get_durations method in l10n_in_hr_holidays attempts to update the l10n_in_contains_sandwich_leaves field whenever it runs, including when opening the form view of an approved time off. This causes an access error, as updates are not allowed for Marc demo in the approved state. Solution: Added a state check in the _get_durations method to prevent updating the field for approved records. opw-4741162 closes #209233 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]>

ethanrobv and others added 22 commits July 10, 2025 06:42

[I18N] *: fetch 18.0 translations

52d8779

[FIX] hw_drivers: don't update certificate if empty

cfd47c4

We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. closes #218325 Task: 4926102 Signed-off-by: Max Whale (mawh) <[email protected]>

bt-admin added the tmp.18.0 label Jul 11, 2025

bt-admin merged commit 6b44116 into brain-tec:tmp.18.0 Jul 11, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Syncing from upstream odoo/odoo (tmp.18.0) #34235

Syncing from upstream odoo/odoo (tmp.18.0) #34235

Uh oh!

bt-admin commented Jul 11, 2025

Uh oh!

Uh oh!

Syncing from upstream odoo/odoo (tmp.18.0) #34235

Syncing from upstream odoo/odoo (tmp.18.0) #34235

Uh oh!

Conversation

bt-admin commented Jul 11, 2025

Uh oh!

Uh oh!