Daily updates from Odoo
Thursday, June 4, 2026
53 changes · saas-19.3
Security fixes and vulnerability patches
This update strengthens the security of customer links within the Point of Sale module by ensuring the necessary authorization token is always included. Previously, the system was vulnerable to unauthorized access, and this fix centralizes the token handling for consistent and secure operation. This enhances overall system security.
Original PR description
The `customerDisplayPath` getter was missing the `access_token` parameter, which is required for proper authorization. Because of this, the `openCustomerDisplay` method was manually constructing its own URL to include the token. This commit centralizes the logic by appending the `access_token` directly to the `customerDisplayPath` getter. The dialog opener now reuses this property, ensuring consistency and preventing missing tokens if the path is accessed elsewhere. Forward-Port-Of: odoo/odoo#267985
Enhancements to existing features
This update streamlines the invoicing process by automatically reconciling invoices created from sale orders. Previously, this required manual steps; now, the system directly links invoices to the corresponding sale order, improving efficiency and accuracy. This change simplifies the accounting workflow and reduces the risk of errors.
Original PR description
This commit will allow to automatically reconcile the invoice create from the sale order by passing a context key that will be used in the create_invoices function. task-5502964 Forward-Port-Of: odoo/enterprise#108546
This update enhances how we track usage of our AI models by adding detailed labels to each request. This allows us to better understand which sources – like agents or web searches – are driving token consumption, leading to more accurate cost analysis and optimization of our AI investments. The changes improve our ability to monitor and manage AI resource utilization.
Original PR description
Tag each completion request with a human-readable label identifying what issued it (the agent, web search, AI field, AI server action, ...) so token usage can be attributed to a given source-model combination. Agent-driven requests are prefixed with "Agent:" to set them apart from feature calls. Example: ``` AI: [Agent: Ask AI] gemini-2.5-flash-lite request [0.68s] - Tokens: 115 in (0 cached)|5 out|0 reasoning AI: [Agent: Ask AI] gemini-3-flash-preview request [2.64s] - Tokens: 5295 in (4050 cached)|79 out|186 reasoning AI: [web search] gemini-3-flash-preview request [21.24s] - Tokens: 562 in (226 cached)|708 out|1343 reasoning AI: [Agent: Odoo Image Generation Agent] gemini-2.5-flash-image request [8.25s] - Tokens: 423 in (0 cached)|1324 out|0 reasoning ```
This update adjusts how global discounts are handled in invoices to meet the requirements of UBL (Universal Business Language) standards. Previously, discounts were represented as negative invoice lines, which is now changed to 'Allowances'. This ensures our invoices are correctly formatted for international trade and compliance.
Original PR description
Export global discounts as Allowances instead of negative invoice lines to comply with UBL specifications. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268177 Forward-Port-Of: odoo/odoo#261029
Resolved issues and error corrections
This update resolves an error that occurred when users created new accounts in the accounting module, specifically for the Mexican (l10n_mx) localization. A recent change made account codes optional, but the system was incorrectly handling the absence of a code. This fix ensures accounts are created correctly regardless of whether an account code is provided.
Original PR description
Currently, an error occurs when a user creates an account record. Steps to Reproduce: - Install `Accounting` and `l10n_mx` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company. - Go to…
Currently, an error occurs when a user creates an account record. Steps to Reproduce: - Install `Accounting` and `l10n_mx` module with demo data. - Switch to `ZAPATERIA URTADO ÑERI` company. - Go to `Accounting` > `Configuration` > `Accounting` > `Chart of Accounts` and create a record. `TypeError: 'bool' object is not subscriptable` After a [recent commit], account codes became optional and can be removed. As a result, when a user creates an account without a code, the code attempts to check whether the first letter of the account code is in the debit codes [1]. Since the account code is False, it raises an error. This commit ensures that if the internal group of an account is asset or expense, the debit tag is assigned to the account. Otherwise, the credit tag is assigned to the account tags. [recent commit]: https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277 [1]- https://github.com/odoo/odoo/blob/a60643538479caf29aefeec89b8d356d8d5439c7/addons/l10n_mx/models/account_account.py#L17-L20 sentry-7490691483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Luxembourg tax reports were incorrectly generating company registry numbers instead of the agent's RCS number when a natural person accountant wasn't linked. The fix ensures the correct RCS number is included in the XML, preventing rejection by Luxembourg tax authorities. This ensures compliance and accurate reporting.
Original PR description
**Steps to reproduce:** * install `l10n_lu_reports`. * Create a company in Luxembourg with a `company_registry` number set. * Link this company to an accounting firm that is a natural person…
**Steps to reproduce:** * install `l10n_lu_reports`. * Create a company in Luxembourg with a `company_registry` number set. * Link this company to an accounting firm that is a natural person (independent accountant) with no business registration number — i.e. `l10n_lu_agent_rcs_number` is left empty on the agent partner. * Go to the tax report and generate the XML declaration. **Observed behavior:** * The `<Agent><RCSNbr>` field in the generated XML contains the company's own `company_registry` value instead of `NE`. * The file is rejected by the Luxembourg tax administration. **Cause:** * In `l10n_lu_generate_xml.py`, the `agent_rcs_number` template value was built with a plain `or` chain: `agent.l10n_lu_agent_rcs_number or company.company_registry or "NE"` * When an agent is set but has no RCS number (natural person), the fallback incorrectly continued to `company.company_registry` instead of stopping at `"NE"`. **Fix:** * Use a conditional expression so that `company.company_registry` is only used as a fallback when **no agent is linked** to the company: `(agent.l10n_lu_agent_rcs_number if agent else company.company_registry) or "NE"` opw-6044689 Forward-Port-Of: odoo/enterprise#112968
This update resolves an issue where changes made to form fields within a translation dialog were unexpectedly saved, even if the user didn't click 'OK' to confirm. The fix ensures that changes are only applied when the user explicitly saves the translation, improving data consistency and preventing unintended modifications. This improves the user experience and reduces potential errors.
Original PR description
[FIX] website: stop saving an attribute translation on close Steps to see the issue: - Drop a form on your page - Add a placeholder on one of the inputs - Save your changes, and switch to another language - Start translating - Click on the input with the placeholder - Make some changes to the placeholder, but don't click "Ok" - Close the dialog => The changes are still applied. task-5190459 Forward-Port-Of: odoo/odoo#264052
This update ensures that sensitive payroll information, like wages and yearly costs, is only visible to authorized users within the payroll group. A recent change in how tracking messages are generated no longer allows for filtering, so a new system has been implemented to separate and restrict access to these messages.
Original PR description
When a new version is created from the salary configurator, a tracking message summarizing field changes is posted on the employee chatter. This message may contain sensitive payroll information such…
When a new version is created from the salary configurator, a tracking message summarizing field changes is posted on the employee chatter. This message may contain sensitive payroll information such as wage and yearly cost, which should not be visible to users outside the payroll group. Previously, all tracking messages on hr.employee were visible to any user with access to the employee record. After the mail tracking refactor introduced in task (3645865) (https://www.odoo.com/odoo/project/1251/tasks/3645865), tracking values are now rendered directly into the message body, making the old field-level filtering mechanism no longer applicable. To restore payroll visibility restrictions: * Tracking values linked to payroll-restricted fields are separated from regular tracking values during `_track_log`. * Payroll-sensitive tracking values are posted in a dedicated tracking message using the subtype `mt_hr_payroll_sensitive`. * Regular tracking values continue to use the standard tracking flow and remain visible to all users with access to the employee chatter. * Employee chatter message fetching is overridden to hide payroll-sensitive messages from users outside `group_hr_payroll_user`. A test was also added to ensure payroll-sensitive tracking messages remain hidden from non-payroll users. Task: 4985543
This update ensures that manufacturing orders linked to projects with mandatory analytic plans are properly configured before confirmation. Previously, users could bypass this requirement, leading to potential accounting discrepancies. Now, the system enforces the use of a valid analytic distribution, preventing errors and improving data accuracy.
Original PR description
Currently, it is possible to confirm a manufacturing order linked to a project without an analytic distribution, even when a plan is set as mandatory for Manufacturing Orders. Fix: On action_confirm, check whether the related project has mandatory plans set and, if so, ensure they are filled — raising a ValidationError otherwise. task-id [6250034](https://www.odoo.com/odoo/project/967/tasks/6250034) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266943
This update fixes an issue where group allocations with past start dates were not correctly calculating accrual amounts. The change ensures that accruals are accurately computed when a group allocation is created, regardless of the start date, preventing zero accrual values.
Original PR description
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To…
Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce: 1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day) 2. From the allocations view -> New Group Allocation 3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off 4. Go to the newly created allocation The allocation amount is 0. Reason ---------------------- When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed. Solution ------------------ Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations. task-4938695 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#267768 Forward-Port-Of: odoo/odoo#265783
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to remain within the newly positioned content, ensuring a smoother and more intuitive editing experience. This improves usability and prevents confusion for users.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267844 Forward-Port-Of: odoo/odoo#264264
This update optimizes the styling of Odoo's Kanban dropdowns, specifically addressing slow CSS performance. By simplifying the CSS rules and adjusting how borders are displayed based on screen size, this change improves the responsiveness and speed of the Kanban interface.
Original PR description
This commit removes several expensive CSS selectors. After reviewing all usages, we found that `.o_kanban_card_manage_settings` always contains `div` elements with `col-*` classes as direct children. We also found that the border behavior depends on the available screen width rather than the bottom sheet itself: it is only needed when the elements are displayed side by side and should be removed when they are stacked vertically. An ´!important´ declaration was also added to compensate for the reduced selector specificity. 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#267979
This update fixes a previous limitation where channel owners without system admin privileges couldn't promote members to admin roles. The change ensures that channel owners can now correctly assign admin access, improving channel management capabilities. This resolves a technical issue impacting channel governance.
Original PR description
`canSetAdmin` was checking the target member role instead of the current user's role. Because of that, a channel owner who was not a system admin could not promote another member to admin. task-6250058 Forward-Port-Of: odoo/odoo#267999 Forward-Port-Of: odoo/odoo#266615
This update corrects an issue where decreasing line quantities in POS orders wasn't working reliably, particularly when using certification modules like Point of Sale. The change ensures that line decreases are accurately tracked and reflected in the order, preventing incorrect quantity calculations. This improves the overall POS order management experience.
Original PR description
This commit will affect all certification modules for the POS (pos_blackbox_be, l10n_se_pos, l10n_de_pos_res_cert) Inside the base `handleDecreaseLine` we match all the lines which have the same…
This commit will affect all certification modules for the POS (pos_blackbox_be, l10n_se_pos, l10n_de_pos_res_cert) Inside the base `handleDecreaseLine` we match all the lines which have the same product_id and compute the new quantity based on those. At the end we create a new line with the decreased quantity. This method is called when `disallowLineQuantityChange()` returns `false`, so when either of `pos_blackbox_be`, `l10n_se_pos` or `l10_de_pos_res_cert` are installed. The problem is that different combos will still have the same product_id and total_excluded_currency, so the `current_saved_quantity` adds the other unrelated combos together and tries to remove from the total of all the combos with the same parent. This commit will keep the decrease line for an order in the uiState. So instead of iterating over all the lines in the order and matching lines which have the same product_id we always keep track of the original line and the matching decrease line for that line. Task-[6173236](https://www.odoo.com/odoo/project/1737/tasks/6173236) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262744
This update fixes an inconsistency in the HTML editor's toolbar. Previously, the toolbar remained active when selecting text within protected blocks like Code or Table of Contents, leading to confusing behavior. Now, the toolbar automatically closes when selecting text within these blocks, ensuring a smoother and more intuitive editing experience.
Original PR description
Problem: The toolbar is disabled when selecting text inside Code or Table of Content blocks, but it remains active when selecting the block itself through the “⋮⋮” handle, leading to inconsistent behavior. Cause: `_updateToolbar` does not check whether `targetedNodes` contains only protected nodes. In such cases, the toolbar should be closed. Solution: When `targetedNodes` contains only protected nodes, prevent the toolbar from opening. Steps to reproduce: - Insert a Table of Content block. - Click on the “⋮⋮” handle while hovering the block. - Observe that the toolbar opens, while it should remain closed. task-6250028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266661
This update ensures that file uploads initiated through the link popover are immediately canceled when the user discards the popover. Previously, uploads continued in the background even after the discard button was pressed, leading to potential issues with data integrity. This change improves the user experience by preventing unexpected uploads.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Go to Todo, In the network tab switch to "Slow 4G" so that file upload can take few seconds to upload. - Upload a file using link popover. - While the file upload is in progress, hit the discard button of the link popover. - Notice that the upload continues in the background and when it completes successfully, link is inserted. **Desired behavior after PR is merged:** Discarding the link popover during file upload should cancel the upload request and prevent inserting the link. task-6199113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267695 Forward-Port-Of: odoo/odoo#263463
This update corrects a technical problem affecting how the `pdp_verification_display_state` field is calculated. The change replaces a problematic setting with a new method (`depends_context`) to ensure proper functionality within the partner merge wizard, preventing errors.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update resolves an issue where demo mode incorrectly required authentication and two-factor authentication (totp). It also corrects a technical error related to how documents were processed, ensuring proper handling regardless of whether the user is a Peppol User or a PDP. This enhancement improves the stability and usability of the demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267893 Forward-Port-Of: odoo/odoo#267461
This update corrects a flaw in how Odoo tracks device support status. Previously, changes weren't reliably reflected in the database when a device switched between supported and unsupported states. Now, device status changes are tracked separately, ensuring accurate database updates and preventing issues with device recognition.
Original PR description
When a device is marked unsupported (e.g. FDM after power outage) and becomes supported with the same identifier (e.g. FDM after the client restarts it after the power outage), the changed was not taken into account because we used to track changes in a set of supported + unsupported. We now track changes in supported and unsupported separately to make sure the db is informed of the changes. Forward-Port-Of: odoo/odoo#267967
This update corrects a problem where DHL shipping labels weren't using the correct template dimensions, resulting in labels printed in the wrong size (8x4 instead of 6x4). The fix maps the incorrect label template selection to the correct DHL API format, ensuring labels match the specified dimensions.
Original PR description
Issue ----- Labels generated with DHL do not respect the template (dimensions) set on the delivery method. Steps to reproduce ----- - Set up DHL - set label template as 6X4_A4_PDF - Create a delivery…
Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.
Steps to reproduce
-----
- Set up DHL
- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery
> The generated label is in 8x4 inch format instead of 6x4 full page
Explanation
-----
All info below was found in DHL's API doc from the following YAML file
https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml
There are 2 issues with the current implementation regarding the label format.
1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:
- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001
(values taken from the excerpt below)
```
templateName:
description: >-
Please enter DHL Express document template name.
<BR> Sample Transport label
templates:<BR> ECOM26_84_A4_001
<BR> ECOM26_84_001 - default<BR>
ECOM_TC_A4<BR> ECOM26_A6_002<BR>
ECOM26_84CI_001<BR> ECOM26_84CI_002 - supported
single customer barcode<BR> ECOM26_84CI_003 -
to be used if customer barcodes are used<BR>
ECOM_A4_RU_002<BR>
ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
[...]
type: string
maxLength: 25
example: ECOM26_84_001
```
[...]: additional info unrelated to labels (useful only for other `typeCode` values)
Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.
- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001
Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is 101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2
2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)
```
fitLabelsToA4:
description: >-
To print respective Transport Label and Waybill document into
A4 margin PDF.<BR> Note:
ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
template. <BR> This option is applicable only
for PDF encodingFormat selection.<BR> false:
Transport Label and Waybill document will use default margin
settings (default behavior) <BR> true:
Transport Label and Waybill document will print into A4 margin
PDF
type: boolean
example: false
```
-----
Ticket:
opw-6148713
Forward-Port-Of: odoo/enterprise#117281This fix resolves an issue where creating new survey records would sometimes fail due to an error in how the system handles empty lists. The code now guards against this scenario, ensuring data can be saved correctly. This prevents disruptions to the recruitment process.
Original PR description
To reproduce error. 1) make a new interview record 2) make sure user has interview group but not survey group 3) try to access/make an interview record. convert_to_cache returns none when it is…
To reproduce error.
1) make a new interview record
2) make sure user has interview group but not survey group 3) try to access/make an interview record.
convert_to_cache returns none when it is passed an empty list see link below:
https://github.com/odoo/odoo/blob/b16aaff17a65987c958c3285157ef1e4443e864f/odoo/orm/fields_misc.py#L71
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 279, in __call__
response = serve_db(request)
^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 443, in serve_db
raise _update_served_exception(request, exc)
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 441, in serve_db
return retrying(serve_func, env=request.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/router.py", line 593, in serve_ir_http
response = request.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/dispatcher.py", line 311, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/addons/base/models/ir_http.py", line 415, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/http/routing_map.py", line 207, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/service/model.py", line 55, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2084, in onchange
snapshot1 = RecordSnapshot(record, fields_spec)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2170, in __init__
self.fetch(name)
File "/home/odoo/src/odoo/saas-19.3/addons/web/models/models.py", line 2185, in fetch
self[field_name] = self.record[field_name]
~~~~~~~~~~~^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 6130, in __getitem__
return self._fields[key].__get__(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1815, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1986, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-19.3/addons/mail/models/mail_thread.py", line 502, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4340, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 82, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/addons/hr_recruitment_survey/models/survey_survey.py", line 19, in _compute_allowed_survey_types
survey.allowed_survey_types = [*survey.allowed_survey_types, 'recruitment']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool
```
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-prThis update fixes an issue where purchase bills were incorrectly created in the company's default currency, regardless of the original purchase order currency. Now, bills automatically inherit the currency of the purchase order, ensuring accurate financial reporting. This improves the reliability of our accounting processes.
Original PR description
**Steps to reproduce:** - create a storable product - confirm a PO in another currency than the main for this product - click on the "bill matching" smart button - select only the purchase order line from your PO - click on match **Current behavior:** this creates on Bill in the main currency **Expected behavior:** the currency should be inherited from the POL **Cause of the issue:** Inside action_match_lines() if there is no amls selected we call _action_create_bill_from_po_lines(). https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/purchase/models/purchase_bill_line_match.py#L157 Inside this method, there's currently no mechanism to take the currency from the POL when we create the bill. **fix:** If multiple different other currencies we take the main currency of the company opw-6131314 Forward-Port-Of: odoo/odoo#267090 Forward-Port-Of: odoo/odoo#266013
This update significantly speeds up the process of validating stock quantities within Odoo, a key function for managing inventory. The changes address inefficiencies in how stock quantities were checked, resulting in a dramatic reduction in processing time, especially for large datasets. This improves overall system performance and responsiveness.
Original PR description
Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`: * **Redundant updates** were performed…
Applying stock quants validation was performing poorly due to multiple bottlenecks in `Picking._check_entire_pack` and `StockMoveLine._apply_putaway_strategy`: * **Redundant updates** were performed on `location_dest_id` in the move lines and the package levels (which internally update all related move lines too), even when the location remained unchanged. * The main loop inside `_check_entire_pack` was **O(N^2)** time relative to the number of move lines due to internal filtering logic. * **Cache misses** triggered unnecessary SQL queries when retrieving `move_line_ids` from `package levels`, while they are already cached via the pickings and can be grouped by `package_level`. --- ### Benchmark Benchmark conducted on a customer database with **400k** `stock_move_line` records within **800** `pickings`, testing performance of the action `StockQuant.action_validate` with different sizes of move lines. Each test was run multiple times and shown is the average mean, all with negligible variance. | Metric | Before | After | Delta | | :--- | :--- | :--- | :--- | | **Benchmark (1k lines)** | 10.5s | 2.2s | -80% | | **Benchmark (5k lines)** | 121s | 8.5s | -93% | | **Benchmark (50k lines)** | 887s | 56s | -94% | | **Benchmark (400k lines)** | timeout | 777s | (within time limit) | **OPW-6045513** Forward-Port-Of: odoo/odoo#262717 Forward-Port-Of: odoo/odoo#257829
This update fixes a previous issue where purchase order information was missing from vendor credit notes (in_refund). Now, users can easily see which purchase order each credit note line is associated with, improving accuracy and streamlining the credit note process. This ensures consistent reporting and simplifies reconciliation.
Original PR description
The purchase_order_id column in invoice lines was hidden for vendor credit notes (in_refund), while it was visible for vendor invoices (in_invoice). This prevented users from identifying which purchase order each line belonged to when a credit note was linked to one or more POs. Include 'in_refund' in the column_invisible condition so the purchase order column is also available on vendor credit note lines. 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#267316
This update resolves an issue where currency amounts in Arabic RTL (right-to-left) user interfaces were incorrectly displayed with the minus sign appearing to the right of the currency symbol. The fix ensures that currency amounts are consistently formatted left-to-right, improving readability and accuracy for users in Arabic-speaking regions. This ensures financial data is presented correctly for all users.
Original PR description
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the…
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount 4. Switch the user language to Arabic 5. Open the Accounting dashboard Issue The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252 opw-6183749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267812 Forward-Port-Of: odoo/odoo#266742
This update corrects a technical issue where message authors were sometimes incorrectly identified. The fix ensures that message authors are accurately linked to either partners or guests based on the message's model, improving the reliability of communication tracking. This resolves a potential inconsistency in how message authorship is recorded.
Original PR description
A message's author is identified by one of two fields depending on its model: `author_id` (for partners) or `author_guest_id` (for guests). Previously in `changeThread`, the value of `thread.effectiveSelf` (which can be either a Partner or a Guest) was provided as the `author_id` regardless of its actual model. This commit explicitly uses `store.self_partner` as the `author_id` and `store.self_guest` as the `author_guest_id` to resolve the occasional mismatch. Forward-Port-Of: odoo/odoo#267828 Forward-Port-Of: odoo/odoo#267464
This update resolves an issue where a misleading error was triggered when setting intrastat codes on product templates. The fix ensures the error only appears when creating templates with dynamic attributes and no variants, aligning with how intrastat codes are correctly stored on product variants. This improves data accuracy and prevents unnecessary alerts.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update fixes an issue where SII invoices generated with quarterly tax periods were incorrectly using monthly formats. The change ensures that generated JSON documents accurately reflect the company's chosen quarterly periodicity, aligning with Spanish tax regulations. This improves data accuracy for tax reporting.
Original PR description
### Issue: When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format According to the documentation, the options for Periodo include…
### Issue: When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225): https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf ### Cause: The invoice JSON generation does not consider the company's `tax_periodicity` This logic was probably omitted because `account_reports` may not be installed However, when the periodicity is configured, the generated SII document should reflect it correctly ### Steps to reproduce: - Install `l10n_es_edi_sii` and `account_reports` - In Settings, set `Tax Periodicity` to `Quarterly` - In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española` - Change ES Company vat number to `ESA12345674` - Create an invoice (Date: 01/05/2026, Customer: ES Company) - Open the generated JSON document - Check the Periodo value, it should be 2T in May opw-6050587 Forward-Port-Of: odoo/odoo#267708 Forward-Port-Of: odoo/odoo#264063
This update fixes an issue where broken link trackers were appearing in the system. The changes now require valid alphanumeric codes for link trackers and disable editing the target link after creation, preventing further problems and ensuring data integrity.
Original PR description
1. Remove the possibility to create link tracker with an empty code. Empty code tracker do not work, but still appear in the tracker list. Only accept alphanumerical chars in the tracker code. 2. Set the target link input as disabled after generating the tracker, since editing the target link at this point would have no impact. task-4531974 Forward-Port-Of: odoo/odoo#266733
This update resolves an issue where Odoo would crash when a customer canceled a Redsys payment and returned to the system. Previously, the system didn't properly handle missing payment information, leading to errors. Now, Odoo gracefully manages payment cancellations, ensuring a smoother customer experience.
Original PR description
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer…
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer cancels the payment from the Redsys checkout page, Redsys redirects back to Odoo without the `Ds_MerchantParameters` parameter. The payment flow assumes the parameter is always present and tries to decode it unconditionally, causing an internal server error. Desired behavior after PR is merged: Odoo gracefully handles payment cancellations when `Ds_MerchantParameters` is missing from the callback parameters. The customer is redirected correctly without triggering a server error. Steps to reproduce: 1. Install the Redsys payment provider. 2. Configure a test environment. 3. Create a sales order or invoice. 4. Start the payment process. 5. Cancel the payment from the Redsys checkout page. 6. Return to Odoo. 7. Observe the internal server error caused by the missing `Ds_MerchantParameters` parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265655
This update resolves an issue where PDF documents received via email were incorrectly displayed with a duplicate iframe preview. The fix ensures that the document preview accurately shows the PDF content, addressing a potential confusion for users. This was previously addressed in 19.0 and is now reinforced.
Original PR description
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the…
**Steps to reproduce:** - Install documents_account - Set up alias to catch incoming mails - Receive a mail with xml attachement which can be previewed as pdf - Go to Documents app - Click on the document preview - Preview is split in two iframes, both with the same content (pdf) **Issue:** Due to the `isPdf` patch the attachment can match multiple types for the preview (pdf and text) as both getter return `true`. ``` <iframe t-if="state.file.isPdf" ... <iframe t-if="state.file.isText" ... ``` It also seems that xml received by mail are imported as text, which is why the issue doesn't happen when manually uploading the same xml file. **Fix:** Ensure that if the document is matching `isPdf`, it doesn't trigger the second iframe with `isText`. Also it seems fixed in 19.0 as the text iframe is replaced by this xpath: `<xpath expr="//iframe[@t-if='state.file.isText']" position="replace">` which was added for https://github.com/odoo/enterprise/commit/de614ee5e9a087d49939c65c0118ae6164c7b31b related patch: https://github.com/odoo/enterprise/commit/ffcdd2275c8bf564e15151ccbcaf3965ed968450 opw-6018536 Forward-Port-Of: odoo/enterprise#118863 Forward-Port-Of: odoo/enterprise#112041
A recent change unintentionally caused all expense lines to be incorrectly reconciled with Stripe transactions. This fix restores the proper filtering of expense lines during reconciliation, ensuring accurate tracking of payments and preventing over-reconciliation. This resolves a disruption in expense reporting and financial accuracy.
Original PR description
In 1f6f4ee3, the account reconciliation filtering was removed from the automatic reconciliation. This broke the reconciliation as all lines would be taken into the reconciliation after-hand Steps to reproduce: - Install `hr_expense_stripe_demo` - Create a Stripe account in the settings - Refresh the account status until validated - Top-up the account in the accounting dashboard - Create a virtual card and activate it - Simulate a transaction with capture - Submit the expense created after checking it has at least one tax - Approve and post the expense - Check the reconciled transaction in the stripe journal - All the lines of the expense move have been reconciled
This update fixes an issue where tracking information in emails was displayed in the wrong order. The change reverses the order of tracking values to match how they are stored in the database, ensuring that the most important tracking details are shown first. This improves the clarity and accuracy of email notifications.
Original PR description
Tracking values are given in a reverse ordering, as DB model reads them by id DESC. Most important one is given last, see 'mail_tracking' module. We therefore have to reverse the list given to the QWeb template.
This update addresses a potential issue with how Odoo updates modules, specifically related to button actions. By adding a short timeout and a rollback mechanism, the system is now more reliable when updating modules and handling user error translations, ensuring a smoother experience for users.
Original PR description
Add a small lock timeout when updating modules just like it is done in master (19.3). Also add rollback so that translation of user errors work (in case we need to fetch the language from the database). runbot-234930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267698
This update corrects a technical problem that was only appearing in the community version of Odoo's stock module. The issue involved incorrect links to stock packages, which has now been resolved. This ensures accurate stock tracking and reporting.
Original PR description
Reproducible only in community **Observation** outermost_result_package_id is a enterprise variable in stock_barcode: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L27 It's computed from result_package_id.outermost_package_id: https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/models/stock_move_line.py#L29-L33 That variable is available in stock community : https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/stock/models/stock_package.py#L48 runbot-241085 Forward-Port-Of: odoo/odoo#267653
This update disables the '@' mention feature for visitors in live chat conversations. Previously, visitors could trigger irrelevant suggestions, creating unnecessary noise. This change ensures a cleaner and more focused chat experience for all users.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267788 Forward-Port-Of: odoo/odoo#253551
This update corrects a reporting error that caused combo products to incorrectly appear in the 'Invoiced Not Delivered' report even after items were fully delivered. The fix accurately reflects the actual delivery status of combo items, ensuring accurate reporting and avoiding duplicate information.
Original PR description
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps…
**Problem:** A combo product's parent line appears in the "Invoiced Not Delivered" report (Accounting > Review) and stays there permanently, even after all of its combo items are delivered. **Steps to reproduce:** 1. Create a combo product bundling two storable items. 2. Sell the combo on a sale order, confirm and invoice it. 3. Deliver every combo item. 4. Open Accounting > Review > Invoiced Not Delivered. **Current behavior:** The combo parent line is listed. While items are partially delivered, both the parent and the items are listed, duplicating the same information. **Expected behavior:** The combo parent is not listed; only the combo item lines, which carry the real delivery state, appear when they are genuinely not delivered. **Cause of the issue:** A combo parent is a virtual sale order line with no stock move of its own, so its delivered quantity is never advanced and always reads 0. The accrual report selects lines where `qty_invoiced_at_date > qty_delivered_at_date`, so the parent (which does receive an invoiced quantity from the combo logic) matches forever. **Fix:** Combo parents carry no delivery information of their own, so excluding them from the accrual search domain is more accurate than inventing a delivered quantity for them. Their combo item lines already represent the real delivery state, so the report stays correct. opw-6215110 Forward-Port-Of: odoo/enterprise#118942
A recent test within the HR Holidays module was failing due to an error in how it checked for related records. This commit corrected the test by using a different method to identify records, preventing installation issues when other modules are installed alongside HR Holidays. This ensures smoother module installations and prevents potential disruptions.
Original PR description
Before this commit, the line https://github.com/odoo/odoo/blob/saas-19.1/addons/hr_holidays/tests/test_holidays_mail.py#L69 used `.id` on a many to many recordset which failed when the recordset had multiple records. This test led to an error when installing other modules with demo data like `test_l10n_be_hr_payroll_account` and the test was run with demo data. This commit uses the `in` operator instead of `==` and avoids `employee_ids.id` to avoid the error. Runbot error: https://runbot.odoo.com/odoo/error/241106 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266677
This update fixes a visual issue where Polish and Vietnamese characters displayed inconsistently on Android Edge browsers. The fix ensures proper font rendering by providing additional font subsets to browsers that don't fully support Unicode ranges, maintaining consistent character appearance across different devices and browsers.
Original PR description
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and…
Scenario: - paste "język việt" (polish + vietnamese) in a page - change website font to not be "Noto Sans", for example: Raleway - open the page on Edge Browser on Android Result: polish and vietnamese characters are using different font and are visually different than latin character. Cause: google fonts is serving for nearly all browsers font configuration with woff2 files and unicode-range so the user only loads the part of the font that will be used on the website. For Edge browser on android, based on the user-agent chrome is serving only a TTF file without unicode-range because it is thinking that unicode-range is not supported. These files only contain basic latin characters, so extended latin and vietnamese characters are being rendered with fallback "Odoo Unicode Support Noto" that has a different weight and style for the same weight. Fix: For the browser not supporting unicode-range (desktop edge before 2020, Edge on android, …), in addition to latin we ask google fonts to provide([1]) latin-extended and vietnamese subsets in TTF/WOFF files if available. For other subset (hebrew, arabic, cyrillic, …) the intent is to fallback on "Odoo Unicode Support Noto" since they should usually not be mixed with latin characters. Note: Edge on android in reality support unicode range, so this would be solved if google fonts just served the unicode range font configuration for that user-agent. [1]: https://developers.google.com/fonts/docs/getting_started#specifying_script_subsets opw-4642242 Forward-Port-Of: odoo/odoo#267798
This update resolves an issue where unbalanced accounting moves within Point of Sale sessions were silently ignored. The system now automatically opens the balancing wizard when an imbalance is detected, ensuring users are alerted and can correct the transaction. This prevents potential financial discrepancies and improves the reliability of POS operations.
Original PR description
`_process_session_validation` rolls back the transaction and returns the `pos.close.session.wizard` action when it detects an unbalanced account move. However, `_validate_session` was discarding that return value, causing execution silently ignore the imbalance without prompting the user. opw-6238945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing the Cashmatic payment system from working correctly on self-order kiosks. The change ensures the necessary JavaScript files are loaded, enabling seamless payment processing in this key kiosk environment. This improves the overall customer experience.
Original PR description
This commit adds the cashmatic JS files to the correct asset bundle so that it loads correctly in the self order kiosk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing the unsubscribe dialog on the website from functioning correctly. The change was initially intended to update for a new software version, but a key step was missed, causing a technical error. This fix ensures the unsubscribe dialog is properly displayed and operational.
Original PR description
This commit 974e0066f8c56aad831de97a581e56b95ba53dc6, introduced a bug by adding 'this' to templates in preparation for owl 3. But it omitted this inherited template making the xpath invalid. Task-6276225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the website's performance by replacing a complex selector with a simpler one. This change reduces the time it takes for the website to recalculate styles, particularly when viewing large tables or resizing the browser window, leading to a faster and more responsive user experience.
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 Forward-Port-Of: odoo/odoo#268106 Forward-Port-Of: odoo/odoo#267969
This update resolves an issue where stock move descriptions were incorrectly displaying HTML content due to a fallback mechanism. The change removes this fallback, using the product's display name instead, and standardizes the handling of descriptions across different picking creation methods. This ensures consistent and accurate stock move descriptions.
Original PR description
Currently, if there's no receipt/delivery/internal description, a move description will use a product internal note as a fallback. The issue is that this is an html field and it doesn't show its…
Currently, if there's no receipt/delivery/internal description, a move description will use a product internal note as a fallback. The issue is that this is an html field and it doesn't show its content correctly. This PR aims to remove this fallback. If no description is found, then it proposes to use the display_name of the product, which is later ignored in `stock_move_product_label.js` anyway. Second, if a picking is created manually, the description_picking is in the vals, which triggers `_inverse_description_picking`. This is different if the picking is created by a SO, PO, MO, etc. We're unifying the behavior by making sure to remove `description_picking` from the create vals. However once a move is done, the description should be immutable. So we're also adding a call to `moves_todo._inverse_description_picking` to for a write on `description_picking_manual` when marking a move as done. task 6131699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where multi-company orders were incorrectly assigning fiscal positions, leading to payment failures. The fix ensures the sale order's company is used when calculating the fiscal position, guaranteeing accurate accounting and order confirmation. This improves order processing reliability in our multi-company setup.
Original PR description
Issue: --- Due to this issue, in multi-company environment, wrong fiscal position might be assigned to the order, leading to `incompatible companies` error. Steps to reproduce: 1- On multi-company…
Issue: --- Due to this issue, in multi-company environment, wrong fiscal position might be assigned to the order, leading to `incompatible companies` error. Steps to reproduce: 1- On multi-company setup, assign a website to the second company. 2- Configure pickup method for second company. 3- Configure fiscal positions for both companies. 4- Setup auto invoice for second company. 5- Using public user, add a product to cart and checkout. 6- Use pickup method, and pay. The order is not confirmed. If you enable debug mode after payment, it will show an `incompatible companies` error. Cause: --- https://github.com/odoo/odoo/blob/43f5ceadbc1f7df9898c327bf65bffdbe9860c1c/addons/account/models/partner.py#L247-L279 `_get_fiscal_position` is using environment company to compute the fiscal position. However, `_compute_fiscal_position_id` causing the issue here is triggered inside `report_saleorder` template with user set as odoobot when trying to to send the confirmation. As a result, the odoobot company's fiscal position will be used causing this issue. Fix: --- We should ensure company from sale order is used by setting it as env company. opw-6186296 Forward-Port-Of: odoo/odoo#264123
This update introduces a new keyboard shortcut (ALT + SHIFT + R) to quickly open the timesheet systray. This simplifies the process for employees to record their time, improving efficiency and usability. This change was implemented as a bug fix.
Original PR description
This commit adds an `ALT + SHIFT + R` shortcut to open the timesheet systray. task-6197777 Forward-Port-Of: odoo/enterprise#116753
This update resolves an issue where negative line items in the Mexican CFDI tax calculation were incorrectly distributed. The change addresses a recent update that introduced new line item types, making the previous method for detecting negative lines obsolete. This ensures accurate CFDI reporting for Mexican businesses.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119327 Forward-Port-Of: odoo/enterprise#119254
This update fixes a calculation error in the Canadian Profit and Loss report. Previously, operating expenses were incorrectly added to gross profit, leading to inaccurate Net Operating Income figures. This change ensures the report accurately reflects the difference between gross profit and operating expenses, providing reliable financial reporting for Canadian users.
Original PR description
Steps to reproduce: 1. Install the Accounting app with the Canadian localization (l10n_ca) 2. Open the Profit and Loss report 3. Review the Net Operating Income line Issue: The Net Operating Income value is incorrectly calculated; operating expenses are being added to gross profit instead of subtracted, producing an incorrect result. Expected behavior: Net Operating Income should equal Gross Profit - Operating Expenses opw-6265192
This update resolves a critical issue that caused OOM crashes when generating the Swedish SIE 4 report with large datasets. By optimizing the database query and using efficient data processing techniques, the report now runs significantly faster and uses less memory, ensuring reliable export capabilities.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#118849 Forward-Port-Of: odoo/enterprise#113227
This update resolves a technical issue that could cause errors when managing floor screens in the restaurant POS system. The change prevents users from creating duplicate configurations, which avoids a system error and ensures stable POS operation. This improves the reliability of the restaurant ordering process.
Original PR description
Duplicating a floor screen causes a duplicated key exception when rendering the POS. To avoid this issue, duplication on the backend is not allowed. task-6246748 Forward-Port-Of: odoo/odoo#266734
This update ensures that the subject displayed in the chatter reflects any changes made to the message subject within the composer. Previously, updates in the composer weren't immediately visible in the chatter, leading to potential confusion. This improvement provides a more accurate and up-to-date view of message subjects for all users.
Original PR description
If the user updates the subject in the composer, the suggested subject in the chatter should reflect the latest message. task-5944635 Forward-Port-Of: odoo/odoo#267140
This update resolves an issue where the Odoo upgrade process would fail if it attempted to change the status of accounts with partially reconciled transactions. The fix ensures that the system doesn't modify account reconciliation flags during the upgrade, preventing errors and maintaining data integrity.
Original PR description
<h2>Context</h2> Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized…
<h2>Context</h2>
Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.
When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed, it tries to update the CoA by adding/updating accounts, using the accounts in the file `l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.
<h2>Problem</h2>
Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which tries to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled from True to False during the update of the CoA, while it still contains partially reconciled transactions.
<details>
<summary>Traceback</summary>
```
File "/home/odoo/src/odoo/19.0/addons/l10n_pl/migrations/2.1/end-migrate.py", line 8, in migrate
Template._load_data({'account.account': Template._get_account_account('pl')})
File "/tmp/tmpm8z3nlb0/migrations/account/0.0.0/pre-ensure-deferred-accounts.py", line 36, in _load_data
return super()._load_data(data, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 697, in _load_data
created_records[model] = self.with_context(lang='en_US').env[model]._load_records(all_records_vals)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5171, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1122, in _load_records_write
super()._load_records_write(values)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5092, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 1045, in write
self.filtered(lambda r: r.reconcile)._toggle_reconcile_to_false()
File "/home/odoo/src/odoo/19.0/addons/account/models/account_account.py", line 975, in _toggle_reconcile_to_false
raise UserError(_('You cannot switch an account to prevent the reconciliation '
odoo.exceptions.UserError: You cannot switch an account to prevent the reconciliation if some partial reconciliations are still pending.
```
</details>
<h2>Solution</h2>
I have sanitized the dict `data` using the `_pre_reload_data` method, so that the traceback does not appear anymore when upgrading.
<h3>Notes</h3>
`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257006Features or functions removed from Odoo
This update simplifies the Point of Sale system by removing a QR code print option that was only relevant for a specific self-ordering restaurant setup. This change streamlines the configuration and improves the overall user experience. The removal also eliminated a redundant link within the Point of Sale module description.
Original PR description
In this commit, --- - pos_self_order: removed the QR code print option from the pos config list view, as printing QR codes is only relevant for restaurants with self-order enabled and is already available in the configuration settings. - point_of_sale: removed the anchor tag from the Point of Sale module description, since the module header already provides the link. task-6222663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265472