Daily updates from Odoo
Thursday, June 4, 2026
139 changes
11 changes
Resolved issues and error corrections
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
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 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 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 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
8 changes
Resolved issues and error corrections
This update fixes an issue where a recurring activity was being unnecessarily recreated after being marked as 'done'. By adding a check to ensure the activity hasn't already been completed, we prevent redundant tasks and improve the efficiency of our fleet management system. This ensures accurate scheduling and reduces potential errors.
Original PR description
When a next activity is set to done, the record is archived. So once the next activity set on the contract is set to done, the cron will re-create it the next day as it won't see it. So we add active_test=False, to be sure that one has not already been set to done --- 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 users are interacting with large tables or resizing the window. Ultimately, this results in 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 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 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 fixes a translation issue in Odoo's Argentine localization module (l10n_ar) that caused confusion regarding fiscal position names. The translations now accurately reflect the purpose of each position, eliminating duplicates and ensuring domestic positions are correctly labeled.
Original PR description
### Description of the issue/feature this PR addresses: Fix fiscal position spanish translation to match with its real purpose. ### Current behavior before PR: * We have a fiscal position name that does not match with its purpose: Represent the local operations inside argentina (country: Argentina) but the name is " Purchases / Sales abroad" * Two fiscal positions have the same translation value and this is confusing ### Desired behavior after PR is merged: * we do not have duplicated fiscal position anymore * Domestic fiscal position is taged with the correct name --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: https://github.com/odoo/odoo/pull/248462
The visual appearance of the portal chatter message delete dialog has been corrected. This change addressed a styling issue caused by a recent update and ensures the dialog displays correctly for all users. It includes necessary styles for message content formatting, improving the user experience.
Original PR description
The delete message dialog in the portal chatter has been visually broken since #247708, which replaced the generic `MessageConfirmDialog` (size="xl") with a dedicated `MessageDeleteDialog` (size="md"). The md size triggers the `o_modal_design_minimal` design path in `dialog.js`, whose styles are defined in `dialog.scss`. Additionally, message content may contain html_editor-formatted elements (blockquote in thi scase) whose styles come from `html_editor.assets_editor`. Neither was included in `portal.assets_chatter_style`. This change adds those missing styles to the portal chatter shadow DOM. **Before:** <img width="637" height="290" alt="image" src="https://github.com/user-attachments/assets/2dae0e72-383d-4277-94e7-ef23a01ea53b" /> **After:** <img width="637" height="317" alt="image" src="https://github.com/user-attachments/assets/ca36bc51-3cc9-43c6-bcf2-30c03498353c" />
This update fixes a translation error in the Argentine fiscal position settings, ensuring the names accurately reflect their purpose. Previously, a confusing duplication of fiscal positions existed, now all domestic positions are correctly labeled, streamlining accounting processes for Argentina.
Original PR description
### Description of the issue/feature this PR addresses: Fix fiscal position spanish translation to match with its real purpose. ### Current behavior before PR: * We have a fiscal position name that does not match with its purpose: Represent the local operations inside argentina (country: Argentina) but the name is " Purchases / Sales abroad" * Two fiscal positions have the same translation value and this is confusing ### Desired behavior after PR is merged: * we do not have duplicated fiscal position anymore * Domestic fiscal position is taged with the correct name --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248462
This update resolves a technical issue within the Odoo POS Restaurant module that could cause errors during screen rendering. The change prevents users from duplicating floor screens on the backend, eliminating a potential system crash and ensuring stable POS operations. This improves the reliability of the restaurant ordering system.
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 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 the account's reconciliation flag remains unchanged 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#2570064 changes
Resolved issues and error corrections
This update corrects a technical issue preventing invoices with long product names, descriptions, or notes from being correctly processed for Romanian E-Factura submissions. The system now enforces character limits (100, 200, and 300 characters respectively) to ensure compliance with Romanian regulations. This resolves rejection errors and allows for proper E-Factura generation.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name…
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian localization (e.g. RO Company) - Configure Romanian E-Factura - Create an invoice with a product having a name longer than 100 chars - Confirm the invoice - Send E-Factura to SPV - Fetch E-Factura status **Issue:** The invoice is rejected with the following error: "[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100." **Similar issue with the product description:** "[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200." **Similar issue with the note (i.e. Terms and Conditions):** "[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300." **Solution:** Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300. opw-5964904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267850 Forward-Port-Of: odoo/odoo#265811
This update fixes a visual issue where Polish and Vietnamese characters appeared differently on Android Edge browsers due to font rendering differences. The fix ensures consistent character display across browsers by providing additional font subsets for older Edge versions that don't support Unicode ranges. This improves the user experience for international content.
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 the Timesheet Assistant wouldn't function correctly when rules were created without a specified template. The fix ensures that all rules require a template, allowing the assistant to accurately build display names for key events. This improves the reliability of the timesheet tracking process.
Original PR description
## [FIX] timesheet_grid: make template field required in AW rule Before this commit, the template field in AW rule was not required and if one rule without any template is set, timesheet assistant will not be able to work correctly to build the display name for the key events found. This commit makes sure the template field is required. ## [FIX] timesheet_grid: ignore rules without template defined Before this commit, when the user creates a rule without any template set, the timesheet assistant will no longer work because it assumes the template is required. This commit adds a condition in the domain when we fetch all AW rules, to ignore the ones without template set.
This update resolves an issue where credit notes couldn't be created if the system encountered an archived bank account. The fix ensures that the system explicitly checks for inactive bank accounts during credit note creation, preventing validation errors and allowing invoices to be confirmed. This improves the reliability of credit note processing.
Original PR description
When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it…
When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message: > The recipient bank account linked to this invoice is archived. So you cannot confirm the invoice. The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team: > In practice, a compute method cannot expect active_test to have > a particular value. It may be invoked with any context. There is no > "context purge" done by the ORM. The computation may be "prepared" > with a context (the one of modified()) and actually done with another > context (code accessing the field before some explicit flush). In > other words, if the compute method searches for a record that matches > some conditions, and if that record cannot be inactive, then this > condition must be explicit in the search domain (or in the context). opw-6229286 Forward-Port-Of: odoo/odoo#267398
3 changes
Resolved issues and error corrections
This update resolves two key issues related to HR document attachments. Previously, attachments were created in the root employee folder, which was inconvenient. Now, attachments are correctly created within the appropriate HR document folders for leave and contracts. This ensures attachments are organized and easily accessible.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals would cause an error. The change ensures the system validates that the number is numeric before attempting to convert it, preventing the error and allowing users to correctly set check numbers.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
This update resolves a problem where users accessing archived documents through certain methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly accessed and displayed, improving the user experience. It's a follow-up to previous related tasks.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488 Forward-Port-Of: odoo/enterprise#119188 Forward-Port-Of: odoo/enterprise#117229
1 change
Resolved issues and error corrections
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used for identifier values, improving the accuracy and clarity of the exported data. This enhances the reliability of the ICP reporting process.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119152 Forward-Port-Of: odoo/enterprise#112995
2 changes
Enhancements to existing features
This update enhances the employee avatar card by displaying key payroll information – wage, pay frequency, and employment category – directly within the popup. This provides users with a quick overview of an employee's payroll details. The changes are restricted to users with specific payroll access permissions.
Original PR description
Show wage (with currency and pay frequency), employment category, and seniority in the footer of the employee avatar card popup. The section is only sent to and rendered for users with `hr_payroll.group_hr_payroll_user` access. task-6117982
Resolved issues and error corrections
This update resolves an issue where the Executive Summary report would fail when the date range option was disabled. The fix ensures the report uses the fiscal year's start date instead, preventing a calculation error and ensuring the report always displays correctly. This improves the report's reliability for users.
Original PR description
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab,…
## Steps to Reproduce: 1. Install the Accounting module. 2. Go to Accounting > Reporting > Executive Summary. 3. Activate debug mode. 4. Click on the gear icon at the top. 5. In the "Options" tab, disable the "Date Range". 6. Open the report again. ## Error: `TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'` ## Cause: At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported. ## Fix: This commit takes the fiscal-year's start date, when the date-range feature is disabled. [1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570 [2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16 sentry-7455506965 Forward-Port-Of: odoo/enterprise#119162 Forward-Port-Of: odoo/enterprise#116888
3 changes
Resolved issues and error corrections
A recent test failure in the website rental product functionality was caused by inconsistent timezone settings. This update has standardized all timezone data to UTC within the test environment, resolving the issue and ensuring reliable test results. This ensures accurate product display and functionality for rental products.
Original PR description
The test_add_accessory_rental_product test failed on the runbot due to a timezone ambiguity where two of them were used. I changed the website timezone to UTC in the test data definition to uniform them. Runbot error: 233282
This update corrects a display problem on the POS Kanban view for businesses not using the 'blackbox' configuration. The update now correctly retrieves session information from the POS session model, ensuring accurate version badges and session details are shown. This improves the user experience and data accuracy for standard POS setups.
Original PR description
- Hide the FDM version badge on the POS kanban view for non blackbox config - Read `bookingPeriodId` and `bookingDate` from the frontend `pos.session` model instead of the computed `current_session_id` backend field on `pos.config`.
This update fixes an issue where the tag container overlapped with the header in the sign module due to longer translated strings. The changes automatically adjust the container's position and reduce its height to ensure a clean layout across different languages and content lengths. This improves the user experience and visual consistency.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" />
4 changes
New functionality added to Odoo
This update expands Odoo's SII (Societat Impostaria Informàtica) functionality to include support for the Hacienda Foral de Navarra tax agency. It addresses a specific requirement for Navarra businesses to use a different endpoint and XML namespace declarations when submitting invoices, ensuring compliance with local regulations. This addition allows companies to accurately report SII data to the Navarra tax authority.
Original PR description
The Hacienda Foral de Navarra uses the same SII XML format as AEAT but sends invoices to a different endpoint. Additionally, Navarra requires explicit XML namespace declarations in the SOAP envelope header, which the standard zeep serializer does not include by default. This adds the Navarra tax agency as a new option in the company SII configuration, defines its production and test endpoints, and injects the required namespaces in the request header when the Navarra agency is selected. task-5946583 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a potential error in the PDP reporting flows that could occur when new or incomplete flow records are created. The fix ensures the system handles missing due dates gracefully, preventing crashes during form creation. This improves the stability and reliability of the reporting process.
Original PR description
PDP reporting flows compute their period status from the due period dates. On a new or incomplete flow record, those dates can still be empty during form/onchange initialization. The compute then tried to compare today's date with `False`, which could crash generic form creation. This patch makes the compute handle missing period dates before doing date comparisons. runbot.build.error-939459
This update resolves an issue where users were prevented from uploading documents to requests linked to records they didn't have full access to. By adding a '.sudo()' function during the attachment creation process, users can now upload documents regardless of their specific access rights, improving workflow efficiency.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099
This update corrects a previous issue where website orders automatically generated CFDI invoices, which was unnecessary and potentially problematic. Now, invoices are only created for website orders when the customer provides all required information, aligning with standard e-commerce practices. This ensures a smoother and more accurate order process.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#116061
3 changes
Resolved issues and error corrections
This update resolves an issue where excessively long addresses in payment fields caused errors during Authorize.net transactions. The system now automatically truncates address information to comply with the Authorize.net API's length restrictions, ensuring smooth and reliable payment processing. This change improves data integrity and prevents payment failures.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
This update resolves an issue where invoices with zero amounts and untrusted partner bank accounts would fail to process. The fix ensures the correct bank account is selected based on the order amount (negative for refunds, positive for regular invoices), improving the reliability of zero-amount transactions. This prevents errors and ensures proper invoicing functionality.
Original PR description
**Steps to reproduce:** - In the contact app, chose your company - Go to the Accounting tab - Create a bank account and check "Send Money" - Create a partner, create a bank account for it - Do not…
**Steps to reproduce:** - In the contact app, chose your company - Go to the Accounting tab - Create a bank account and check "Send Money" - Create a partner, create a bank account for it - Do not Check the "Send Money" - Go to the POS, click on a product and refund it 100% to make the price 0 - Chose the partner we created as the client and ask for an invoice - Try to pay, the account is not trusted **Why the fix:** With this same steps, if we make a normal order with a price different than zero, it will work. But if the price is negative, we will get the same error. This happens because the *partner_bank_id* is chosen depending on if this is a refund or not. With an amount of zero, the order is considered to be a refund, and we chose the partner's partner_bank_id, which is not trusted. On a normal positive flow, we chose the company's which is trusted, so we can send the money and it works. This does not make sense to assume a zero amounted order is a refund, because when we invoice something that is zero or greater, we get an invoice, but only for the *partner_bank_id* we chose it as if it was a credit note. So we should take the partner's *partner_bank_id* for every order that has a strictly negative amount, and take the company's for every order that is zero or positive. Another way to fix this would be to backport this commit that also resolves this issue starting in 18.0 by adding a fallback to the company's *partner_bank_id*, but it might be a bit much of a change for version 17.0 https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 opw-6005384
This update resolves an issue where the 'Fill' option on the /shop page's product image editor wasn't functioning as expected. The fix ensures that product thumbnails now correctly adjust their fill mode (cover or contain) based on the toggle selection, improving the visual presentation of products.
Original PR description
**Problem:** On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails. **Steps to…
**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.
**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.
**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.
**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`
**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.
**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.
opw-6231432