Syncing from upstream odoo/odoo (tmp.saas-18.3) #34193

bt-admin · 2025-07-09T03:46:12Z

bt_gitbot

When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 closes #216953 X-original-commit: 1540c30 Signed-off-by: Ryan Cen (ryce) <[email protected]>

…rt layout Steps to Reproduce: 1. Go to Settings > Companies > Configure Document Layout. 2. Choose layout Boxed or any layout that horizontally places the company logo and address. 3. Edit the address block choose long string. 4. Save the layout and click Preview Document or print SO or invoice. Issue: Observe in PDF output the long text overlaps into logo or extend outside the layout bound(differ in layouts) — even though enough space is visually available Cause: A previous change in PR #201198 added the text-nowrap class to address blocks to fix a minor wrapping issue. However, this unintentionally caused layout overflow issues with long lines. Solution: - Added width to the address block to ensure balanced layout structure. - Removed text-nowrap from all layouts, as the original issue is now resolved by applying proper width sizing. - Removed float-end from Boxed layout, as it was contributing to misalignment. Additional Notes: All behaviors addressed by PR #201198 were re-tested to ensure this fix does not reintroduce previous issues. opw-4764975 closes #217835 X-original-commit: 0a45a1e Signed-off-by: Bastien Fafchamps (bafa) <[email protected]> Signed-off-by: Khushi Srivastava (khsr) <[email protected]>

Introduced in #213177. A simple typo meant the `update_conf` method was being called with a set instead of a dict, leading to an error being thrown and preventing the git checkout. This commit fixes the typo. closes #217838 X-original-commit: 6948c19 Signed-off-by: Louis Travaux (lotr) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>

Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 closes #217803 X-original-commit: fb78c5a Related: odoo/enterprise#89688 Signed-off-by: Louis Travaux (lotr) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>

Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546 closes #216643 Related: odoo/enterprise#88998 Signed-off-by: Rémy Voet (ryv) <[email protected]>

Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom > The copied by product line refer to the operation of the original bom > this can be checked by archiving the copied operation which should > erase its link with the copied by product line but will not Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 closes #217836 X-original-commit: 75668dd Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>

Change label of `non_deductible_account_id` field on `account.journal` from `Private Part Account` to `Private Share Account` as private part means something else in english. task-4868244 closes #217810 X-original-commit: f665307 Signed-off-by: William André (wan) <[email protected]> Signed-off-by: Pratham Nareshbhai Patel (ppat) <[email protected]>

**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 closes #217471 X-original-commit: 1abbce3 Signed-off-by: Adrien Guilliams (adgu) <[email protected]> Signed-off-by: Arthur Nanson (artn) <[email protected]>

closes #217762 X-original-commit: 027d07d Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>

Purpose of this commit: - Backport a part of commit [1] which ensures that the `Translate with AI` button now changes its color appropriately in dark mode. [1]-48c7cd1 task-4897771 closes #215850 Signed-off-by: David Monjoie (dmo) <[email protected]>

**Steps to reproduce:** - Install Accounting + Inventory + Sales apps - Enable Automatic Accounting in Settings - Ensure two companies are available - Set one product category (same for both companies) - For company 1 (current) -> FIFO + automatic valuation (`'real_time'`) - For company 2 -> FIFO + manual valuation (`'manual_periodic'`) - Create a storable product for this category - From company 1: - Buy 10 products at 10$ each and receive them (Purchase + Delivery) - Sell 15 products at 10$ each and deliver them (Sale + Delivery) - Buy 10 products at 10$ (Purchase) - Switch to company 2 (keep company 1 checked) - From company 2: - Validate the third delivery order (WH/IN) - Go to Inventory/Reporting/Valuation - One journal entry is missing for the last move **Issue:** During the processing of the SVL in `_run_fifo_vacuum`, the product used its current env context company instead of the one provided explicitly in the parameters. This caused inconsistencies in valuation logic when the method used differed between the given companies, which results in a missing `account_move_id`. **Fix:** Ensure that the product is evaluated in the correct company context by using `self.with_company(company.id)` when looping on the products before the valuation logic. opw-4732067 closes #217045 X-original-commit: 6731163 Signed-off-by: Steve Van Essche <[email protected]> Signed-off-by: Florentin Delcourt (defl) <[email protected]>

When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it doesn’t consider the live chat rules. Since [1], we do not wait for the live chat service to be initialized, so the initial value is used instead of the corrected one. These rules depend on the URL. Since `get_livechat_info` is called from the website template, we can’t determine which rule applies at that point. The goal is mainly to avoid calling `init_livechat` ("/mail/data") if we already know the live chat won’t be available. However, this check alone isn’t enough to decide whether to show the chat button. This commit renames `isAvailable` to `can_load_livechat` for clarity. If `can_load_livechat` is set, we can load the live chat and call `init_livechat`, which will then set the `livechat_available` value. task-4908197 [1]: #194399 closes #217695 Backport-of: #216595 Signed-off-by: Didier Debondt (did) <[email protected]>

