Daily updates from Odoo
Tuesday, February 24, 2026
60 changes · saas-19.2
Resolved issues and error corrections
This update ensures internal users accessing message links within slides are consistently directed to the backend form view, aligning with other portal documents. Previously, internal users were incorrectly redirected to the website page. This change maintains a unified user experience across all portal users.
Original PR description
Since #202555, a message link in slides redirects internal users to the website page if it's published. To ensure consistency with other documents in the portal, this commit redirects internal users to the backend form view of the slides. Portal and public users continue to be redirected to the published website page. Forward-Port-Of: odoo/odoo#249720
This update fixes a problem where the earliest contract start date for employees wasn't consistently tracked. Now, the system automatically updates this key field whenever a new contract is created or an existing contract's start date changes, guaranteeing accurate historical data for payroll and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#107971
Forward-Port-Of: odoo/enterprise#102198This update resolves an issue where consolidated invoices were incorrectly linking orders due to a bug in how the system processed POS orders. The fix ensures that all orders associated with a consolidated invoice are accurately reflected, improving invoice accuracy and reporting. This change was made to enhance the reliability of our invoicing process.
Original PR description
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order *…
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order * Close POS 1 POS 2: * 1 uninvoiced order * 1 invoiced order * Close POS 2 Reopen POS 1: * 1 uninvoiced order * Close POS 1 Reopen POS 2: * 1 uninvoiced order Close POS 2 * Go to Orders → Consolidated Invoice * Create a consolidated invoice using the correct date range Observation: * Two documents are created * No. of orders linked to each document are incorrect Cause: * `_split_pos_orders_in_lines` overwrites entries in the `lines_per_config` dictionary * Previous orders for the same config are lost Fix: * Extend the existing recordset in `lines_per_config` instead of overwriting it Before <img width="1230" height="231" alt="order consolidation bug" src="https://github.com/user-attachments/assets/26657f34-998e-41c4-a68a-0939cbe6de1d" /> After <img width="1265" height="206" alt="consolidated order fixed" src="https://github.com/user-attachments/assets/7c703416-ac3b-412e-bb28-0d6f73fa25f2" /> opw-5904420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248402
This update fixes an issue where work entries created from attendance archives were incorrectly including existing entries on the same day, leading to inaccurate work duration reporting. The change ensures that work entries accurately reflect the correct duration for each date, resolving a potential discrepancy in time tracking.
Original PR description
Current behavior: work entries created from attendance archive "included" existing work entries on the same day, even when they do not overlap in time frame. This happens because the attendance intervals are created from records in self, not all attendances on a given day Expected behavior: work entries should reflect the correct duration for a date. opw-5499002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#107704
This update fixes a problem that occurred after installing the l10n_lu_hr_payroll module. The 'Payroll: Update data' cron job was failing due to a missing file. The issue was resolved by removing the outdated file reference, ensuring the cron job now runs correctly.
Original PR description
When the ``Payroll: Update data`` cron is executed after installing the ``l10n_lu_hr_payroll`` module, a traceback is raised. Steps to reproduce the error: - Install ``l10n_lu_hr_payroll`` module - Run the ``Payroll: Update data`` cron Traceback: ```py FileNotFoundError: [Errno 2] No such file or directory: '/home/odoo/src/enterprise/saas-19.1/l10n_lu_hr_payroll/data/hr_payslip_input_type_data.xml' ``` In commit [1], ``hr_payslip_input_type_data.xml`` file was removed. However, it is still being referenced in the code below here. https://github.com/odoo/enterprise/blob/4174108cb98a9fd84a012ff9dca81ae322c5f338/l10n_lu_hr_payroll/models/hr_payslip.py#L209 As a result, when the ``Payroll: Update data`` cron runs, the system attempts to update a file that no longer exists, causing a FileNotFoundError. [1]: https://github.com/odoo/enterprise/commit/0fecd57652c8c72a4fb91d44bd0c5d75f621541a sentry-7278209115 Forward-Port-Of: odoo/enterprise#108068
This update simplifies the process of adding the 💯 emoji to Odoo messages by introducing a new, more commonly used shortcode (:100:). Additionally, the emoji picker's empty state message has been updated for clarity. These changes improve the user experience and make it easier to express reactions within Odoo.
Original PR description
Purpose of this PR: Before this PR, the 💯 emoji could only be found using the`:hundred_points:` shortcode, which is less commonly used. This PR adds the `:100:` shortcode to improve discoverability. Additionally, the empty-state helper text in the emoji picker is adjusted from `"No emoji matches your search"` to `"No emojis match your search"` for better wording. task-5873748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250145 Forward-Port-Of: odoo/odoo#248654
This update corrects a problem in the payment dashboard query that was causing errors and slowing down performance. The change ensures the query behaves consistently with previous versions by disabling record rules, which reduces unnecessary joins and avoids ambiguous column errors. This improves the dashboard's speed and reliability.
Original PR description
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior. The dashboard query for payments to check was executed with the default…
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.
The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.
```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
self._fill_sale_purchase_dashboard_data(dashboard_data)
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
self.env.cr.execute(sql)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
^
```
Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.
opw-5951694
upg-3902613
[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250003This update fixes an issue where non-sale enabled products were incorrectly appearing in sales orders. The change ensures that only products designated for sale are selectable, preventing errors and improving order accuracy. This resolves a potential data inconsistency.
Original PR description
Steps to produce: --- - Install `sale_renting` and `sale_management` modules. - Go to `Sales > Products > Products`. - Create a product and disable the Sales option (`sale_ok = False`). - Create a…
Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.
Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.
Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
`super_domain + [('rent_periodicity', '=', False)]`, only
`[('rent_periodicity', '=', False)]` was returned, and
`super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
`sale_ok = True` were not applied.
Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.
[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49
opw-5902403
---
Forward-Port-Of: odoo/enterprise#107639This update fixes an issue where Odoo would crash during invoice imports, leading to duplicate invoices being created. The fix ensures that invoices are properly acknowledged even if an import error occurs, preventing this duplication. This improves data integrity and reduces the risk of errors.
Original PR description
When importing invoices, if an error occurs in `_peppol_import_invoice`, Odoo crashes before acknowledging the already created bills. But, since `rollbackable_transaction` is used in `_extend_with_attachments`, the invoice is already committed. Since the acknowledgement is not sent while the invoice is committed, the next `_peppol_get_new_documents` attempt duplicates the invoice. opw-5937044 Forward-Port-Of: odoo/odoo#249842 Forward-Port-Of: odoo/odoo#249521
This update enhances how Odoo extracts amounts from bank statements (like CODA files). It now supports decimal amounts identified through regular expressions, specifically designed for statements that don't use decimal points. This allows for more accurate reconciliation of financial data from various bank statement formats.
Original PR description
Update the reconciliation logic of reco models to support regex patterns using named capture groups 'integer' and 'fraction'. This is specifically designed for cases where bank statement labels (like CODA files) provide amounts in cents i.e continuous string of digits without a decimal separator. The logic now: - Prioritizes 'integer' and 'fraction' named groups if present in the match. - Concatenates these groups with a decimal point to form a valid float. - Falls back to the standard digit extraction logic if named groups are not found. So now if user wants the amount to be extracted in decimal values from label then user needs to add regex which supports two groups 'integer' and 'fraction'. Community PR: odoo/odoo#242750 Task [link](https://www.odoo.com/odoo/project.task/5449413) Task-5449413 Forward-Port-Of: odoo/enterprise#103630
This update fixes a bug where deactivated withholding taxes were still being calculated in payments. The fix ensures that the system no longer includes inactive tax rates, resulting in accurate payment totals. This improves financial reporting and reduces the risk of errors.
Original PR description
# How to reproduce - Install the l10n_ar_withholding module - Pick a Vendor and add a Purchase Withholding tax in the accounting tab - Go into configuration and disable that tax - Create a Vendor Bill with that Vendor - Confirm the bill and create a payment # The problem The deactivated tax is still computed in the payment # Why The function that fetches the withholding taxes does not check if the taxes are active or not # The fix I though of 2 solution : - Add an override to remove the taxes from the Vendor when they are deactivated - Add a filter to the fetch function to check if the taxes are active I chose the 2nd solution as it is the least invasive one. opw-5917257 Forward-Port-Of: odoo/odoo#247831
This update resolves an issue preventing the correct display of an employee's SSN when generating CFDI reports in the payroll module. The fix updates a template reference to directly access the SSN from the employee record, ensuring accurate reporting. This improves the functionality of a key payroll reporting feature.
Original PR description
Steps to reproduce the issue: 1. Install the module `l10n_mx_hr_payroll_account_edi`. 2. Generate a payslip for an employee. 3. The following traceback is raised at the moment to click on "Generate…
Steps to reproduce the issue:
1. Install the module `l10n_mx_hr_payroll_account_edi`.
2. Generate a payslip for an employee.
3. The following traceback is raised at the moment to click on "Generate CFDI" button:
```py
File "/data/build/odoo/odoo/addons/base/models/ir_qweb.py", line 858, in _render_iterall raise
QWebError(qweb_error_info) from error odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the
template: KeyError: 'l10n_mx_ssn' Template: l10n_mx_hr_payroll_account_edi.report_payslip_mx_cfdi Reference:
8166 Path: /t/t/div/t[2]/div[4]/table[2]/tbody/tr/td/div[5]/span[1]
Element: <span class="ms-1" t-field="o.version_id.l10n_mx_ssn"/>
```
---
To avoid moving the `l10n_mx_ssn` field from the `hr.employee` model to `hr.version`, the `t-field` in the template is updated to `o.employee_id.l10n_mx_ssn`.
This approach is valid because an employee's SSN rarely changes. If a modification is ever needed, it can be updated directly on the employee form, where the field is already tracked.
target: saas-19.2
task-5962423This update significantly speeds up the salary simulation process within the HR system. By adding an index and avoiding unnecessary image calculations, the simulation now completes much faster – nearly five times quicker. This improves user experience and efficiency when configuring employee salaries.
Original PR description
Description ----------- Add missing index on `hr.expense.employee_id` as it's used in a few places as a transitive dependency. Avoid computing images for new employee versions during simulation, as it's loading external dependencies, incurring a performance cost. Benchmark --------- On a staging database, opening the salary configurator and clicking on 'Simulation' when selecting a new car took: | Timings for | Before | After | Speed up | |--------------------|--------|--------|----------| | `onchange_benefit` | ~750ms | ~160ms | 4.6x | | `update_salary` | 2.3s | 1.1s | 1.9x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249160 Forward-Port-Of: odoo/odoo#241901
This update streamlines the process of generating salary simulations by introducing a standardized context manager. This ensures consistent setup and teardown of necessary operations, reducing potential errors and improving the reliability of the simulation results. It also enforces the correct configuration for these critical calculations.
Original PR description
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose…
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose and error-prone, as it's done at each call site of `hr.contract.salary.offer._get_version` and `hr.version._generate_salary_simulation_payslip` (or any other future method that may require such a savepoint). These methods have a comment that mentions *requiring* a savepoint to be called, but nothing is enforcing it, so a bug due to oversight is bound to happen. Context keys are also injected a bit everywhere like `salary_simulation` and `tracking_disable`, without much consistency, and adding to the visual clutter. This commit introduces a little context manager called `hr_version_context` that manages the creation of the savepoint, the setup and teardown necessary, and the setting of the keys in the context. It's accompanied by a decorator `@requires_hr_version_context` that will fail if the caller didn't use `hr_version_context` before invoking the marked method. This ensures: - Correct creation of the savepoint and its related pre-/post-operations - Apply context keys consistently - Ensure methods that require such setup *cannot* be called without it. Forward-Port-Of: odoo/enterprise#107743 Forward-Port-Of: odoo/enterprise#103187
This update ensures payslips display the employee's actual start date with the company, rather than the contract's start date. This correction addresses inconsistencies when employees change jobs internally, guaranteeing accurate historical pay information and preventing outdated dates from appearing on payslips.
Original PR description
In the paysplip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Here we create a new function, similar to _get_first_version_date() which returns the beginning of the contract tied to the first version of the period, instead of the beginning of the version itself, which might be before or after the actual date of the start of the contract. We call this function _get_first_contract_date(). Task: 5909637 Enterprise PR: https://github.com/odoo/enterprise/pull/106692 Forward-Port-Of: odoo/odoo#249347 Forward-Port-Of: odoo/odoo#248598
This update corrects a previous issue where payslips incorrectly used the current contract start date. Now, payslips display the employee's actual entry date with the company, ensuring accurate payroll calculations and historical records, especially for internal job changes. This change impacts payroll processing in Switzerland and the UAE.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#107854 Forward-Port-Of: odoo/enterprise#106692
This update resolves an issue where snippets were unintentionally nested within other snippets, causing unexpected behavior in the website builder. The change prevents snippets like 's_popup' and 's_table_of_content' from being dropped into other snippets, ensuring a more stable and predictable website design experience. This improves the consistency and reliability of the website builder interface.
Original PR description
This commit prevents the following snippets to be dropped inside other snippets like tabs, toc, and more: - s_popup - s_newsletter_subscribe_popup - s_newsletter_benefits_popup - s_tabs - s_table_of_content - s_faq_horizontal task-5439635 Forward-Port-Of: odoo/odoo#242035
This update resolves a crash in the Delivery Slip report when printed in languages other than English. The issue stemmed from the report using English labels for key fields. The fix now correctly targets technical fields, ensuring the report functions smoothly across all supported languages.
Original PR description
Steps to reproduce: 1. Switch the partner language to Spanish. 2. Print the Delivery Slip. 3. The report crashes due to translated XPath anchors. Cause: XPath targeted hardcoded English strings 'Tracking Number' and 'Total Weight'. Solution: Target technical fields o.carrier_tracking_ref and o.shipping_weight instead of text labels. opw-5493498 Forward-Port-Of: odoo/odoo#248679
This update resolves a testing issue that prevented users from validating invoices in the AR VAT module. By using 'sudo()' when writing XML fields, the system now bypasses permission restrictions, ensuring consistent and reliable testing. This improves the overall stability of the AR VAT functionality.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update resolves an issue where Odoo couldn't reliably print to older printers. By defaulting to 'IPP Everywhere' PPDs for compatible printers, the system now supports a wider range of printer models, ensuring consistent printing functionality. This change primarily affects printers discovered via DNS-SD.
Original PR description
When no `ppd` is available for the cups discovered printer, we now use the IPP Everywhere ppd. We only set it for dnssd printers as printer that only implement socket/lpd could be too old and not compatible with IPP Everywhere. Forward-Port-Of: odoo/odoo#247210
This update resolves an issue where the payroll sheet calculation would fail if there were warnings present. The change allows the payroll sheet to be generated even with warnings, ensuring accurate payroll processing. This improves the reliability of the HR payroll module.
Original PR description
Revert https://github.com/odoo/enterprise/pull/104137 Forward-Port-Of: odoo/enterprise#108340
This update ensures that invoices generated with the `l10n_it_edi` module correctly display the total amount in EUR, as required by Italian tax regulations. Previously, the total was incorrectly formatted in the invoice currency, leading to potential compliance issues. This change ensures accurate reporting for Italian businesses.
Original PR description
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to…
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency. `ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document: https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b > L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che > “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”. > Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>` > deve essere obbligatoriamente “EUR”. > Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that > “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.” > Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>` > field must mandatorily be “EUR”. As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field (assuming the company currency is always EUR for `l10n_it`). Ticket [link](https://www.odoo.com/odoo/project.task/5913088) opw-5913088 Forward-Port-Of: odoo/odoo#249272 Forward-Port-Of: odoo/odoo#247537
This update resolves an issue where Odoo incorrectly defaulted to USD as the Stripe currency, causing potential blocking for European companies where EUR is the correct currency. The change switches to EUR as the default, ensuring accurate Stripe integration and preventing disruptions for EU users. This resolves previous support tickets opw-5393508, opw-5913327, and opw-5953025.
Original PR description
Right now, we need to guess the correct stripe currency for the stripe account depending on the country, we used the USD as an ultimate fallback But, the USD currency is easy to guess, where the EUR is way harder (it may not be the company currency). So, it is too error-prone to set the USD as the default fallback, and it can lead to EU companies being blocked as their stripe currency is the wrong one. We therefore switch it to EUR. opw-5393508 opw-5913327 opw-5953025 Forward-Port-Of: odoo/enterprise#108293
This update corrects a critical issue in the generation of Belgian UBL invoices by ensuring the required ‘schemeID’ is included. This ID, part of the ISO 6523 ICD list, is now correctly applied, ensuring compliance with regulatory standards for company registries. This fix improves the accuracy and reliability of invoice processing for Belgian businesses.
Original PR description
1) This commit adds the new generic methods to build an UBL file. The big objective is to remove the hierarchy of UBL later on and make BIS3 completely standalone. In this commit, BIS3 is not independent of UBL 2.1 & 2.0. 2) Missing schemeID for Belgium Company registry Since https://github.com/odoo/odoo/commit/d40652c17b43b6a9fd4d19ce84b943b2a51fad9c, in Belgium, we set by default the company registry. However the schemeID is missing and should be part of the ISO 6523 ICD list: https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/ 3) Fix PartyLegalEntity when the country is NL and there is no company registry/EAS/Endpoint That case was raising a traceback before this commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249093 Forward-Port-Of: odoo/odoo#246377
This update fixes a calculation error in the Belgian payroll module, ensuring that meal vouchers and private car expenses are accurately reflected on payslips. Previously, these amounts were displayed as zero. This change ensures accurate reporting and compliance for Belgian employees.
Original PR description
In this commit, we fixed the data of the existing Belgian structure types by setting the right work entry type as default_work_entry_type_id. Belgian's structure types should have the correct attendance work entry type to consider the meal vouchers and the private car in the benefits and payslip lines Before this change, the belgian payslips will have quantity 0 for meal vouchers and private car. After this change, the belgian payslips will have the correct quantity for both meal vouchers and private car. task-5946425
This update fixes a problem where duplicate loyalty cards were being created when not all loyalty programs applied points to an order. The change ensures that loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data efficiency. This addresses an internal issue identified as opw-5405109.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#248653 Forward-Port-Of: odoo/odoo#244254
This update resolves a technical issue related to the preparation of the Cycle Transportation Declaration for Belgian payroll. The fix ensures accurate reporting of this specific tax requirement, improving compliance with Belgian regulations. This change primarily impacts the l10n_be_hr_payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#108069
This update fixes an issue where location, notes, and privacy settings weren't being correctly carried over from the quick event creation form to the full event form. The change ensures that all entered information is consistently reflected when editing events, improving data accuracy and user workflow. This was a simple fix to a data loss issue.
Original PR description
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When…
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When the full form view opens, the `Location, Notes and Privacy` fields are empty, even though they were filled in the quick-create dialog. Root cause: --- - At [1], [2] & [3], `Location, Notes and Privacy` values are correctly stored in the location, notes and privacy fields respectively. - When opening the full form, default values are built via `getDefaultValuesFromRecord`. - And here at [4], location,notes and privacy are missing from the `QUICK_CREATE_CALENDAR_EVENT_FIELDS`. - As a result, these fields are skipped and not passed through the context, causing data loss. Solution: --- - Add the location and privacy fields to the `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they are included when generating default values for the full form view. - And replace `description` with `notes`. Note: --- - As this is a small and simple case, the test has not been added to avoid unnecessary overhead. [1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381 [2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407 [3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403 [4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17 opw-5504553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247117
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly added, which has now been removed. This ensures the correct offer screen is displayed, aligning with the standard Odoo Enterprise experience.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#108179 Forward-Port-Of: odoo/enterprise#104578
This update fixes an issue where trial website requests were sometimes creating duplicate websites. The changes ensure that new trial websites are always created on the user's existing website, streamlining the trial process. A new, more reliable method for generating websites has also been implemented, eliminating the need for a cron job.
Original PR description
Forward-Port-Of: odoo/enterprise#107320
This update addresses usability issues on the mobile version of the bank reconciliation widget. Specifically, the layout has been adjusted to better accommodate the smaller screen size, and some buttons have been simplified to improve clarity and space efficiency. This enhances the user experience for mobile users.
Original PR description
The mobile style on bank rec widget is a bit buggy, this commit adds few improvements: 1 - When in mobile view, chatter is shown on the right (like in desktop view), but the screen is way too tight to display both chatter and st_lines at the same time. Solution: Display the chatter at the bottom of the screen. 2 - If the screen is too tight to show 2 primary buttons (Example: Set Partner & Set Account), We remove the "Set " on the buttons label to save some space. 3 - In tablet view, we don't have enought place to show all the secondary buttons we are showing in desktop view. This commit removes the reco model secondary buttons. (Now accessible in the dropdown menu) task-5114831 Forward-Port-Of: odoo/enterprise#96103
This update prevents internal Odoo users without invoicing rights from accessing and downloading invoice data in JSON/XML format. Previously, a vulnerability allowed internal users to view these sensitive files, posing a potential security risk. This change ensures that access to this data is restricted to authorized invoicing users, improving data security and compliance.
Original PR description
Steps to reproduce: 1. Create an Invoice 2. Send for EDI (should in error, easy way to do it in local turn off the internet) 3. Turn Debug mode 4. Click Download (A new window with URL with will be open) showing the JSON/XML 5. Change Marc Demo (or any user) being internal user without Invoicing rights 6. That user can access the JSON/XML with that particular URL After this commit- We make sure only Invoicing Users can download the JSON/Export task-5481114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243257
This update resolves a bug where users without access to a company were unable to view organization charts for employees in that company. The fix ensures that access checks are performed correctly, allowing users to see the full organizational structure regardless of company permissions. This improves usability and prevents data access errors.
Original PR description
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't…
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B. ## Reproduction Steps 1. Create a second company to your database. Let's call these companies Company A and Company B. 2. Select Company A as your main company, but make sure Company B is also selected. 3. Create an Employee A. 4. Select Company B as tour main company; but make sure Company A is also selected. 5. Create an Employee B who has A as manager. 6. Create Employee C who has B as manager. 7. With a user only having access to Company B, log in and try to access Employee C's page. ### Expected behavior Employee's C page loads correctly. ### Unexpected behavior An access error occurs. ## Origin of the issue A sudo() was missing. __ opw-5910036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248819 Forward-Port-Of: odoo/odoo#247817
This update restores a key feature in the Point of Sale system – the ability to mark orders as 'trusted.' Previously, this functionality was removed, causing potential issues with order management. This fix ensures that users can correctly designate trusted orders, streamlining the sales process.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240883 Forward-Port-Of: odoo/odoo#200567
This update adjusts the order of taxes in Odoo's accounting system for India (l10n_in) to prioritize the most frequently used tax rates. This ensures that the correct tax is applied automatically, streamlining the sales and purchase processes and improving accuracy. This change is a bug fix related to tax calculations.
Original PR description
In this commit, we are updating the tax sequence so that the most frequently used taxes appear at the top, while the less frequently used ones remain at the bottom. The following adjustments are applied: Exempt, Nil Rated, and Non-GST Supply (for both Sales and Purchase) 5% GST, 18% GST, 40% GST (for both Sales and Purchase) 5% IGST, 18% IGST, 40% IGST (for both Sales and Purchase) All remaining taxes will retain their existing order. Ref - https://github.com/odoo/odoo/pull/228765#discussion_r2486366588 Task-5408149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a problematic printing library to significantly improve the stability and reliability of printer functionality within Odoo. While features like QR codes and low-paper warnings are being removed, this change prioritizes a more robust and dependable printing experience.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as…
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper. However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices. Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250141 Forward-Port-Of: odoo/odoo#249819
This update eliminates redundant error messages related to IoT receipt printers. As we no longer collect printer status data, these warnings are no longer generated or displayed. This improves the user experience and reduces unnecessary notifications.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/249819 As we are no longer querying the status of the receipt printer on the IoT box, some of the error messages such as being low on paper will no longer be sent by the IoT. This commit removes the messages in the JS code too. Forward-Port-Of: odoo/enterprise#108336 Forward-Port-Of: odoo/enterprise#108109
This update grants the Invoicing & Banks group within the Odoo Enterprise version access to essential reports, specifically 'Statement Reports'. This enhancement improves reporting capabilities for this group, allowing them to better monitor financial data. This change was made to streamline reporting workflows for key users.
Original PR description
In enterprise, we are allowing the Invoicing & Banks group to have access to basic reports, including 'Statement Reports' task-5925567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249709 Forward-Port-Of: odoo/odoo#249006
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change restores access rights, allowing these users to view essential reports without encountering errors. This ensures accurate reporting and analysis for these user groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108054 Forward-Port-Of: odoo/enterprise#107654
This update fixes issues with downloading the Activitywatch application, specifically addressing problems with the Windows and Linux versions. The changes ensure users can easily access the correct build for their operating system, improving application setup and functionality.
Original PR description
This PR adds the download link for the Ubuntu build of activitywatch, fixes the windows link, and fixes the platform detection. Forward-Port-Of: odoo/enterprise#108079
A horizontal scrollbar appeared in the messaging menu when hovering over muted notifications. This was caused by a margin on the 'Mark as Read' button overflowing the container when the unread counter was hidden. This update ensures the layout remains stable and prevents the scrollbar from appearing.
Original PR description
**Purpose of this PR:** Hovering over a muted notification in the messaging menu caused a horizontal scrollbar because the `'Mark as Read'` button retained a margin that overflowed the container when the unread counter was hidden. This commit makes the margin conditional on the counter's presence, preventing the layout overflow. task-[5904526](https://www.odoo.com/odoo/project.task/5904526) **Before/After:**   Forward-Port-Of: odoo/odoo#247320
This update resolves an issue where the payment QR code remained visible on the customer display after an order was completed. The fix clears data related to the QR code when the order is finalized, ensuring a cleaner user experience. This improves the customer's checkout process.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250102 Forward-Port-Of: odoo/odoo#244991
This update fixes an issue where address information was missing from invoice PDF reports. The change adjusts how template variables are used, ensuring that address details, including information blocks and addresses, are correctly rendered when using the external layout. This ensures accurate and complete invoices are generated.
Original PR description
After the refactoring of the t-set syntax on qweb templates and application of the script, the contact address info stopped rendering due to how now a template level variables are now used. This commit targets to fix the invoice pdf report t-set for 'information_block' and 'address' so that the elements are rendered when the 'external_layout' is rendered. task-5955062 target: saas-19.2 -> master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that invoice reports across various localized versions of Odoo (e.g., for Ecuador and Mexico) correctly display updated address information. The change addresses a technical adjustment to the report invoice layout, improving the accuracy and consistency of invoice documents for international clients.
Original PR description
Adapted each localization report invoice inheritance on the changes to address block
This update resolves an issue that prevented the correct download of XML invoices for Italian companies using the l10n_it_edi module. The fix corrects a mismatch in how invoice data is structured, ensuring the XML FatturaPA file can be generated without errors. This ensures Italian businesses can continue to comply with local tax regulations.
Original PR description
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company…
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company - Create a new invoice > Customer: IT Company > Add a product > Confirm > Send > Send - Actions > Print > XML FatturaPA Traceback: ```py TypeError: string indices must be integers, not 'str' ``` In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary. However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2]. If ``_get_invoice_legal_documents`` returns a dictionary instead of a list, the following logic incorrectly iterates over dictionary key which leads to the above traceback. https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26 [1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9 [2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403 sentry-7272542156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249408
This update resolves a technical issue where strict email servers were rejecting Odoo emails due to improperly folded subject headers. By preventing folding and ensuring subjects adhere to RFC standards, we improve email deliverability and avoid frustrating '554 Invalid Subject header' errors. This ensures our email communications are reliably received by users.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. See-also: #243119 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#247057
This update corrects a UI navigation problem in the add snippet dialog, specifically when using languages like Arabic. The snippet order was incorrect due to language direction differences, leading to a confusing user experience. This fix ensures consistent and intuitive navigation for all users regardless of their language settings.
Original PR description
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language:…
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language: when the backend language and the frontend language are not read in the same direction (RTL / LTR), the frontend language is taken to display the previews (see [f9c77de]). This is the right approach to show the snippets themselves, but the order of the columns should be done according to the backend language, which is the one that gives the instructions for the overall UI. To reproduce: - Set the admin's language to arabic - Clear the cache and refresh your page - Edit and open the add snippet dialog - Navigate with Tab => The 1st focused snippet is in the wrong column compared with the rest of the UI. [9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113 [f9c77de]: https://github.com/odoo/odoo/commit/f9c77de84aa6ea705e5d3f129328fb2199103b9a task-5109547 Forward-Port-Of: odoo/odoo#228414
This update resolves an issue where inactive taxes weren't consistently shown in fiscal position mappings. The change ensures that inactive taxes are correctly displayed in the 'Replaces' field when viewing taxes through the configuration interface or within fiscal position tree views. This improves data accuracy and reporting.
Original PR description
Observed issue: inactive taxes are shown in "Replaces" `original_tax_ids` field if the form view of a tax is opened through "Configuration"->"Taxes", but not shown under "Replaces" in a fiscal position tree view, nor are they shown in the same "Replaces" field of the tax form view when opened from the fiscal position tree view. Cause: the fiscal position link calls `action_open_related_taxes` on partner (path `/account.tax/[id]`), while the "Configuration"->"Taxes" calls `action_tax_form` on tax (path `/taxes/[id]`), which has additional context element `'active_test': False` among others. Solution: adding the context to the fiscal position action produces the desired behavior, but it might break something else as it affects the whole view. task-5917667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247787
This update resolves an issue where Spanish e-Facturae invoices were generating XML files with excessive decimal places (up to 8), causing validation errors with the Spanish tax authority. The fix ensures that currency amounts are rounded to two decimal places as required by Spanish regulations, improving compliance and preventing invoice rejection.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#249674 Forward-Port-Of: odoo/odoo#248882
This update ensures that the names of Ecuadorian localization regimes comply with government requirements for electronic invoicing. The change involves updating the names to match official regulations and adding a mapping field to guarantee consistent Spanish naming conventions for all government-submitted invoices, regardless of user language settings.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update adds a new test to ensure the employee tour feature works correctly. This test was created in response to a previous change that introduced the employee tour functionality. This ensures the feature continues to function as expected and provides a layer of quality assurance.
Original PR description
This commit adds a test for the following related PR: https://github.com/odoo/enterprise/pull/104888 task-5779779 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#244682
This update corrects a restriction preventing HR officers from creating new employees in the Belgian payroll system. The fix utilizes 'sudo' access to correctly read a specific field, allowing authorized users to complete the employee creation process without encountering access errors. This ensures smooth onboarding for new employees in Belgium.
Original PR description
Steps to reproduce: - Install l10n_be_hr_payroll - Have a user with only HR officer rights - Try to create a new employee with that user (in BE) - You have an access error on the field l10n_be_resident_situation The field `l10n_be_resident_situation` has the HR Payroll officer group. This field is used on the inverse of the is_non_resident field, which is accessible to HR officers. This commit fixes the issue by using sudo to read the field's value. task-5779779 Forward-Port-Of: odoo/enterprise#104888
This update resolves an issue where VoIP session tracking was incorrectly identifying sessions due to recent changes in how user sessions are managed. The fix ensures the system correctly searches for sessions in the updated session map, improving the reliability of VoIP functionality. This ensures accurate session tracking for our users.
Original PR description
In this PR: https://github.com/odoo/enterprise/pull/104426 session management was introduced that changed the concept of `mainSession` and `transferSession` in the userAgent. There was a missing cleanup in the function `isInProgress` that is still using the old main and transfer sessions. This commit fixes this bug by searching for the session in the new sessions map.
This update fixes a critical issue where accrual entries weren't correctly reflecting product costs, leading to inaccurate inventory valuations. Specifically, it addresses scenarios where product prices differed from their cost, ensuring proper accounting for sales and purchase orders. This improves the accuracy of financial reporting.
Original PR description
## [FIX] Accrual account domain Since [1], the accrued order wizard can be open from a purchase order line view and from a sale order line view. The wizard account field uses a domain, and this…
## [FIX] Accrual account domain Since [1], the accrued order wizard can be open from a purchase order line view and from a sale order line view. The wizard account field uses a domain, and this domain is different if the active model is `purchase.order`. In quoted PR, the domain wasn't adapted to work with `purchase.order.line` as active model. This PR fixes that. ## [FIX] Correct COGS cost #### How to reproduce the issue - Use anglo-saxon config; - Have a product with a cost; - Sale this product with its unit price =/= its cost; - Deliver; - Create accrual entry for this product => The perpetual valuation lines are not correct, they use the SO lines' price for their debit/credit instead of the product's cost. #### Example If we have a product with cost of $100 and sell it for $180 We currently have: Account Debit Credit Stock Valuation $ 0.00 $ 180.00 Cost of Goods Sold $ 180.00 $ 0.00 But we should have: Account Debit Credit Stock Valuation $ 0.00 $ 100.00 Cost of Goods Sold $ 100.00 $ 0.00 ## PO line price diff #### Issue While generating accrual entries for a PO with billed not received, if the billed price is different than the PO line price, no entries were generated for the price diff account. #### How to reproduce 1. Create a product using "Standard Price" as its costing method and set a cost for this product and set a price difference account (on its product category); 2. Create a purchase order for this product and confirm it; 3. Create an invoice for this PO with a different price for the product; 4. Go to Accounting > Review > Billed Not Received; 5. Select the PO and click on "Create Accrual Entries" button => Accrued entries are created but no entries are created for the price difference. #### Expected behavior Two more entries must be created: one for the price diff account and one for the stock valuation account. [1]: https://github.com/odoo/odoo/pull/231510 task-[5349657](https://www.odoo.com/odoo/966/tasks/5349657) Forward-Port-Of: odoo/odoo#249875 Forward-Port-Of: odoo/odoo#234600
This update resolves an issue preventing users from sharing document templates with read-only fields. By separating validation logic and removing unnecessary security checks, the system now correctly handles shared template requests, ensuring a smoother user experience. This fix improves the reliability of document sharing workflows.
Original PR description
Currently, attempting to share a document template that contains readonly fields fails. When `_populate_constant_items` calls `_fill` to pre-fill these fields, `_fill` aggressively checks that the request state is 'sent'. Since shared links create requests in the 'shared' state, the transaction crashes. Additionally, `_fill` throws a `UserError` if not called with `sudo`, which inappropriately treats a developer/privilege error as an end-user error. This commit resolves the issue by separating concerns: - Moves the `state == 'sent'` validation out of the `_fill` helper and into `_sign` (the caller responsible for actual user signatures). - Removes the artificial `sudo` check in `_fill`, relying instead on standard ORM Access Errors to block unauthorized database writes. (only in master) Task: 5949263 Forward-Port-Of: odoo/enterprise#107898
This update fixes an issue where the order of selection options in sign templates was being lost after saving. The change ensures that user-defined option sequences are consistently preserved, preventing confusion and ensuring data integrity within sign documents. This improves the user experience and reliability of the sign process.
Original PR description
Steps to reproduce: 1. Open a Sign template. 2. Drag a 'Selection' field onto the document. 3. In the popover, type options in a specific order (e.g., Delta, Alpha, Beta). 4. Click save. 5. Re-open or inspect the data 6. observe the order is scrambled based on Database ID. Cause: The Python method used `list(set())` which is an unordered collection, losing the user's input sequence. Furthermore, the final `search().ids` call returned records sorted by primary key (ID) rather than the provided list order. Solution: Replace `set()` with `dict.fromkeys()` to deduplicate while preserving input order. opw-5896373 Forward-Port-Of: odoo/enterprise#108380 Forward-Port-Of: odoo/enterprise#107175
This update clarifies a confusing error message related to delivery scheduling and lock dates. Previously, a validation error would incorrectly flag deliveries as being in a locked fiscal period. The fix ensures the error message accurately reflects the issue and provides better guidance to users, streamlining the delivery validation process.
Original PR description
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both…
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both after the lock date. Related: PR #222169
When validating a `stock.picking` record, the constraint `_check_backdate_allowed()` can fail on a different `stock.picking` record. This is confusing for the end user and makes finding the erroneous `stock.picking` difficult.
## Steps to reproduce.
**setup**:
1. install stock, sale, purchase. Use the demo data.
2. Navigate to Inventory > Configuration > Warehouse and click into the Warehouse for the active company.
3. Select the Routes smart button, then select the Buy route. Ensure that the "Product" option is selected for the Buy route.
4. Navigate to Inventory > Product > Product.
5. Create a test product that is:
1. tracked by quantity (General Information tab)
2. Has a vendor listed (in the Purchases tab)
3. Uses the "buy" route (in the Inventory tab)
4. Has a reordering rule for the Buy route (reordering rules smart button)
6. Do not add any stock for this product.
**reproduction**:
1. Navigate to Sale > Orders.
2. Create and confirm a sale order for the configured product, such that more products will need to be created.
3. Navigate into the delivery order for the sale and set its scheduled date to be December 1st.
4. In Accounting > Accounting > lock dates, set all the lock dates to be December 3rd.
5. Navigate back to the sales order, then use the Purchase order smart button to view the purchase order.
7. Use the Deliveries smart button to view the purchase delivery.
8. Validate the delivery - > Validation error thrown
> You cannot modify the scheduled date of this operation because it falls within a locked fiscal period.
**Solution**: add the name of the stock.picking to the error message & only check the lock date when `date_done` is altered, not `scheduled_date`.
[opw-5428179](https://www.odoo.com/odoo/unassigned-tasks/5428179)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247474This update resolves an issue that caused duplicate move entries to appear in the shop floor view when creating work orders without a Bill of Materials. The fix clarifies how work orders and operations are linked, ensuring accurate display of components and preventing errors that could disrupt production workflows. This improves the reliability of the shop floor interface.
Original PR description
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation…
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation to be performed in a workcenter - Confirm the MO and open the Shop Floor - Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display - Click on `Add component` and add any valid component via the catalog #### > Traceback: `OwlError: Got duplicate key in t-foreach` ### Cause of the issue: The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72 Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188 However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47 Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected. In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error. opw-5417887 Forward-Port-Of: odoo/enterprise#106200
This change reverses a previous update that was incorrectly removing accented characters from legal names used for Mexican VAT (EDI) processing. The SAT now allows all characters, so Odoo will now accept the user-entered, accented names as they are, giving users full control and preventing issues. This simplifies the process and ensures accurate VAT compliance.
Original PR description
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least…
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]). This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues. The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them. This reverts the whole accent sanitization saga: - Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4. This also removes the unused frozendict import to make "Check Style" happy. opw-5915515 [1] https://github.com/odoo/enterprise/pull/95207 [2] https://github.com/odoo/enterprise/pull/107960 [3] https://github.com/odoo/enterprise/pull/96043 [4] https://github.com/odoo/enterprise/pull/106557 [5] https://github.com/odoo/enterprise/pull/107677 Closes odoo/enterprise#107960 Forward-Port-Of: odoo/enterprise#108425 Forward-Port-Of: odoo/enterprise#108189
This update fixes an issue where receipts printed with the l10n_gcc_pos module were displaying English text instead of Arabic. The fix adds Arabic translations to the receipt XML files, ensuring that all text is displayed in the user's chosen language, matching the behavior of other receipts.
Original PR description
Problem: When printing a receipt in arabic using the l10n_gcc_pos module, some of the text is in English. Cause: Translation is not enabled for the module and the text is written in English only in the receipts XML. Solution: Add the arabic translations of texts to the receipts XML and choose the display language based on the user's language (same behaviour in other receipts). Steps to reproduce: - Install l10n_gcc_pos module - Activate and choose Arabic as the language - Open Point of Sale and validate an order - See how some text (specifically "Tax Invoice" and "Simplified Tax Invoice") are printed in English although the rest of the receipt is printed in Arabic. opw-5501464 Forward-Port-Of: odoo/odoo#245795