Tuesday, March 14, 2023
65 changes · master
New functionality added to Odoo
Singapore companies can now use the SG BIS Billing 3.0 electronic invoicing format. This expands local compliance support and makes it easier to exchange invoices using Singapore's expected business document standard.
Original PR description
Add a new edi_format "SG BIS Billing 3.0" available for SG companies. This format is based on BIS Billing 3.0. task-3180983
Enhancements to existing features
Manufacturing orders and work orders now use the same date fields for planned and actual timing once work starts or finishes. This reduces duplicate date information and helps teams see production timing more clearly across manufacturing, inventory, and subcontracting flows.
Original PR description
Since starting a workorder and marking it as done replace scheduled dates with effective ones... task: 3108291 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The German SKR03 accounting template now classifies account 1380 correctly in the balance sheet. This helps German companies rely on more accurate financial reporting and chart of accounts setup.
Original PR description
By checking the script checking if all the account supposed to be in the BS are. The account 1380 seems to be miss configured task-id: 3041738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The Egyptian e-invoicing module has been updated to use Odoo's newer action framework for certificate retrieval and invoice signing. This keeps the feature aligned with the platform architecture and should help maintain reliability without changing the business workflow.
Original PR description
The purpose of this commit is to convert the client actions 'action_get_drive_certificate' and 'action_post_sign_invoice' to the new architecture. TaskID: 3164406 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps: - Open studio - Go to 'Reports' tab - Select 'Pricelist' report - Error message opw-3207593 Forward-Port-Of: odoo/odoo#115024
Original PR description
Steps: - Open studio - Go to 'Reports' tab - Select 'Pricelist' report - Error message opw-3207593 Forward-Port-Of: odoo/odoo#115024
Expense reports now prevent users from adding expense lines with incompatible payment modes, avoiding save-time errors later in the workflow. The expense module dependency setup was also corrected so it installs reliably after a related dependency change.
Original PR description
You cannot validate and expense report having expense_line_ids of different payment mode. But so far, it was possible to select these lines, and it would be blocked upon saving. We will improve this behavior by adding a domain on the expense_line_ids field and disallowing to add lines that would lead to an error later in the process. task id # 3221780 Also fix an issue with the dependencies of hr_expense since the removal of the one with hr_contract --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Stacked bar charts can now display an overlaid line showing the combined total across groups. This helps business users quickly understand net totals, such as invoices minus credit notes, especially when positive and negative values are mixed.
Original PR description
When stacking a bar chart, you often want to see the resulting sum of the different groups (esp. if there are negative values). For example, when displaying a stacked chart of invoices vs credit notes, you usually also want to know the net total. This is done only on stacked bar charts that have single column per x-axis label and with more than one level of groupby. TASK-ID: 3193260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SQL queries shown in logs and tests are now formatted across multiple lines, making them easier to read and troubleshoot. This is an optional developer-facing improvement that helps speed up debugging without changing normal business workflows.
Original PR description
sqlparse is a python library that can be used to pretty-format SQL
queries. We use it to pretty-print queries for `--log-sql` and in
tests for `AssertQueries`. The library is optional and will emit a
warning upon being used but not installed (as a way to advertize its
existence to our fellow developers).
It can be installed via apt `python3-sqlparse` or via pip `sqlparse`.
As an example, the following query logged on a single line:
SELECT "ir_module_module"."id" FROM "ir_module_module" WHERE ("ir_module_module"."state" = 'installed') ORDER BY "ir_module_module"."name"
becomes:
SELECT "ir_module_module"."id"
FROM "ir_module_module"
WHERE ("ir_module_module"."state" = 'installed')
ORDER BY "ir_module_module"."name"The web autocomplete component now supports focusing its input automatically and adding a custom style class to its container. This gives Odoo screens more flexibility to create smoother, more polished user interactions without changing core behavior.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes internal test data for Odoo's messaging-related features more consistent ahead of future Discuss improvements. It also adjusts an attachment test so it can run reliably on larger screens, helping reduce maintenance risk without changing day-to-day user behavior.
Original PR description
In preparation of discuss refactoring. Extracted from https://github.com/odoo/odoo/pull/110188 to ease its diff a little.
The CRM lead scoring settings modal now makes the date field visibly underlined so users can more easily recognize it as editable. The confirmation button is also renamed to “Update,” making the action clearer before applying changes.
Original PR description
Make the date field always underlined in the PLS modal in the settings, to indicate that it is editable and not a technical constraint. Task-3193113
This update removes extra spaces before punctuation marks such as colons, semicolons, question marks, and exclamation marks across several Odoo areas. It improves the professionalism and consistency of English-language text shown in the product, demos, and related messages.
Original PR description
According to Wiktionary, *French spacing* is "the archaic practice (though still current in French) of inserting a space around colons, semicolons, question marks, and exclamation marks". This is not standard practice in English and most languages of the world. The purpose of this commit is to start purging the code from this typo, as it may reflect poorly on the software for some people. Enterprise: https://github.com/odoo/enterprise/pull/37853
This update lets Odoo screens show dropdown controls in a disabled state when an action should not be available. It helps create clearer interfaces and prevents users from trying unavailable options.
Original PR description
With this commit, we can now customize the Dropdown component to make it disabled. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unnecessary spaces before punctuation such as colons, semicolons, question marks, and exclamation marks across many Odoo Enterprise apps. The change improves the polish and professionalism of English text shown in the product without altering business workflows.
Original PR description
According to Wiktionary, *French spacing* is "the archaic practice (though still current in French) of inserting a space around colons, semicolons, question marks, and exclamation marks". This is not…
According to Wiktionary, *French spacing* is "the archaic practice (though still current in French) of inserting a space around colons, semicolons, question marks, and exclamation marks". This is not standard practice in English and most languages of the world. The purpose of this commit is to start purging the code from this typo, as it may reflect poorly on the software for some people. Community: https://github.com/odoo/odoo/pull/114533 \* = account_asset, account_auto_transfer, account_bank_statement_import, account_consolidation, account_sepa_direct_debit, appointment, documents_l10n_be_hr_payroll, event_barcode, event_social, helpdesk, hr_appraisal, hr_appraisal_survey, hr_contract_salary, hr_payroll, hr_payroll_account, hr_referral, industry_fsm, iot, knowledge, l10n_be_hr_payroll, l10n_be_reports, l10n_de_pos_cert, l10n_es_reports, l10n_ke_hr_payroll, l10n_ma_hr_payroll, l10n_mx_edi_website_sale, marketing_automation, mrp_mps, mrp_plm, mrp_workorder, mrp_workorder_hr, pos_hr_mobile, sale_planning, sale_purchase_inter_company_rules, sale_renting, sale_stock_renting, sale_subscription, sign, social, spreadsheet_edition, stock_barcode, stock_barcode_picking_batch, timesheet_grid, voip, web_gantt, web_studio
Document extraction now stores document identifiers in a simpler text format and consolidates duplicated service endpoints. This improves maintainability and helps invoice, expense, and recruitment document processing stay consistent across the system.
Original PR description
Upgrade PR: odoo/upgrade#4417
Manufacturing orders and work orders now use one set of dates that updates from planned to actual progress as work starts and finishes. This reduces duplicate date fields and helps reports and planning views show the most relevant timing information consistently.
Original PR description
Since starting a workorder and marking it as done replace scheduled dates with effective ones... task: 3108291
The AvaTax settings page now includes a checkbox to control whether related options are shown. This makes the configuration screen clearer without affecting whether the AvaTax module is installed.
Original PR description
Before this PR, the avatax setting was missing a checkbox on the left, the goal of the checkbox is not to uninstall the module but will be use only for the display or not of the options below. task-id: 3226604
The Expense app was missing a required link to another component, which prevented businesses from installing it by itself. This fix adds the missing requirement so the app can be installed independently as expected.
Original PR description
Before this commit, it was not possible to install hr_expense alone. This commit enable the installation of standalone hr_expense by adding missing dependency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal web test helper that could get stuck when a component was removed after an error. The change makes automated tests more reliable, helping developers catch issues without affecting regular users.
Original PR description
The `afternextrender` helper is meant to be used in some tests that want to do something after owl has completed all its work following a specific action. It is useful when the action may cause some…
The `afternextrender` helper is meant to be used in some tests that want to do something after owl has completed all its work following a specific action. It is useful when the action may cause some additional renders, so waiting for one nextTick is not enough. Unfortunately, it has a bug: it waits for Owl scheduler to be empty. But in some cases, when a component is destroyed because of an error, the scheduler task list will not be cleared until the next render completes. It is implemented that way in Owl to reduce the amount of work it does. But this means that in some testing scenarios, the afterNextRender promise will simply not be resolved, since there is no upcoming render to clear the tasklist. With this commit, we just avoid the issue by ignoring the fibers coming from destroyed component. Note that I think that it is not a good semantic for tests, as it is a little bit too "black-boxy". Ideally, we should rather wait for something in the DOM. There is a waitUntil helper somewhere that may be useful for this situation Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mongolian balance sheet report has been updated to include accounts that were previously missing. This helps ensure the balance sheet balances correctly and provides more reliable financial reporting for Mongolian localization users.
Original PR description
When checking if the BS is balanced with a script, it seems that some accounts were missing from the BS. This PR correct that task-id: 3041738
The Italian financial reports now include accounts that were previously missing from the balance sheet report definitions. This helps companies using the Italian localization produce more complete and accurate balance sheet reporting.
Original PR description
By checking the script checking if all the account supposed to be in the BS are. Seems some account were present in the COA but not in the Balance sheet, this PR corrects that. task-id: 3041738
The Lithuanian balance sheet report has been adjusted so that all relevant accounts are included and amounts use the correct signs. This helps businesses get a balanced and more reliable financial statement for Lithuanian reporting.
Original PR description
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738
The Finnish balance sheet report has been adjusted so that missing accounts are included and reversed signs are corrected. This helps businesses produce more accurate balanced financial statements for Finnish reporting requirements.
Original PR description
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738
The Norwegian balance sheet report has been updated so all relevant accounts are included and signs are applied correctly. This helps ensure the balance sheet balances properly and provides more reliable statutory reporting.
Original PR description
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738
The Belgian balance sheet report now includes account 497, which was already part of the Belgian chart of accounts but missing from the report structure. This corrects an imbalance so Belgian financial statements present totals accurately.
Original PR description
Before this PR the belgian BS wasn't balanced since an account was missing in the BS (the account 497 was present in the COA but not in the BS). By adding the account the balance sheet is now correctly balanced. Task-id: 3041738
The German reporting setup now includes accounts that were previously present in the chart of accounts but missing from the balance sheet report. This helps ensure balance sheet reporting is more complete and accurate for German accounting users.
Original PR description
By checking the script checking if all the account supposed to be in the BS are. Seems some account were present in the COA but not in the Balance sheet, this PR corrects that. task-id: 3041738
eCommerce can now offer fixed-cost delivery methods without requiring the Inventory app, making basic shipping setup available in lighter SaaS configurations. Delivery features were reorganized so inventory-specific behavior lives separately, while website sales include the needed shipping setup directly.
Original PR description
It's currently impossible to set fixed delivery costs in eCommerce without installing Inventory. This is a problem for one-app free instances on our SaaS, which would need to pay for a feature that…
It's currently impossible to set fixed delivery costs in eCommerce without installing Inventory. This is a problem for one-app free instances on our SaaS, which would need to pay for a feature that should be part of the basic eCommerce features bundle. Delivery is now split from inventory/stock module to allow for a soft free integration into website_sale. This PR makes it possible to define fixed-cost delivery methods in eCommerce without installing Inventory by adding a direct dependency of `website_sale` on `delivery`. The bridge between those two modules is therefore included in the former. Steps are: - extract the Inventory logic from the `delivery` module into a new `stock_delivery` module; - move `website_sale_delivery` into `website_sale`; - adapt dependencies to `delivery` and `website_sale_delivery`; - remove bridge module with loyalty directly in `website_sale_loyalty`; - move `website_sale_delivery_mondialrelay` to `website_sale_mondialrelay`. task-3074497 task-3203210 See also: - https://github.com/odoo/enterprise/pull/36609 - https://github.com/odoo/upgrade/pull/4362
Odoo reorganized shipping-related code so inventory-specific logic is separated from delivery and online sales integrations depend on the right modules directly. This should simplify future maintenance while keeping shipping carriers, marketplace sales, and tax cloud website flows aligned after module renames and merges.
Original PR description
The split of delivery from inventory stock lead to several changes: - dependencies moving from `delivery` to `stock_delivery` - dependencies moving from `website_sale_delivery` to `website_sale` - rename of module `website_delivery_fedex` to `website_sale_fedex` - rename of module `website_delivery_ups` to `website_sale_ups` - merge module `website_sale_delivery_taxcloud` into `website_sale_account_taxcloud` task-3074497 task-3203210 See also: - https://github.com/odoo/odoo/pull/110686 - https://github.com/odoo/upgrade/pull/4362
Reproduction steps: -Install payroll app - Got to payroll > Contracts > Contracts > List view - Select multiple record and modify the Working Schedule missing return in write Forward-Port-Of: odoo/odoo#115028
Original PR description
Reproduction steps: -Install payroll app - Got to payroll > Contracts > Contracts > List view - Select multiple record and modify the Working Schedule missing return in write Forward-Port-Of: odoo/odoo#115028
1. Install DIN 5008 2.1. Settings - [Companies] > [Document Layout] > Configure (..) - Set [Layout] to DIN 5008 and paper format to one with DIN 5008 - write on [Company Tagline] - [Download PDF Preview] 2.2. Accounting - Customer Invoices - click an invoice and [PREVIEW] Before: Slogan not added After: Added on the top right corner as it should https://github.com/odoo/odoo/blob/saas-15.2/odoo/addons/base/models/res_company.py#L64 versions: up to master opw-3145751 Forward-
Original PR description
1. Install DIN 5008 2.1. Settings - [Companies] > [Document Layout] > Configure (..) - Set [Layout] to DIN 5008 and paper format to one with DIN 5008 - write on [Company Tagline] - [Download PDF Preview] 2.2. Accounting - Customer Invoices - click an invoice and [PREVIEW] Before: Slogan not added After: Added on the top right corner as it should https://github.com/odoo/odoo/blob/saas-15.2/odoo/addons/base/models/res_company.py#L64 versions: up to master opw-3145751 Forward-Port-Of: odoo/odoo#115069 Forward-Port-Of: odoo/odoo#114332
before this commit, enabling the mass editing for the various tree view using the studio throws exception saying field used in domain is missing in the view * install studio, hr, hr_holidays * open department tree * enable mass editing for the tree using studio app * exception will be raised similarly for the hr.job, hr.plan, hr.work.location and hr.leave tree views. after this commit, on enabling mass editing on this tree view, exception will not be shown. --- I confirm I ha
Original PR description
before this commit, enabling the mass editing for the various tree view using the studio throws exception saying field used in domain is missing in the view * install studio, hr, hr_holidays * open department tree * enable mass editing for the tree using studio app * exception will be raised similarly for the hr.job, hr.plan, hr.work.location and hr.leave tree views. after this commit, on enabling mass editing on this tree view, exception will not be shown. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114889
Chrome 111 enabled checking of websocket origin: if the WS connection sends an Origin head which is not whitelisted with the new `--remote-allow-origins` switch it is rejected. Turns out websocket-client (amongst others) *does* send an `Origin`, which trips the check, and means tours immediately break when trying to run them as Odoo's test harness is unable to connect to (and control) the devtools. Suppress sending `Origin` to fix the issue. Note: this also prevents using the remote dev
Original PR description
Chrome 111 enabled checking of websocket origin: if the WS connection sends an Origin head which is not whitelisted with the new `--remote-allow-origins` switch it is rejected. Turns out websocket-client (amongst others) *does* send an `Origin`, which trips the check, and means tours immediately break when trying to run them as Odoo's test harness is unable to connect to (and control) the devtools. Suppress sending `Origin` to fix the issue. Note: this also prevents using the remote developer tools by opening the devtools URL, user needs to go through chrome://inspect from the client and find / select the headless browser from there. Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39 Chrome tracker issue: https://crbug.com/1422444 Forward-Port-Of: odoo/odoo#115027 Forward-Port-Of: odoo/odoo#114930
The test added in dea66e1df317ca8782a68ece6c1e5917f6e8f3ec depends on a `mail` helper, even though it is in the `web` module. opw-3133731 Forward-Port-Of: odoo/odoo#115043
Original PR description
The test added in dea66e1df317ca8782a68ece6c1e5917f6e8f3ec depends on a `mail` helper, even though it is in the `web` module. opw-3133731 Forward-Port-Of: odoo/odoo#115043
To reproduce ============ - on Time off, create a time off with a big description - approve this time off the form breaks Problem ======= the style of text overflow is not handled Solution ======== add `text-break` class to the input part opw-3118856 Forward-Port-Of: odoo/odoo#114442
Original PR description
To reproduce ============ - on Time off, create a time off with a big description - approve this time off the form breaks Problem ======= the style of text overflow is not handled Solution ======== add `text-break` class to the input part opw-3118856 Forward-Port-Of: odoo/odoo#114442
Current behavior: When you make a purchase that should be rounded down, for example 1.97 rounded down to 1.95. On the payment screen if you select a payment method and pay with a greater amount than the base amount. The total due would be rounded incorrectly to 2.00 instead of 1.95. Steps to reproduce: - Create a product with a price of 1.97 - Set a rouding down method of 0.05 - Open a pos session - Add the product to the order - Select a payment method, for example cash and enter an am
Original PR description
Current behavior: When you make a purchase that should be rounded down, for example 1.97 rounded down to 1.95. On the payment screen if you select a payment method and pay with a greater amount than the base amount. The total due would be rounded incorrectly to 2.00 instead of 1.95. Steps to reproduce: - Create a product with a price of 1.97 - Set a rouding down method of 0.05 - Open a pos session - Add the product to the order - Select a payment method, for example cash and enter an amount greater than the base amount, for example 5.00 - The total due will be 2.00 instead of 1.95 opw-3175726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113819 Forward-Port-Of: odoo/odoo#113428
To reproduce the issue: 1. Create user with no access rights apart from user rights in Sales, Sign, Project and Timesheet 2. Create a project, add a task inside and link an analytic account to the project 3. Create an RFQ, add a product linked to the analytic account 4. Confirm order, receive product, validate, create bill 5. Log in with user 6. Try to access the analytic account through: Project->Task->project name->Settings->Analytic account 7. An error message pops-up "You are not allo
Original PR description
To reproduce the issue: 1. Create user with no access rights apart from user rights in Sales, Sign, Project and Timesheet 2. Create a project, add a task inside and link an analytic account to the…
To reproduce the issue: 1. Create user with no access rights apart from user rights in Sales, Sign, Project and Timesheet 2. Create a project, add a task inside and link an analytic account to the project 3. Create an RFQ, add a product linked to the analytic account 4. Confirm order, receive product, validate, create bill 5. Log in with user 6. Try to access the analytic account through: Project->Task->project name->Settings->Analytic account 7. An error message pops-up "You are not allowed to access Purchase Order (purchase.order) records." Error: You should be able to access the analytic account, but the Purchase Order smart button should not be visible/present The data access by the smart button was not stopped by rules or groups, thus data was always trying to be loaded, even when the user did not have the access rights OPW-3180788 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114851 Forward-Port-Of: odoo/odoo#114701
Before this commit: in the PoS restaurant paid orders' date will be shown wrong. The problem is that it will be sent based on the user's timezone, and `init_from_json` in PoS restaurant converts it again to the local time. The solution is to send the time with its offset. Converting the time to string will keep the time offset in the format. opw-3195027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114142
Original PR description
Before this commit: in the PoS restaurant paid orders' date will be shown wrong. The problem is that it will be sent based on the user's timezone, and `init_from_json` in PoS restaurant converts it again to the local time. The solution is to send the time with its offset. Converting the time to string will keep the time offset in the format. opw-3195027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114142
Before this commit ------------------ Before this commit, the db migration from the 15.0 to 16.0 test case is failing while this is migrating analytic_account, in computing methods trying to use a direct field without reference. ``` Traceback (most recent call last): File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 223, in crawl_menu self.mock_action(action_vals) File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
Original PR description
Before this commit ------------------ Before this commit, the db migration from the 15.0 to 16.0 test case is failing while this is migrating analytic_account, in computing methods trying to use a…
Before this commit
------------------
Before this commit, the db migration from the 15.0 to 16.0 test case is failing while this is migrating analytic_account, in computing methods trying to use a direct field without reference.
```
Traceback (most recent call last):
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 223, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpmjg7gno3/migrations/base/tests/test_mock_crawl.py", line 405, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 2977, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3126, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5847, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1188, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1347, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4186, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/16.0/addons/account/models/account_analytic_account.py", line 38, in _compute_invoice_count
self._cr.execute(query_string, query_param)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 516, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 313, in execute
res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "move_id" is ambiguous
LINE 1: ...lytic_distribution) as account_id, COUNT(DISTINCT(move_id)) ...
```
After this commit
-----------------
In this commit added the reference to the move_id which is used without reference.
TaskId: 3141476
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#115132Description of the issue/feature this PR addresses: Issue: - When editing the `quantity_done` on a `stock.move` that is in "done" state, even if the old quantity and the new quantity are the same, a new `stock.valuation.layer` is still generated. Current behavior before PR: - Video: https://user-images.githubusercontent.com/65999461/221755106-51a44cf1-d102-4356-b079-53668ba3ba5e.mp4 Desired behavior after PR is merged: - Video: https://user-images.githubusercontent.com/6599
Original PR description
Description of the issue/feature this PR addresses: Issue: - When editing the `quantity_done` on a `stock.move` that is in "done" state, even if the old quantity and the new quantity are the same, a new `stock.valuation.layer` is still generated. Current behavior before PR: - Video: https://user-images.githubusercontent.com/65999461/221755106-51a44cf1-d102-4356-b079-53668ba3ba5e.mp4 Desired behavior after PR is merged: - Video: https://user-images.githubusercontent.com/65999461/221755980-5dbdb3fe-e261-4767-a107-d978b30e53f4.mp4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113814
- postmortem debugging has not worked since #78857 and I could not find any trace of somebody caring, reintroducing debugger calls as needed is easy enough - werkzeug's interactive debugger seems even less useful: though harder to introduce by hand, it only work on the frontend in a threaded server Left qweb's t-debug support as it's basically independent, and might provide a lot more value. Forward-Port-Of: odoo/odoo#115076
Original PR description
- postmortem debugging has not worked since #78857 and I could not find any trace of somebody caring, reintroducing debugger calls as needed is easy enough - werkzeug's interactive debugger seems even less useful: though harder to introduce by hand, it only work on the frontend in a threaded server Left qweb's t-debug support as it's basically independent, and might provide a lot more value. Forward-Port-Of: odoo/odoo#115076
Steps: 1. Create Employee A that related with user A / partner A in Sales department 2. Create a channel Sales, set Auto Subscribe Departments as Sales department 3. Archive Employee A / user A / partner A 4. Create a application B in Sales department and click button Create Employee 5. An error occurred: duplicate key value violates unique constraint "mail_channel_partner_partner_unique" Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavi
Original PR description
Steps: 1. Create Employee A that related with user A / partner A in Sales department 2. Create a channel Sales, set Auto Subscribe Departments as Sales department 3. Archive Employee A / user A / partner A 4. Create a application B in Sales department and click button Create Employee 5. An error occurred: duplicate key value violates unique constraint "mail_channel_partner_partner_unique" Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115025
This issue was occurring while printing the count sheets in the 'update quantity' section of products in 'Inventory' module.  Steps to Reproduce: - Go to products and select any product. - Click on update quantity button in product form view. - Click create button, select the new record without saving it. Then click Print > Count Sheet To fix this we check whether it is
Original PR description
This issue was occurring while printing the count sheets in the 'update quantity' section of products in 'Inventory' module.  Steps to Reproduce: - Go to products and select any product. - Click on update quantity button in product form view. - Click create button, select the new record without saving it. Then click Print > Count Sheet To fix this we check whether it is integer or not, if it is integer then only it will print the report. sentry-3880400776 Forward-Port-Of: odoo/odoo#112793
Steps to reproduce: - Create 2 SN tracked products - Create a receipt of the 2 products, with a demand qty of 2+ of each product - Create the SNs of the incoming products + validate picking - Print Labels > 2x7 or 4x12 (with or without price) > confirm Expected result: 2+ labels per product printed, 1 for each SN Actual result: Only 1st label of the 2nd product is printed, all of labels of the 1st product are printed Issue: The "quantity" in: https://github.com/odoo/odoo/blob/da
Original PR description
Steps to reproduce: - Create 2 SN tracked products - Create a receipt of the 2 products, with a demand qty of 2+ of each product - Create the SNs of the incoming products + validate picking - Print…
Steps to reproduce:
- Create 2 SN tracked products
- Create a receipt of the 2 products, with a demand qty of 2+ of each product
- Create the SNs of the incoming products + validate picking
- Print Labels > 2x7 or 4x12 (with or without price) > confirm
Expected result:
2+ labels per product printed, 1 for each SN
Actual result:
Only 1st label of the 2nd product is printed, all of labels of the 1st product are printed
Issue:
The "quantity" in:
https://github.com/odoo/odoo/blob/da30b41022c4f05b3abfdc3e64519d8438d25745/addons/product/report/product_product_templates.xml#L155-L156
is structured as:
{product, [(barcode_to_print, qty_to_print), ...], ...}
or in this case:
{product2: [(product2_sn1, 1), (product2_sn2, 1), ...], product1: [(product1_sn1, 1), (product1_sn2, 1), ...]}
So there was a miscounting where:
https://github.com/odoo/odoo/blob/da30b41022c4f05b3abfdc3e64519d8438d25745/addons/product/report/product_product_templates.xml#L162-L164
Would set the current_quantity to 0 (since only 1 per SN barcode)
And:
https://github.com/odoo/odoo/blob/da30b41022c4f05b3abfdc3e64519d8438d25745/addons/product/report/product_product_templates.xml#L155-L156
would register the not (current_quantity=0) as true and quantity={product1: (...),...} as true => move onto the next product rather than checking if there are any more (barcode, qty) tuples to print, i.e. never reach:
https://github.com/odoo/odoo/blob/da30b41022c4f05b3abfdc3e64519d8438d25745/addons/product/report/product_product_templates.xml#L166-L167
for product2 and therefore never reach its (sn,qty) labels beyond it's first one.
Note that this issue does not occur for the dymo or zpl labels because they follow different, less complicated templates
opw-3199095
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#114915If the developer wants to give warehouse_id form view location, when create new location, there will be an error in the compute function because it use function split() with field parent_path has no value.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114819
Original PR description
If the developer wants to give warehouse_id form view location, when create new location, there will be an error in the compute function because it use function split() with field parent_path has no value.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114819
The following basic case has been broken in website forever since [1] in Odoo 8: ```html <p><span>a</span><span>b</span></p> ``` Saving the above html results in: ```html <p> <span>a</span> <span>b</span> </p> ``` Which, when re-rendered back in the DOM renders equivalent to: ```html <p><span>a</span> <span>b</span></p> ``` Note the space between "a" and "b". That is because etree will pretty print nodes with indentations as long as they do not have text content,
Original PR description
The following basic case has been broken in website forever since [1] in Odoo 8: ```html <p><span>a</span><span>b</span></p> ``` Saving the above html results in: ```html <p> <span>a</span>…
The following basic case has been broken in website forever since [1] in Odoo 8:
```html
<p><span>a</span><span>b</span></p>
```
Saving the above html results in:
```html
<p>
<span>a</span>
<span>b</span>
</p>
```
Which, when re-rendered back in the DOM renders equivalent to:
```html
<p><span>a</span> <span>b</span></p>
```
Note the space between "a" and "b". That is because etree will pretty print nodes with indentations as long as they do not have text content, and that indentation is collapsed into a single visible space by the browser when inserted in the DOM. This is not limited to span nodes as the same applies to any inline node. This is very easily reproduced in website on any version:
- Drop a Text snippet.
- Replace all the content of the snippet by "ab".
- Put "a" in bold and "b" in italic.
- Save.
- Notice that the saved version is now "a b" instead "ab".
The user has no way of removing this space easily because even if they manage to do it by any mean, the server will pretty print the html again and the space will reappear. The only way to circumvent this is to have some text content as sibling of the inline nodes.
Consider this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span></p>'), pretty_print=True)
b'<p>\n <span>a</span>\n <span>b</span>\n</p>\n'
```
Which is incorrect, while this:
```
>>> etree.tostring(html.fromstring('<p><span>a</span><span>b</span>c</p>'), pretty_print=True)
b'<p><span>a</span><span>b</span>c</p>\n'
```
Is correct.
We could fix it using a heavy hack that would leverage this behavior by inserting one of the few unicode control characters that etree considers to be actual content, and therefore preventing pretty printing for this node. The server would then remove the control character to avoid polluting the actual views. This would have the side-effect of forbidding this control character to ever be used in a view however, and would obviously be an extremely ugly hack.
The alternative which was chosen in accordance with Antony (al) and Xavier (xmo) is to disable pretty printing altogether, since the original commit [1] seem to have introduced it as a fix for an old version of the editor rather than for the intrinsic qualities of having pretty printed views.
If we ever want to re-enable pretty printing in the future, I suggest it be implemented in JS because the browser is the only one able to assert whether a node is going to be treated as a block or as an inline with respect to the current CSS rules in application.
task-3142796
opw-3122373
opw-3186250
[1]: https://github.com/odoo/odoo/commit/6b857b6eeb59137a71385f98c82c440ac82cd45d
Forward-Port-Of: odoo/odoo#113150**Current behavior before PR:** When we add a single / on editor and add any extra character immediately after the first / and press up/down arrow key it throws a traceback error. **Desired behavior after PR is merged:** Now, if any new characters is added after the first / and press arrow key then it does not throw any traceback error. **Task-3193362** Forward-Port-Of: odoo/odoo#114521
Original PR description
**Current behavior before PR:** When we add a single / on editor and add any extra character immediately after the first / and press up/down arrow key it throws a traceback error. **Desired behavior after PR is merged:** Now, if any new characters is added after the first / and press arrow key then it does not throw any traceback error. **Task-3193362** Forward-Port-Of: odoo/odoo#114521
Before this PR, the res config for the accounting page needed some UI fixes (checkbox misplaced, missing attrs invisible). This PR fixes that. task-id: 3226604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115167 Forward-Port-Of: odoo/odoo#115079
Original PR description
Before this PR, the res config for the accounting page needed some UI fixes (checkbox misplaced, missing attrs invisible). This PR fixes that. task-id: 3226604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115167 Forward-Port-Of: odoo/odoo#115079
`base_automation` module patches `write` method to detect changes that trigger the automated actions. It's implemented by reading current values before making the write operaion. It may lead to max recursion error if compute method updates other records. Example: in `account_asset` Depreciation values are computed for all Depreciation Lines at the same time [1]. Fix it by breaking recursion on computed not stored readonly fields: `write` method for such fields might be called by compute metho
Original PR description
`base_automation` module patches `write` method to detect changes that trigger the automated actions. It's implemented by reading current values before making the write operaion. It may lead to max…
`base_automation` module patches `write` method to detect changes that trigger the automated actions. It's implemented by reading current values before making the write operaion. It may lead to max recursion error if compute method updates other records. Example: in `account_asset` Depreciation values are computed for all Depreciation Lines at the same time [1]. Fix it by breaking recursion on computed not stored readonly fields: `write` method for such fields might be called by compute method only and hence the old value is always equal to new value. STEPS: - Create an Asset model of 240 Months, Straight Line, No pro rata - Create Assets using this asset model and confirm it. - Create an automated action for account.move and trigger on update (Action can be anything) - Now try to access the Assets [1]: https://github.com/odoo/enterprise/blob/45dd0884c84d0e8a31c2c36a975f1b1f7cf6d01c/account_asset/models/account_move.py#L39-L46 opw-3147688 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112711
[FIX] web: tooltip question mark using wrong class This commit replaces the `btn-link` with `text-info` since it is not a button and the `btn-link` class should be used in pair with the `btn` class. Moreover, the question mark button in form view supposed to trigger the `tooltip` box is difficult to reach since the triggering area behaves weirdly on chromium OSX. This is fixed in a separate commit: d44d5e8ddea5e7e548cfe8fd74fc8e964ff088c6 This commit has been rebased to target 1
Original PR description
[FIX] web: tooltip question mark using wrong class This commit replaces the `btn-link` with `text-info` since it is not a button and the `btn-link` class should be used in pair with the `btn` class. Moreover, the question mark button in form view supposed to trigger the `tooltip` box is difficult to reach since the triggering area behaves weirdly on chromium OSX. This is fixed in a separate commit: d44d5e8ddea5e7e548cfe8fd74fc8e964ff088c6 This commit has been rebased to target 16.0 in accordance to the other commit fixing the behavior of the tooltip. task-3099734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108772
Using the bank recon widget (enterprise), it is possible to create bank statements from the list view. The default start and end balances were not computed. This PR fixes that (computes the balances) and has a few additional improvements: - A warning is added to the statement form view to indicate the problem with the statement - Statement validity can be computed before the statement is saved, to guide the user when manually creating statements - balance_start, balance_end_real are now com
Original PR description
Using the bank recon widget (enterprise), it is possible to create bank statements from the list view. The default start and end balances were not computed. This PR fixes that (computes the balances) and has a few additional improvements: - A warning is added to the statement form view to indicate the problem with the statement - Statement validity can be computed before the statement is saved, to guide the user when manually creating statements - balance_start, balance_end_real are now computed fields - default_get method is simplified and moved - the action "Create Statement" is removed in favour of multi-edit - tests and translation templates - added code to avoid a module update related enterprise PR contains the necessary view changes. Forward-Port-Of: odoo/odoo#115082 Forward-Port-Of: odoo/odoo#112710
The `afternextrender` helper is meant to be used in some tests that want to do something after owl has completed all its work following a specific action. It is useful when the action may cause some additional renders, so waiting for one nextTick is not enough. Unfortunately, it has a bug: it waits for Owl scheduler to be empty. But in some cases, when a component is destroyed because of an error, the scheduler task list will not be cleared until the next render completes. It is implemented t
Original PR description
The `afternextrender` helper is meant to be used in some tests that want to do something after owl has completed all its work following a specific action. It is useful when the action may cause some…
The `afternextrender` helper is meant to be used in some tests that want to do something after owl has completed all its work following a specific action. It is useful when the action may cause some additional renders, so waiting for one nextTick is not enough. Unfortunately, it has a bug: it waits for Owl scheduler to be empty. But in some cases, when a component is destroyed because of an error, the scheduler task list will not be cleared until the next render completes. It is implemented that way in Owl to reduce the amount of work it does. But this means that in some testing scenarios, the afterNextRender promise will simply not be resolved, since there is no upcoming render to clear the tasklist. With this commit, we just avoid the issue by ignoring the fibers coming from destroyed component. Note that I think that it is not a good semantic for tests, as it is a little bit too "black-boxy". Ideally, we should rather wait for something in the DOM. There is a waitUntil helper somewhere that may be useful for this situation Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115185
1. Install [Events] 2. On [Settings], create an admin for Events (uncheck all other rights) 3. Click on Events, enter an event 3. Click on [Communication] tab, and try adding a line Issue: accessing ir.model is blocked Solution: Find another way Impacted versions: 15 - master opw-3163138, 3103199, 3193659 Forward-Port-Of: odoo/odoo#115101 Forward-Port-Of: odoo/odoo#112527
Original PR description
1. Install [Events] 2. On [Settings], create an admin for Events (uncheck all other rights) 3. Click on Events, enter an event 3. Click on [Communication] tab, and try adding a line Issue: accessing ir.model is blocked Solution: Find another way Impacted versions: 15 - master opw-3163138, 3103199, 3193659 Forward-Port-Of: odoo/odoo#115101 Forward-Port-Of: odoo/odoo#112527
When upgrading a database with `l10n_multilang` installed, the translations kept were not the right ones. Here is the process that was executed during the upgrade: * `base` is loaded: registry is loaded with `translate=True`, which calls `convert_column_translatable`. This has the effect of setting the value of the field to `{'en_US': name}`, with only that language installed. * `l10n_multilang` is loaded: the function `lang_install` is extended to copy the translations of the templates on th
Original PR description
When upgrading a database with `l10n_multilang` installed, the translations kept were not the right ones. Here is the process that was executed during the upgrade: * `base` is loaded: registry is…
When upgrading a database with `l10n_multilang` installed, the translations kept were not the right ones.
Here is the process that was executed during the upgrade:
* `base` is loaded: registry is loaded with `translate=True`, which calls `convert_column_translatable`. This has the effect of setting the value of the field to `{'en_US': name}`, with only that language installed.
* `l10n_multilang` is loaded: the function `lang_install` is extended to copy the translations of the templates on the instanciated records.
* `l10n_*` is loaded: the translation values are loaded from the `.po` files. `lang_install` is called after the loading on the templates, copying the value on the records. The value on the records is now something like `{'en_US': name, 'fr_BE': nom, 'nl_BE': naam}`.
* `base/end-migrate` is executed: it copies the values coming from `ir_translation`, without overriding the values that are already on the record because of the order of the `||` operator.
This means that any value inputed by the user[^1] will be overriden by the value in the `.po` files.
[opw-3175383](https://www.odoo.com/web#id=3175383&model=project.task)
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: HydrionBurst <cwg@odoo.com>
[^1]: not only inputed by the user, but also if the chart template is an older version whose templates were updated in the code in the meantime.
Forward-Port-Of: odoo/odoo#113669Steps to reproduce: 1. Install module Project 2. Enable Sub-Task feature in settings 3. Create a project A and add a task with subtasks with depth level >1. 4. Duplicate project A Issue: Duplicated child subtasks (depth >1) are not being mapped with the newly created project(duplicated one). Cause: Only mapping parent task due to wrong filter values. Solution: Map 'display_project_id ' id with the newly created project id on all child subtasks record sets. --- I confirm I
Original PR description
Steps to reproduce: 1. Install module Project 2. Enable Sub-Task feature in settings 3. Create a project A and add a task with subtasks with depth level >1. 4. Duplicate project A Issue: Duplicated child subtasks (depth >1) are not being mapped with the newly created project(duplicated one). Cause: Only mapping parent task due to wrong filter values. Solution: Map 'display_project_id ' id with the newly created project id on all child subtasks record sets. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108875
1. Install [Events] 2. On [Settings], create an admin for Events (uncheck all other rights) 3. Click on Events, enter an event 4. Click on [Communication] tab, and try adding a line Issue: accessing ir.model is blocked Solution: Find another way Impacted versions: 15 - master opw-3163138 related to https://github.com/odoo/odoo/pull/112527 Forward-Port-Of: odoo/enterprise#38097 Forward-Port-Of: odoo/enterprise#37019
Original PR description
1. Install [Events] 2. On [Settings], create an admin for Events (uncheck all other rights) 3. Click on Events, enter an event 4. Click on [Communication] tab, and try adding a line Issue: accessing ir.model is blocked Solution: Find another way Impacted versions: 15 - master opw-3163138 related to https://github.com/odoo/odoo/pull/112527 Forward-Port-Of: odoo/enterprise#38097 Forward-Port-Of: odoo/enterprise#37019
When creating a bank statement from the bank recon list view, the ending balance is not properly computed in the default_get method. Two cases exist: 1. the line is saved, or 2. it is a new unsaved line for which the user is creating the statement. This PR enables the computation of the ending balance for case 2 - since the line is not yet saved, the line amount is placed into the context. See the corresponding community PR. Forward-Port-Of: odoo/enterprise#38086 Forward-Port-Of: odoo/enterpris
Original PR description
When creating a bank statement from the bank recon list view, the ending balance is not properly computed in the default_get method. Two cases exist: 1. the line is saved, or 2. it is a new unsaved line for which the user is creating the statement. This PR enables the computation of the ending balance for case 2 - since the line is not yet saved, the line amount is placed into the context. See the corresponding community PR. Forward-Port-Of: odoo/enterprise#38086 Forward-Port-Of: odoo/enterprise#37074
Before this PR, the res config for the accounting page needed some UI fixes (checkbox misplaced, missing attrs invisible). This PR fixes that. task-id: 3226604 Forward-Port-Of: odoo/enterprise#38124 Forward-Port-Of: odoo/enterprise#38083
Original PR description
Before this PR, the res config for the accounting page needed some UI fixes (checkbox misplaced, missing attrs invisible). This PR fixes that. task-id: 3226604 Forward-Port-Of: odoo/enterprise#38124 Forward-Port-Of: odoo/enterprise#38083
Following this fix: https://github.com/odoo/enterprise/pull/33866 In BarcodeModel `_findLine` method, we check the line `picking_id` to know if we are in a picking or in an inventory adjustment. The issue is we don't fetch the move lines picking id in `stock_barcode` but we do once `stock_barcode_picking_batch` is installed. To fix that, this commit checks instead if the lines have a `qty_done` property defined (should have in any case for the picking). Also, in the test `test_gs1_receipt_
Original PR description
Following this fix: https://github.com/odoo/enterprise/pull/33866 In BarcodeModel `_findLine` method, we check the line `picking_id` to know if we are in a picking or in an inventory adjustment. The issue is we don't fetch the move lines picking id in `stock_barcode` but we do once `stock_barcode_picking_batch` is installed. To fix that, this commit checks instead if the lines have a `qty_done` property defined (should have in any case for the picking). Also, in the test `test_gs1_receipt_lot_serial`, actives the tracking group because this test checks lines tracked by lots. runbot build error: 15279 Forward-Port-Of: odoo/enterprise#37942 Forward-Port-Of: odoo/enterprise#36352
Before this commit, the computation of the quarter in the XML export gave inaccurate results for quarters 3 and 4. This was due to a wrong formula, which has been fixed here. Forward-Port-Of: odoo/enterprise#38112
Original PR description
Before this commit, the computation of the quarter in the XML export gave inaccurate results for quarters 3 and 4. This was due to a wrong formula, which has been fixed here. Forward-Port-Of: odoo/enterprise#38112
Prior to this commit, the IndExe tag relied on the validation of electronic invoices [<Line>](https://github.com/bmya/enterprise/blob/dd93622cf56cc2fd8d485a92fd014238f2460ef3/l10n_cl_edi_stock/template/dte_template.xml#L63), which was incorrect. This is because electronic tickets have their own validation process. With this commit, the issue has been resolved and the IndExe tag is now properly validated. , which was incorrect. This is because electronic tickets have their own validation process. With this commit, the issue has been resolved and the IndExe tag is now properly validated.  Forward-Port-Of: odoo/enterprise#37937 Forward-Port-Of: odoo/enterprise#37436
Steps: - Install `lunch` & `knowledge` - Open `lunch` and click on `Favorites` - Traceback opw-3224120 Forward-Port-Of: odoo/enterprise#38109
Original PR description
Steps: - Install `lunch` & `knowledge` - Open `lunch` and click on `Favorites` - Traceback opw-3224120 Forward-Port-Of: odoo/enterprise#38109
Steps: - Switch companies - sign document - Download certificate Issue: Receive the wrong header and company document layout Cause: The communication_company_id is never initialized when we create a sign.request object. Previously fixed in https://github.com/odoo/enterprise/pull/35910 opw-3195561 Forward-Port-Of: odoo/enterprise#37849
Original PR description
Steps: - Switch companies - sign document - Download certificate Issue: Receive the wrong header and company document layout Cause: The communication_company_id is never initialized when we create a sign.request object. Previously fixed in https://github.com/odoo/enterprise/pull/35910 opw-3195561 Forward-Port-Of: odoo/enterprise#37849
### Steps to reproduce * create a Horizontal Group on the General Ledger report with the domain "Account" * open the General Ledger and apply the Horizontal Group you just created * try to unfold some lines You should be met with a traceback. opw-3164080 Forward-Port-Of: odoo/enterprise#37656
Original PR description
### Steps to reproduce * create a Horizontal Group on the General Ledger report with the domain "Account" * open the General Ledger and apply the Horizontal Group you just created * try to unfold some lines You should be met with a traceback. opw-3164080 Forward-Port-Of: odoo/enterprise#37656
To Reproduce ============ - enable dev mode - go to mrp > Master Production Schedule Problem ======= when validating the props of `withSearch`, the prop `orderBy` doesn't have the correct type which is **Array of Objects**. this problem is introduced after this [fix](https://github.com/odoo/odoo/commit/8b1814bdfa177e58c80c74d235f7b49273aef728), where we changed the type of `orderBy` from `string[]` to `ObjectTerm[]`. Solution ======== maker `orderBy` an object opw-3217069 For
Original PR description
To Reproduce ============ - enable dev mode - go to mrp > Master Production Schedule Problem ======= when validating the props of `withSearch`, the prop `orderBy` doesn't have the correct type which is **Array of Objects**. this problem is introduced after this [fix](https://github.com/odoo/odoo/commit/8b1814bdfa177e58c80c74d235f7b49273aef728), where we changed the type of `orderBy` from `string[]` to `ObjectTerm[]`. Solution ======== maker `orderBy` an object opw-3217069 Forward-Port-Of: odoo/enterprise#38117
default=fields.Datetime.now() is taking the date when the server started we should use default=fields.Datetime.now instead. When the cron is running and is having a validationError due to an error when creating transactions for example (same sequence number already exists), that error is catched with the except UserError and we do nothing with it. Which means that on the next iteration, when the cron will try to commit, the error will still be present and that will raise again. To prevent tha
Original PR description
default=fields.Datetime.now() is taking the date when the server started we should use default=fields.Datetime.now instead. When the cron is running and is having a validationError due to an error when creating transactions for example (same sequence number already exists), that error is catched with the except UserError and we do nothing with it. Which means that on the next iteration, when the cron will try to commit, the error will still be present and that will raise again. To prevent that, we rollback when we encounter an error. Forward-Port-Of: odoo/enterprise#38065 Forward-Port-Of: odoo/enterprise#38053