In order to satisfy certification requirements from the LNE, we implement the following: - A product is weighed at e.g. 200g and added to the order - Another product is weighed. The weight must change from 200g before the user is allowed to add the item. - This should also happen even if another non-weighed product is added in-between. task-4859589 closes #215084 X-original-commit: 0beac29 Related: odoo/enterprise#88089 Signed-off-by: Yaroslav Soroko (yaso) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>

In 0f3a9de we added helpers to create test taxes in `AccountTestInvoicingCommon`, not realizing that they were already in `TestTaxCommon`. This commit removes them from `TestTaxCommon` to avoid the duplication. task-none closes #217867 X-original-commit: aae91c9 Signed-off-by: Laurent Smet (las) <[email protected]> Signed-off-by: Antoine Dupuis (andu) <[email protected]>

The test in this module imports a common setup from account_reports which is not a dependency, and is not auto installed when the test runs with comunity modules only. This fix replaces the setup by the community one AccountTestInvoicingCommon. closes #217802 X-original-commit: 591acd3 Signed-off-by: Jinane Maksoud (maji) <[email protected]>

Before, the previous document chaining was not sent in the XML because with the t-if, if the variable name is unknown, it will not complain and just see it as False. (like for the first invoice that has no previous) Now, passing the correct variable name, the previous document will be included opw-4814241 closes #217845 X-original-commit: 4aa87ad Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>

Steps to reproduce =============== 1. Create a company called Acme. 2. Create a child contact of type Invoicing address but do not give it any name. 3. Go to Sales. 4. Open the dropdown to select customer ---> Recipient without name will show False after the parent name From [Commit 1], formatted display name was added. After this commit, add a fallback as customer's type to the name. [Commit 1]: 4f59494 Task-4812554 closes #211865 Signed-off-by: Warnon Aurélien (awa) <[email protected]>

…of int The system will crash when we get the `category` as `str` and we try to evaluate `int(category)` in `_validate_and_get_category` method. Root Cause:- - At [1] and [2], we are passing an object in the arguments for the category. If we manually provide a category, it may result in a 'not found' error instead of a regular error. - However, at point [3], Since the category is received from a query parameter, it can be easily tampered with, so it should be properly validated before use. - This controller makes the older controller (used before V14) compatible with the new one. [1] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L470 [2] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L247 [3] https://github.com/odoo/odoo/blob/1df0feb3dc1b0ac34227683337eca4d95fa986b5/addons/website_sale/controllers/main.py#L546 Error:- `ValueError: invalid literal for int() with base 10: 'duffle-bags'` Solution:- - We added a validation to ensure the category parameter is a valid integer before using it. - This prevents crashes when users manually input invalid or tampered category values in the URL. Sentry - 6658317828 closes #216791 Signed-off-by: Louis Tinel (loti) <[email protected]>

…ed from sale In Hungary the rate of the currency of an invoice is based on the delivery date. When creating an invoice from Sale, the `currency_rate` of the lines is the one of the invoice date not of the delivery. Steps to reproduce: - Install l10n_hu_edi and witch to Hungarian company - Have two different rates for EUR<->HUF - Create a pricelist in EUR - Create a quotation with the pricelist and confirm - Validate the delivery on another date (which has a different rate from today) - In the sale order click "Create Invoice" - The generated invoice has lines using the rate for today Cause: The field `delivery_date` is `precompute=True` but on creation of the invoice, at the time of the precompute, `line_ids` is still `False`. So the invoice is first computed without the delivery date, the currency rate used is the one of the invoice date. When the delivery date is written on the invoice, the line balance is not recomputed as the field `balance` is marked as `protected`. Solution: As the field `delivery_date` was implemented in `account_move` for localizations including l10n_hu, there are no reason to contain the fix only to l10n_hu. So we add the value of `delivery_date` in the dictionnary used to create a new invoice from sale with the method `_create_invoices`. This way the delivery date is there on creation of the invoice and is used for the currency rate. opw-4756568 closes #217893 X-original-commit: 459803b Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Mathieu Coutant (mcou) <[email protected]>

When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 closes #217506 X-original-commit: 63c7355 Related: odoo/enterprise#89521 Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Robin Engels (roen) <[email protected]>

