Daily updates from Odoo
Tuesday, January 27, 2026
31 changes · master
Resolved issues and error corrections
This update fixes a critical issue where the Moroccan tax report XML export incorrectly handled cash basis taxes. The change ensures bills are accurately reflected in the export, aligning with Moroccan tax regulations. This improves data consistency and report reliability.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file. Forward-Port-Of: odoo/enterprise#105106 Forward-Port-Of: odoo/enterprise#104619
This update corrects a bug in how overtime entries are generated within the attendance system. Previously, overtime rules were incorrectly applied, leading to overlapping entries and errors. This fix ensures accurate overtime calculations and approval processes.
Original PR description
STEP TO REPRODUCE:
------------------
0- Go to attendance > Configuration > Overtime Ruleset 1- Create the following overtime ruleset (all rules are paid and with the entry type overtime):
rule 1: timing rule on worked day with this timing : 0AM -> 8AM
rule 2: timing rule on worked day with this timing : 12AM -> 1PM
rule 1: timing rule on worked day with this timing : 5PM -> 12PM
2- Go to attendance > configuration > settings
3- Enable Time Management
4- ANd change the extra hours validation by automatically approved 5- create an employee and give to him this overtime ruleset 6- Create for an attendance for him from 6AM to 8PM 7- to go the form view of this attendance
8- Approve it; you wwill have a traceback
REASON:
-------
The way to handle the reorganization of the overtime line on an attendance was badly done; everything was shift with the same shift so some overtime was overlapping the others
Forward-Port-Of: odoo/enterprise#105173This update resolves an issue where users lacking specific access rights within Odoo could not submit VAT declarations through the Intervat module. By adding sudo permissions, this change ensures all users can successfully complete the submission process, regardless of their access level. This enhances user experience and compliance.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492 Forward-Port-Of: odoo/enterprise#105395 Forward-Port-Of: odoo/enterprise#103647
This update corrects an issue where FedEx labels were incorrectly displaying addresses containing special characters (like accents or non-English characters). The code has been updated to ensure all address components are converted to ASCII, resulting in accurate label formatting for all shipping addresses. This improves the reliability of shipments using FedEx.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#104979 Forward-Port-Of: odoo/enterprise#104265
This update resolves an issue where the tax code (9) was missing from Datev exports for expense payments using 19%I tax. The fix addresses a technical problem with how payment amounts are processed, ensuring accurate tax code reporting in the Datev data. This ensures consistent and compliant reporting to the accounting system.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This update resolves an issue where invoices, sale orders, and POS orders defaulted to an invalid payment method ('Por Definir') in the MX region. This caused fiscal inconsistencies, particularly with the 'PUE' payment policy. The fix removes this default, ensuring accurate financial reporting and compliance.
Original PR description
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE`…
### Issue: The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid ### Cause: In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir` ### Fix: After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank ### Steps to reproduce: - Install `l10n_mx_edi` and switch to the MX company - Create an invoice with today’s invoice date - The payment policy is set to PUE - Before the fix, the payment method is set to `Por Definir` For Sale Order and POS Order tests, it's the default value as soon as you create an order opw-5406038 Forward-Port-Of: odoo/enterprise#105344 Forward-Port-Of: odoo/enterprise#104164
This pull request addresses critical errors identified during automated testing of the planning and timesheet grid modules. The changes fix timezone inconsistencies that were causing test failures, ensuring accurate reporting and scheduling functionality. Resolving these issues improves the reliability of the Odoo Enterprise platform.
Original PR description
Solves https://runbot.odoo.com/odoo/runbot.build.error/238011 https://runbot.odoo.com/odoo/runbot.build.error/238022 https://runbot.odoo.com/odoo/runbot.build.error/238023 https://runbot.odoo.com/odoo/runbot.build.error/238024
This update optimizes how Odoo handles incoming VoIP calls, preventing duplicate call creation caused by multiple users connecting simultaneously. By using a server-side mechanism and PostgreSQL's UPSERT feature, the system now efficiently manages call records, improving performance and reliability for all users.
Original PR description
## Context Each Odoo client (e.g., a browser tab), establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each instance receives the notification, which leads to the associated callbacks being called as many times as there are running Odoo clients. ## Current state To avoid creating a voip.call record for every connected client, we introduced a "get_or_create" method that first attempts to retrieve the record and then creates it if it doesn't exist. If the operation fails due to concurrent updates, the client simply retries it after some jitter. This is not ideal because each attempt results in a round trip. ## After this commit This commit improves the current handling of concurrent updates by managing them on the server side. It leverages the [UPSERT](https://wiki.postgresql.org/wiki/UPSERT) mechanism of PostgreSQL to implement the "get or create" logic and relies on Odoo's automatic retry feature to manage concurrent updates.
This update enhances the accuracy of achievement reports by using a new method for calculating and storing key data. Specifically, the system now utilizes materialized views and indexing to speed up report generation and ensure data consistency, addressing potential calculation inaccuracies.
Original PR description
Investigation in process. task-5477432
This update corrects a technical inconsistency where employee payroll settings were incorrectly marked as editable. The change ensures that fields marked as read-only in the version record are consistently read-only for the employee record, maintaining data integrity and preventing unintended modifications to payroll information. This resolves a prior issue flagged by automated testing.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983 Forward-Port-Of: odoo/enterprise#105414 Forward-Port-Of: odoo/enterprise#100575
This update corrects a problem where inputs weren't appearing on payslips. The fix adds the necessary domain to each relevant model, ensuring that inputs are correctly associated with payslips. This improves the functionality of the payroll system.
Original PR description
When trying to add Inputs for a payslips none appear as the domain was incorrect and only showed salary inputs for use in the employee. This is fixed in this commit by adding to the domain en each specific model. task-5486091 Forward-Port-Of: odoo/enterprise#105160 Forward-Port-Of: odoo/enterprise#103986
A bug preventing feeds from opening in the Social Twitter module has been resolved. This update addresses a technical incompatibility between the new QWeb engine feature and the existing view rendering process, ensuring feeds now open correctly. This resolves a disruption for users accessing social media feeds.
Original PR description
**How to reproduce:** - Install the social_twitter module - Enable Demo Mode - Open a Feed **Before this commit:** A traceback occurs and the feed fails to open. **Technical reason:** Introduced by this commit: https://github.com/odoo/enterprise/commit/99d583d5d6362504b4e838c7825fe9ca8d2b342c This commit introduced the parametric t-call feature for server-side QWeb engine. However, we use `ViewCompiler` to render views (here `KanbanCompiler`), which does not support parametric t-call, leading to the traceback. **After this commit:** The feed opens correctly with no traceback. Task-5707050
This update resolves an issue where Stripe expense data was being duplicated, causing confusion and errors in the Odoo system. The changes now skip the Stripe KYC steps during demo setup, speeding up the process and ensuring accurate data. This improves the demo experience and prevents data inconsistencies.
Original PR description
Prevent expenses automatically created by Stripe Issuing to be duplicated. Currently, it adds a lot of noise on customer dbs. The payment method is duplicated and it can lead to errors (eg: employee submit duplicatas instead of the original expenses. The automatic reconciliation doesn't happen afterwards) task-5246475 Forward-Port-Of: odoo/enterprise#102034
This update resolves an issue where smart buttons on the voip call forms were missing access groups and causing singleton errors. The fix ensures that smart buttons work as intended, displaying the correct information and improving the user experience. This impacts users interacting with voip calls across various modules like CRM, Helpdesk, and Sales.
Original PR description
1. Tickek/Application smart buttons on voip.call form miss access groups. 2. In voip.call form, when clicking the application smart button, a singleton error will raise. 3. Incorrect numbers on smart button. Task-[5461729](https://www.odoo.com/odoo/5778/tasks/5461729) Forward-Port-Of: odoo/enterprise#103233
This update fixes an issue where users couldn't adjust the quantity of optional products added through the portal's upsell feature. The change ensures that the quantity of these products is correctly updated, allowing users to manage their subscriptions and renewals accurately. This improves the user experience and prevents order discrepancies.
Original PR description
Version: - 19.0 Steps to Reproduce: - Enable the Add Products option in the recurring plan. - Create a subscription with the same plan and add optional products. - Confirm the subscription and create invoice for current period. - From the portal, click on Add Quantity to create an upsell order. Before: - Users were not able to update the quantity of products added as optional products from portal. - This happened because the `is_optional` field value was not copied to the new order line created during the upsell. After: - The `is_optional` field value is now copied to the new order line created for upsell and renewal orders. - This allows users to update the quantity of optional products correctly. Impact: - Users can update the quantity of optional products from the portal without issues. task-5427585 Forward-Port-Of: odoo/enterprise#102670
This update resolves a bug in the holiday scheduling Gantt chart that was introduced during a previous refactoring. The fix ensures that holiday intervals are calculated correctly, preventing inaccurate display of employee time off. This improves the reliability of the holiday calendar.
Original PR description
The bug was introduced following this refactor PR: https://github.com/odoo/odoo/pull/229706 This commit fixes the issue by computing correctly the interval with the correct type Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238017 task-5788459
This update resolves an issue where the VoIP ringtone played incorrectly due to multiple tabs receiving notifications. A new system directs incoming call notifications to a central SharedWorker, ensuring only one tab plays the ringtone and addressing potential problems with connection loss or tab inactivity. This enhances the reliability of the Odoo VoIP system.
Original PR description
Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being…
Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution. However, we were informed that sometimes the call wouldn't ring at all 🤬 This called the reliability of the system into question. What would happen if: - The main tab loses the WebSocket connection? - The main tab is throttled? - The main tab was never interacted with, preventing us from playing audio? - The notification arrives after the main tab is killed and before a new main tab is elected? This commit attempts a new approach ⋆✴︎˚｡⋆ All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone. This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that: - effectively received the incoming call notification - is allowed to play audio [Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
This update fixes an issue where employees with multiple bank accounts for salary distribution were receiving payment advice that only showed the first account and incorrectly allocated the full salary. Now, the payment advice (PDF and XLSX) accurately reflects all bank accounts and salary amounts, ensuring accurate payment reporting.
Original PR description
Issue: When an employee had multiple bank accounts with salary distribution, the payment advice (PDF and XLSX) was displaying only the first bank account and assigning the full salary amount to that account. This resulted in incorrect payment information being generated. Fix: When multiple bank accounts are configured with salary distribution, the payment advice now displays the correct information in both PDF and XLSX reports. task-5390429 Forward-Port-Of: odoo/enterprise#104073 Forward-Port-Of: odoo/enterprise#101818
This update corrects a technical error in the l10n_au_hr_payroll module that was causing a warning message to appear incorrectly on the TFN dashboard. The fix ensures that the dashboard accurately reflects TFN status information, preventing potential confusion for payroll users. This resolves a data inconsistency.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998
Forward-Port-Of: odoo/enterprise#103777This update prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets awaiting approval, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#103911 Forward-Port-Of: odoo/enterprise#52355
This update fixes an issue where the 'Inventory Reason' entered during barcode inventory counts wasn't being recorded. Now, when completing an inventory count via the Barcode app, the specified reason is correctly saved and visible in the inventory history. This ensures accurate tracking of inventory adjustments.
Original PR description
## Issue When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere. ## Steps to reproduce 1. Install the *Barcode* app…
## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.
## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
- **The _Inventory Reason_ given in step 5 does not appear anywhere**
If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.
## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.
opw-5423934
Forward-Port-Of: odoo/enterprise#104763This update fixes a potential issue where the system didn't correctly process weight readings from the scale, particularly when using the 'read_once' action. Now, the system reliably handles all weight readings, ensuring accurate data capture and reporting for IoT scale data.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`. Forward-Port-Of: odoo/enterprise#105324
This update fixes a bug where tax return names and status indicators weren't correctly translated when a new language was installed in Odoo. The solution automatically generates translations for all existing tax return names upon language installation, ensuring consistent and accurate translations across all supported languages. This improves the user experience for international users.
Original PR description
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to…
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to the database and select it -> The states of the returns (the little bubble in the kanban cards) aren't translated even though the translation is present in the pot and po files. **Commit 2:** [FIX] account_reports: translation of date in returns title Steps to reproduce: - Have 2 languages on the db - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Switch to the second language -> The period displayed in the name of each return isn't translated **Commit 3:** [FIX] account_reports: translate account returns name after lang installation Steps to reproduce: - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Install another language -> The names of the returns aren't translated in the new language. Solution: When installing a new language, generates the translation of the title for all existing returns task-5421659 Forward-Port-Of: odoo/enterprise#102559
This update addresses a limitation in the account online synchronization process where access tokens expire quickly. We've replaced the token system with a consent token, a unique identifier linked to the user, ensuring a more reliable and persistent consent management experience. This change improves the stability and functionality of the online synchronization feature.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105392 Forward-Port-Of: odoo/enterprise#105202
This update ensures that new partners created during shared sign requests automatically use the signer's name instead of their email address. This improves data consistency and makes it easier to identify signers within the system. It resolves an issue where new signers were created with only their email as a name.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339 Forward-Port-Of: odoo/enterprise#105271 Forward-Port-Of: odoo/enterprise#104869
This update ensures that LNA (a key technology) is consistently used for IoT devices across all Point of Sale systems, including Kiosks. Previously, LNA was only active in the POS, limiting functionality. This change improves the overall performance and reliability of IoT-enabled Kiosk POS operations.
Original PR description
Before this commit, LNA was being used for IoT devices in the POS but not in the Kiosk when `point_of_sale.use_lna` was enabled. After this commit, LNA will also be enabled for IoT devices in the Kiosk. task-5874663 Forward-Port-Of: odoo/enterprise#105520 Forward-Port-Of: odoo/enterprise#105460
This update corrects a compatibility issue with the Bulgarian National Bank (BNB) exchange rate provider. Due to Bulgaria's adoption of the Euro, the BNB now provides rates in EUR, not BGN. This fix ensures that companies using EUR as their main currency can correctly sync exchange rates without errors.
Original PR description
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the…
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR. This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates. refs: We can compare the data here from 31 December using the WayBackMachine: https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm Compared to today: https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm And see the comparison used to be to BGN but is now for EUR Steps To Reproduce: 1. Create a company for Bulgaria with EUR as the main currency. 2. Go to Accounting Settings -> Automatic Currency Rates. 3. Select "[BG] Bulgaria National Bank" as the service provider. 4. Click the sync button. 5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one." The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR. Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO. Ticket [link](https://www.odoo.com/odoo/project.task/5483771) opw-5483771 Forward-Port-Of: odoo/enterprise#105074
This update fixes an issue where the basic salary was incorrectly calculated for employees in Saudi Arabia. The system now verifies the presence of 'WORK100' in employee workdays, ensuring the basic salary is only applied when appropriate, aligning with payroll regulations. This prevents overpayment and improves payroll accuracy.
Original PR description
purpose: we should check if there are WORK100 in the worked days, but as of now, we dont, and that results in having the basic salary triggered even when it shouldn't. - made basic salary only computed when work entry source is calendar or WORK100 in the worked days (there are attendances for the employee) and made its amount adapt with the worked days task-id: 5472853 Forward-Port-Of: odoo/enterprise#104090 Forward-Port-Of: odoo/enterprise#103493
This update resolves an issue where country-based filtering on payslips wasn't functioning properly, leading to errors. The fix ensures that country selections are correctly stored and used for filtering, eliminating module loader problems and improving payroll accuracy.
Original PR description
Issue: The country_id related field on payslip and payslip run was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/enterprise#104167 Forward-Port-Of: odoo/enterprise#103318
This update enables users to create returns for previously archived accounting periods without needing to reactivate or overwrite existing archived returns. This provides greater flexibility in managing returns and simplifies the reporting process. A new test case has been added to ensure the functionality works as expected.
Original PR description
Archived returns are ignored when manually creating returns, allowing a new return to be created for the same period without reactivating or overwriting the archived one. Also a test case has been added for the same task-5440965 Forward-Port-Of: odoo/enterprise#102928
This update fixes a visual inconsistency in the Helpdesk dashboard by extending the conditional formatting and aligning border styles to match other Odoo dashboards. This ensures a more uniform and professional appearance for users accessing the Helpdesk data.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103793 Forward-Port-Of: odoo/enterprise#103019