Daily updates from Odoo
Tuesday, August 27, 2024
30 changes · master
Enhancements to existing features
Odoo now creates IoT Box connection links using standard web address parameters instead of pipe separators. This makes the links more compatible with common tools and reduces the risk of connection issues caused by unusual URL formatting.
Original PR description
URL generated by Odoo to connect an IoT Box used pipes to separate important data. We now use regular search params: `?param1=value1¶m2=value2`. Community PR: [https://github.com/odoo/odoo/pull/178033](https://github.com/odoo/odoo/pull/178033) Task: 4116429
Accounting-related kanban cards have been updated to use newer standard layouts and styling. This makes the views easier to maintain and keeps the user interface aligned with current Odoo conventions, with minimal visible change for end users.
Original PR description
\* = [account_asset, account_batch_payment, account_budget, account_consolidation aacount_intrastat] In this commit we have simplified the kanban arch for the account_accountant and related modules. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name="..." widget="image"/>` instead Community pr: https://github.com/odoo/odoo/pull/177227 Task-3992107
Resolved issues and error corrections
This fix updates spreadsheet document tests so they match recent changes in how pivot identifiers and titles are displayed. It helps keep automated quality checks reliable without changing day-to-day user behavior.
This fix stops restaurant orders from being transferred when an appointment booking is being created. It helps avoid accidental changes to table orders and keeps the booking flow reliable for staff.
Original PR description
Related: https://github.com/odoo/odoo/pull/177039
This change moves a stock-related intercompany sales and purchasing test into the module that owns stock behavior. It helps keep automated checks aligned with the correct business area, reducing maintenance risk without changing user-facing functionality.
This fix updates Documents Spreadsheet behavior to work correctly with the latest pivot table title display. It helps keep spreadsheet pivot menus and side panels reliable after the underlying title component changed.
Code cleanup and technical improvements
This update adjusts the Planning app to stay aligned with a recent underlying platform change in how formatted field values are handled. It is an internal compatibility update with no expected change to day-to-day user workflows.
Original PR description
Related to odoo/odoo#177747, where the `getFormattedValue` util now automatically extracts formatter options from the field node (in the arch). As a consequence, the API of the util slightly changed, and a call in planning had to be adapted.
Miscellaneous changes
Problem: When the user enable approval rules for confirming purchase orders, the approval message was not being translated to the user's preferred languages. Purpose: Since multiple users can be notified for the approval, it was discussed that translating the message to be in the language of the first user should help with the limitation. It will solve the bug in the case only one user needs to be notified. Steps to reproduce on Runbot: 1. Install Studio and purchase 2. create a purchase
Original PR description
Problem: When the user enable approval rules for confirming purchase orders, the approval message was not being translated to the user's preferred languages. Purpose: Since multiple users can be notified for the approval, it was discussed that translating the message to be in the language of the first user should help with the limitation. It will solve the bug in the case only one user needs to be notified. Steps to reproduce on Runbot: 1. Install Studio and purchase 2. create a purchase order without confirming it 3. Go into Studio and edit the "confirm order' button on the PO 4. Add 2 approval rules - notify User A with notification order 1 - notify User B whose language is not English with notification order 2 5. Confirm the PO and observe the message is sent in English opw-3932725 Forward-Port-Of: odoo/enterprise#64060
This PR replaces https://github.com/odoo/enterprise/pull/55511 Forward-Port-Of: odoo/enterprise#67574 Forward-Port-Of: odoo/enterprise#56146
Original PR description
This PR replaces https://github.com/odoo/enterprise/pull/55511 Forward-Port-Of: odoo/enterprise#67574 Forward-Port-Of: odoo/enterprise#56146
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - cli
Original PR description
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - click on the delivery address - remove the partner's parent_id - add an email and phone number to the partner and save - go back to the picking page and click validate - a traceback will appear ## Solution: - in the `_prepare_parcel_common_data` method, raise a user error if the SO has `access_point_data` and the partner has no parent_id. OPW-4042529 Forward-Port-Of: odoo/enterprise#68625 Forward-Port-Of: odoo/enterprise#67074
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to noth
Original PR description
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft…
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to nothing - (Make sure the User Type is Internal User) - Switch to this user - Go to Sales and create a new Quotation, confirm - Click on the 'Create Invoice' button - An access error appears because of 'l10n_cl.account.invoice.reference' ### Cause: The records of `l10n_cl.account.invoice.reference` are only readable by Accounting groups. ### Solution: Make the records of `l10n_cl.account.invoice.reference` accessible to all internal users. This will raise another access error for `l10n_latam.document.type`, so we also need to make them accessible (in community). ### Note: I noticed the access right of `l10n_cl.account.invoice.reference` were giving rights to `account.group_account_invoice` twice where I think the second time was supposed to be `account.group_account_manager`. I don't know if this is wanted but it doesn't make sense to have two lines for the same model and user group. I decided to only change `group_account_invoice` to `group_account_manager` so this PR is removing the write, create, unlink rights of `account.group_account_invoice`. opw-4078302 Forward-Port-Of: odoo/enterprise#68087
Problem: The SEPA configuration fields sepa_orgid_id and sepa_orgid_issr are reset when exporting and importing a partner (company) associated with a company. Steps to Reproduce: 1. Configure a "SEPA Credit Transfer (SCT)" for a company. 2. Export the partner related to the company. 3. Re-import the partner. 4. Check the SEPA configuration of the company; it is reset. Solution: To fix this, we need to prevent the SEPA configuration from being reset when it is already set. opw-3981
Original PR description
Problem: The SEPA configuration fields sepa_orgid_id and sepa_orgid_issr are reset when exporting and importing a partner (company) associated with a company. Steps to Reproduce: 1. Configure a "SEPA Credit Transfer (SCT)" for a company. 2. Export the partner related to the company. 3. Re-import the partner. 4. Check the SEPA configuration of the company; it is reset. Solution: To fix this, we need to prevent the SEPA configuration from being reset when it is already set. opw-3981278 Forward-Port-Of: odoo/enterprise#67424
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to re
Original PR description
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to reproduce the issue:__ - add products to your cart - remove one or many products of the stock - try to validate your payment __linked to Odoo PR:__ https://github.com/odoo/odoo/pull/174615 opw-4016059 (upgrade issues) Forward-Port-Of: odoo/enterprise#68557 Forward-Port-Of: odoo/enterprise#67423
Forward-Port-Of: odoo/enterprise#68915
Original PR description
Forward-Port-Of: odoo/enterprise#68915
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity descr
Original PR description
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type…
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity description" is mandatory, as it's not an export document. The country customs code must be included in the Nacionalidad tag as well, as the vendor is foreign. Reference: Law Nº21420, and resolution Nº46 (May 13th, 2022) https://www.bcn.cl/leychile/navegar?idNorma=1172303 https://www.sii.cl/normativa_legislacion/resoluciones/2022/reso46.pdf After this PR: These issues are fixed. Community PR: https://github.com/odoo/odoo/pull/166793 Forward-Port-Of: odoo/enterprise#63311 Forward-Port-Of: odoo/enterprise#63244
`partners` and `guests` are not handled in the client side anymore. They should be replaced by `personas`. Forward-Port-Of: odoo/enterprise#68839
Original PR description
`partners` and `guests` are not handled in the client side anymore. They should be replaced by `personas`. Forward-Port-Of: odoo/enterprise#68839
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#68726 Forward-Port-Of: odoo/enterprise#65904
Original PR description
Part of a UI task. Changed CONTINUE/PAUSE to CONTINUE/START Regenerated the PDF file task-id: 3646156 community: https://github.com/odoo/odoo/pull/171616 Forward-Port-Of: odoo/enterprise#68726 Forward-Port-Of: odoo/enterprise#65904
The version of the csv is now 7.0. Adapt the headers to it, they must now all be present. The values don't seem to have changed, at least the ones required that we provide. task-4131986 Forward-Port-Of: odoo/enterprise#68853 Forward-Port-Of: odoo/enterprise#68796
Original PR description
The version of the csv is now 7.0. Adapt the headers to it, they must now all be present. The values don't seem to have changed, at least the ones required that we provide. task-4131986 Forward-Port-Of: odoo/enterprise#68853 Forward-Port-Of: odoo/enterprise#68796
Forward-Port-Of: odoo/enterprise#68821 Forward-Port-Of: odoo/enterprise#68704
Original PR description
Forward-Port-Of: odoo/enterprise#68821 Forward-Port-Of: odoo/enterprise#68704
Some improvements in EDI to support factoring operations. The tag "plazo" and "unidadTiempo" are mandatory in order to a company can be a factor . (Sell off all of its outstanding invoices at one time, rather than having to wait on collecting payments from customers) - Rename tag "RespuestaAutorizacion" to "autorizacion" - Add tag "plazo" and "unidadTiempo" in Sales Invoices and Debit Note (not only for Purchase liquidation) - Modify unit tests Forward-Port-Of: odoo/enterprise#68520 Forward
Original PR description
Some improvements in EDI to support factoring operations. The tag "plazo" and "unidadTiempo" are mandatory in order to a company can be a factor . (Sell off all of its outstanding invoices at one time, rather than having to wait on collecting payments from customers) - Rename tag "RespuestaAutorizacion" to "autorizacion" - Add tag "plazo" and "unidadTiempo" in Sales Invoices and Debit Note (not only for Purchase liquidation) - Modify unit tests Forward-Port-Of: odoo/enterprise#68520 Forward-Port-Of: odoo/enterprise#67572
Duplicating a sheet would not add the sheet ID to the cellThreads map in the cell threads plugin. This would cause issues when adding rows or columns because the sheetId can't be referenced and an error is thrown. Added a case in handle in order to add the new sheet id from duplicating to the cellThreads map. opw-4100746 Forward-Port-Of: odoo/enterprise#68406
Original PR description
Duplicating a sheet would not add the sheet ID to the cellThreads map in the cell threads plugin. This would cause issues when adding rows or columns because the sheetId can't be referenced and an error is thrown. Added a case in handle in order to add the new sheet id from duplicating to the cellThreads map. opw-4100746 Forward-Port-Of: odoo/enterprise#68406
### Steps to Reproduce: - Create a field service task > switch the worksheet template to false > add products and timesheets > sign report > error because there is no worksheet template set. ### After this PR: - Allow signing the report when there is no worksheet template, it will be possible to sign and send the report as long as there is content to populate the report with ( products and timesheets). task-3974170 Forward-Port-Of: odoo/enterprise#68787 Forward-Port-Of: odoo/enterprise#
Original PR description
### Steps to Reproduce: - Create a field service task > switch the worksheet template to false > add products and timesheets > sign report > error because there is no worksheet template set. ### After this PR: - Allow signing the report when there is no worksheet template, it will be possible to sign and send the report as long as there is content to populate the report with ( products and timesheets). task-3974170 Forward-Port-Of: odoo/enterprise#68787 Forward-Port-Of: odoo/enterprise#65367
The tour `test_sections_tour` fails undeterministically. It fails after opening the the variant, then opening another section of it. The issue is that we try to open the second section just before the preloading of this section happens. The opening of it enters `loadReportOptions`, has no loadingCallNumber as it is the first opening. We then stop at the call to `get_options`. Then, the preloading can happen (which is why it's undeterministic). We enter the `if` in `preLoadClosedSection
Original PR description
The tour `test_sections_tour` fails undeterministically. It fails after opening the the variant, then opening another section of it. The issue is that we try to open the second section just before the preloading of this section happens. The opening of it enters `loadReportOptions`, has no loadingCallNumber as it is the first opening. We then stop at the call to `get_options`. Then, the preloading can happen (which is why it's undeterministic). We enter the `if` in `preLoadClosedSections`, as the options are not yet of the second section. We then increment loadingCallNumber, which means it's not in sync with the call that was made to the python. If the options call comes back now, we don't remake a call with the new loadingCallNumber. runbot-75429 runbot-74795 Forward-Port-Of: odoo/enterprise#68539
Purpose ======= Fix the "open record" action for the activities kanban in the marketing campaign form. The record can be opened when clicking anywhere on the kanban article, it should only be opened when clicking on the title of the acitvity. Specification ============= Following this commit https://github.com/odoo/odoo/commit/d52fc5ae69a9ca55df22f416a26c1ea5f5484ac9 the kanban arch parser has been updated changing the condition to open the record from this 'this.allowGlobalClick' to
Original PR description
Purpose ======= Fix the "open record" action for the activities kanban in the marketing campaign form. The record can be opened when clicking anywhere on the kanban article, it should only be opened…
Purpose ======= Fix the "open record" action for the activities kanban in the marketing campaign form. The record can be opened when clicking anywhere on the kanban article, it should only be opened when clicking on the title of the acitvity. Specification ============= Following this commit https://github.com/odoo/odoo/commit/d52fc5ae69a9ca55df22f416a26c1ea5f5484ac9 the kanban arch parser has been updated changing the condition to open the record from this 'this.allowGlobalClick' to this 'this.props.archInfo.canOpenRecords'. It was previously only opening the record when the user clicked on the element with the 'oe_kanban_action' class (i.e. the activity title) but is now opening the record no matter where the click is on the kanban article. Fixing the issue by adding the new 'can_open' attribute on the kanban and setting it to false bringing back the old behavior. Also adding the 'user-select-none' class on the 'Add child activity' button so that the cursor isn't changed to the selector one when hovering the text. Task-4089001 Forward-Port-Of: odoo/enterprise#67806
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment
Original PR description
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment is installed alone, hopefully avoiding to miss the increased query count next time. Forward-Port-Of: odoo/enterprise#67769
Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record. ### Description of the issue : 1) When generating a `repair.order` record through a Helpdesk ticket or accessing an existing linked repair order through the smart button, the context key for `default_team_id` will be inherited. In this case referencing the id of the current `helpdesk.team` record. 2) When trying to generate a quote through
Original PR description
Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record. ### Description of the issue : 1) When generating…
Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record. ### Description of the issue : 1) When generating a `repair.order` record through a Helpdesk ticket or accessing an existing linked repair order through the smart button, the context key for `default_team_id` will be inherited. In this case referencing the id of the current `helpdesk.team` record. 2) When trying to generate a quote through the repair order, an edge case can happen where a ValidationError is triggered at sale order creation. ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Sales Order (sale.order) Constraint: sale_order_team_id_fkey ``` This is due to the fact that the `sales.order` also uses a `default_team_id` context key to designate the default sales team. If by happen stance, the referenced `id` values does not match an existing `crm.team` record, you will hit the above foreign key constraint blocking the user from generating the quote. ### Proposed fix : Functionally it makes no sense to pass the `default_team_id` context value from helpdesk to sales order, as both implicitly reference different models and functional entities. Since the `_prepare_repairs_default_value` was already introduced in https://github.com/odoo/enterprise/commit/edd88ebdcc60b7c4d261bfb8755e910356684a3f to handle the context value preparation when using the repair smart button, the simplest solution is to set the `default_team_id` context key to `False`, thus not passing it later on to the sales order (i.e. the quote will not have a default sales team, but the user can still manually define one) ### How to reproduce: 1) Set up a DB with sales, helpdesk and repairs installed 2) If using demo data, just create a handful of new helpdesk teams (`helpdesk.team`). The important part is that you have at least one record with an id that will not be present in the `crm.team` table 3) For the helpdesk team matching the above criteria, activate the Repairs option (`use_product_repairs`) in the team configuration 4) Create a helpdesk ticket for that helpdesk team, create a repair order using the action button, then try using the Create Quotation action button (`action_create_sale_order`) → Validation Error is triggered OPW-4123410 Forward-Port-Of: odoo/enterprise#68822
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into a
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% *…
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report. **Cause:** The report is checking the tax lines where the account is "2408%%" to compute the amount of this column. So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax. **Solution:** Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex. It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line. Recomputing all from the invoice lines would bad for the performance. As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding: [Monto del Pago Sujeto Retención = Retenido Consignado / 15%] opw-3989661 Forward-Port-Of: odoo/enterprise#68803 Forward-Port-Of: odoo/enterprise#68016
### Steps to reproduce: - Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive. - Create a product with 19% tax inclusive. - Create a contact and assign the above fiscal position. - Navigate to a field service project and add an employee with a tax-included rate in the employee mapping. - Create a new field service task for the customer with the assigned fiscal position and add one hour for the employee in the mapping. - Add the product with 19% tax included to
Original PR description
### Steps to reproduce: - Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive. - Create a product with 19% tax inclusive. - Create a contact and assign the above fiscal…
### Steps to reproduce: - Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive. - Create a product with 19% tax inclusive. - Create a contact and assign the above fiscal position. - Navigate to a field service project and add an employee with a tax-included rate in the employee mapping. - Create a new field service task for the customer with the assigned fiscal position and add one hour for the employee in the mapping. - Add the product with 19% tax included to the task. - Mark the task as done. #### Current Behavior: - The product unit price is calculated excluding tax. - The service unit price remains calculated as tax-included. #### Expected Behavior: Both product and service unit prices should be calculated consistently as tax-excluded when the tax is set to 19% exclusive. ### Cause of the issue: When creating a new sale order line if the unit price is not specified "product_id_change" is called which set the correct unit price after applying the fpos by calling `_update_taxes` on the line: https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L617-L628 But in our case we are setting the `unit_price` to the employee rate here: https://github.com/odoo/enterprise/blob/e23e01337faeec652d400618cf14aaf3d6d47ef2/industry_fsm_sale/models/project_task.py#L408-L412 and the taxes are not taken into account. ### Fix: The unit price of the employee rate should be updated to reflect the changed taxes from fpos. However, since `_update_taxes` relies on the unit price of the product rather than on the one given to the line: https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L685 we can not call the `_update_taxes` directly to update the sol. opw-3853196 Co-authored-by: waha <waha@odoo.com> Forward-Port-Of: odoo/enterprise#68661 Forward-Port-Of: odoo/enterprise#67730
In 8f74d9d the french translation for the accounting financial reports where forgotten. This add the missing translated terms opw-4124296 Forward-Port-Of: odoo/enterprise#68781
Original PR description
In 8f74d9d the french translation for the accounting financial reports where forgotten. This add the missing translated terms opw-4124296 Forward-Port-Of: odoo/enterprise#68781
Browse mehtod of orm only returns a recordset for the ids provided but it never checks if those ids exist, which with recompute of analytic_json field can lead to this error: 'odoo.exceptions.MissingError: Record does not exist or has been deleted.' Forward-Port-Of: odoo/enterprise#68660
Original PR description
Browse mehtod of orm only returns a recordset for the ids provided but it never checks if those ids exist, which with recompute of analytic_json field can lead to this error: 'odoo.exceptions.MissingError: Record does not exist or has been deleted.' Forward-Port-Of: odoo/enterprise#68660