Scenario: - edit navigation bar to "Rounded box menu" (header_boxed_opt) - select option "Sub Menus" to "On Hover" - add a mega menu - outside of editor, hover the mega menu item and move mouse over it Result: the mega menu content closes before we get to it. History: In saas-18.1 and saas-18.2, these menus with the show on hover have been broken and fixed through different changes: (A) normal popup menu (B) all mega menu (C) mega menu with header_boxed_opt menu bar Here is the list of commit and what was broken after them: - 6715158 (nov 2024): C - b9b3a60 (jan 2025): A+C - ddf0712 (apr 2025): B+C - e65d4cf (apr 2025): C And hopefully this commit will fix C that happen since in 6715158 where we added a !important margin-top to the mega menu in case of header_boxed_opt header that is causing issue C. We do not the the change for a menu inside .o_mega_menu_is_offcanvas because in this case "header_sidebar_opt" doesn't need the fix and needs to have a margin-top because: - it is in the margin-top space that the go back button is - the height is computed taking into account the margin-top, so if we removed it the height of the megamenu+margin-top would not be 100% and there would be a gap at the bottom opw-4876149 closes #217809 X-original-commit: 44560db Signed-off-by: Quentin Smetz (qsm) <[email protected]> Signed-off-by: Nicolas Lempereur (nle) <[email protected]>

bug introduced in: ea48070 Steps to reproduce the bug: - Go to "Inventory" → "Operations" menu → "Replenishment" - Click "New" to create a new replenishment rule Problem: Traceback is triggered: ``` in _float_check_precision assert precision_rounding > 0,\ ^^^^^^^^^^^^^^^^^^^^^^ AssertionError: precision_rounding must be positive, got 0.0 ``` As the product is not set, the `product_uom` is not set either, which leads to a `product_uom.rounding` of 0.0. Opw-4925719 Opw-4928957 Opw-4926504 Opw-4925919 Opw-4928684 Opw-4925080 Opw-4928788 Opw-4926719 Opw-4927440 opw-4928540 closes #217961 X-original-commit: 6218559 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Djamel Touati (otd) <[email protected]>

Scenario: - go to the /contactus page - edit the subject field and set a default value then save Result: the default value is not saved. Reason: in 13.0, field default value had priority over data-for so an issue was solved by b637a5e that if you saved a form, the data-for would become the default for all the uses of that form (so eg. a job position would be set for all job positions). In 8d0a63f the priority was changed so data-for has higher priority than the default value, that made the prior fix unnecessary (just a nice to have, to not save the data-for as default that would be overridden by another data-for). The fix was reintroduced by ca433f3 but it removes default value if there is a data-for. Fix: remove the filling and removing of data-for value in edition: the data-for is not shown in the editor (allowing us to set default) but has the priority when rendering the field in non-editable mode. This is mirroring what is already done for data-fill-with. The added test steps, verify that the default value that is overridden by a data-for is kept for type/email/text shown inputs. Side note: this commit also remove useless data-fill-with="undefined" attributes that are added when editing field. They shouldn't cause any issue unless someone add a "undefined" field in the prefilled fields. opw-4794903 closes #217437 X-original-commit: 9ad836b Signed-off-by: Outagant Mehdi (mou) <[email protected]> Signed-off-by: Nicolas Lempereur (nle) <[email protected]>

Before this commit: When calculating the `price_unit` for stock moves from purchase order lines, the `remaining_qty` and `remaining_value` could be imprecise. Standard float comparisons for these remaining amounts could lead to incorrect `price_unit` calculations if, for example, `remaining_qty` was a very small float near zero. This could result in inaccurate stock valuations, particularly when currency conversions were involved or when landed costs were applied. For example, 70.00000003 is rounded **up** to 70.00001 (with 5 digits), resulting in a quantity difference of 0.00001, which incorrectly inflates the unit cost. After this commit: Change the rounding method to 'HALF-UP' instead of the default 'UP' to improve precise result for quantities. Steps to reproduce: 1. Configure a product with AVCO real time. Set decimal precision for price and UoM to 5 digits. 2. Create a Purchase Order (e.g., 190 units @ $110/unit). 3. Receive 70 units and create a backorder 4. Create and post a bill for the initially received quantity. 5. Apply a landed cost to the picking of the first 70 units. 6. Create a draft bill for the remaining quantity on the PO. 7. Receive the remaining 120 units from the backorder. 8. The product's cost explodes opw-4705224 closes #217997 X-original-commit: 60a5ba0 Signed-off-by: Tiffany Chang (tic) <[email protected]> Signed-off-by: Walravens Mathieu (wama) <[email protected]>

ryce-odoo and others added 24 commits July 8, 2025 01:47

[IMP] l10n_es_edi_sii: aeat cert renewal

26d5c37

closes #217762 X-original-commit: 027d07d Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>

bt-admin added the tmp.saas-18.3 label Jul 9, 2025

bt-admin merged commit f1e1575 into brain-tec:tmp.saas-18.3 Jul 9, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Syncing from upstream odoo/odoo (tmp.saas-18.3) #34193

Syncing from upstream odoo/odoo (tmp.saas-18.3) #34193

Uh oh!

bt-admin commented Jul 9, 2025

Uh oh!

Uh oh!

Syncing from upstream odoo/odoo (tmp.saas-18.3) #34193

Syncing from upstream odoo/odoo (tmp.saas-18.3) #34193

Uh oh!

Conversation

bt-admin commented Jul 9, 2025

Uh oh!

Uh oh!