Daily updates from Odoo
Tuesday, March 17, 2026
49 changes · saas-19.1
Enhancements to existing features
This update enhances the HTML Editor's search functionality by adding a "separator" command to the results when users search for "divider" or "line". This allows users to easily insert horizontal lines or dividers into their documents, streamlining the content creation process. This is an improvement to the existing functionality.
Original PR description
#### Desired behavior after PR is merged: - Separator command now appears when searching for “divider” or “line” in the powerbox. task-5977288 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250935
Resolved issues and error corrections
This update resolves a bug that prevented the burndown chart in the Project app from loading correctly in sample mode when no project was selected. The change ensures the necessary context is set, preventing errors and improving chart functionality. This fix aligns with best practices for embedded actions.
Original PR description
The burndown chart embedded actions use action_id which bypasses the Python method that sets required context (stage_name_and_sequence_per_id). Without this context, the JS model makes RPC calls that fail in sample mode when no project record is selected. This change replaces action_id with python_method, following the same pattern used by hr_timesheet for similar embedded actions. Steps to reproduce: 1. Open Project app 2. Access burndown chart via embedded action without records 3. Sample mode triggers the crash Current behavior: TypeError reading undefined field type Expected behavior: Burndown chart loads with proper context task-5347524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential error that could occur when a session record doesn't have associated device information. It guarantees that session records always contain necessary data like IP address and user agent, preventing errors during user activity tracking. This improves data reliability for reporting and analytics.
Original PR description
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... =…
This commit ensures that there is always information linked to a `res.session` record. This causes an error, for example, if `user_agent` is `False`: ```py ... = self.__user_agent_parser(device.user_agent) ``` We ensure that if we have a `is_current` `res.session` record which does not have a `is_current` `res.device`, we have information (`ip_address`, `user_agent`, `country`, `city`). Scenario: - device A detected at time T0: info A in session + new log A - device B detected at time T1: info B in session + new log B - log B is unlink (or marked as revoked) - device B detected at time T2: nothing ==> `web_read` on `res_users` ==> error T2 < T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` - device B detected at time T3: info B updated in session + new log B T3 > T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY` Explanation: At this moment, T2, because log A exists, a `res.session` record exists. When we compute information for the `res.session` record, as this record is the current session, we must get the current device. To retrieve the current device, we use the `res.device` model. Unfortunately, no current device is present (because log B has been deleted) and `DEVICE_ACTIVITY_UPDATE_FREQUENCY` has not been exceeded. In this case, we have a current session without current device. Note: However, we are certain that there is at least one device for this session record because session records are built with device records. Task-6023651
This update fixes an issue preventing product names from appearing on invoices generated from Point of Sale orders. The change involves a partial revert of a previous fix to ensure the correct product information is displayed without disrupting related widgets. This improves the clarity and accuracy of sales invoices.
Original PR description
Steps to reproduce: ------------------- * Go to point of sale * Open list of orders * Select any order > Traceback Why the fix: ------------ Partially reverting https://github.com/odoo/odoo/commit/937363e5786eeab02b06c2dc63e1d9e743fc1874 as it broke a widget. Pos order are using this widget but the dependency on the field `translated_product_name` makes it impossible to open any order in the backend as this field does not exist on pos order line model. We're only partially reverting the fix to keep the computed fields. This will allow to properly fix the original issue without requiring an exception later. opw-6040334 Forward-Port-Of: odoo/odoo#254158
This pull request reverts a previous change that was causing issues with email notifications related to HR contracts. The fix addresses a technical problem that was preventing proper email delivery, ensuring that users receive expected notifications regarding contract updates. This change improves the reliability of the HR contract management process.
Original PR description
Revert https://github.com/odoo/enterprise/pull/106974
A technical error in the Point of Sale app's order form was causing a problem with displaying product information. This update removed a problematic widget that was relying on a field not present in the order data, resolving the error and ensuring proper order form functionality. This change improves the stability of the Point of Sale module.
Original PR description
Steps to reproduce: = - Open the `Point of Sale` app in the backend. - Open the order list view and try to open any order. Issue: = - A traceback is raised: `KeyError: 'translated_product_name'`. Reason: = - The `product_label_section_and_note_field` widget introduced a dependency on the `translated_product_name` field, which is not present in `pos.order.line`. Fix: = - Removed the widget `product_label_section_and_note_field` from pos order form view as it is not required in pos. Reference PR: = - https://github.com/odoo/odoo/pull/248401 task-6040210 Forward-Port-Of: odoo/odoo#254108
This update corrects a display issue in the employee emergency contact section. Previously, the 'Relationship' field was incorrectly shown for all employees, regardless of their company location. Now, the field is hidden for employees associated with non-Indian companies, ensuring accurate data presentation.
Original PR description
### Steps to reproduce: - Install l10n_in_hr_payroll. - Create an employee (also link a user) in an Indian company and another company. - Go to My Profile > Private Information > Emergency. - The Relationship field is shown for non-Indian employees as well as employees from other countries. ### Issue: - We're not hiding the relationship field if employee is from other country . ### Fix: - We'll hide this field if an employee belongs to non-indian company. Task: 6008888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254162
This update corrects a bug where resending invoices to MER would overwrite existing addendums, even if the invoice hadn't been sent. The fix ensures that existing addendums are updated instead of being replaced, streamlining the invoice processing workflow and preventing data loss. This improves the reliability of invoice handling.
Original PR description
Issue: when resending an invoice already sent to MER, the existing addendum is overwritten even when the invoice is not sent to MER. Solution: updating values on the existing addendum rather than creating a new one, if it already exists. task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253730 Forward-Port-Of: odoo/odoo#253281
This update resolves an issue where non-admin users accessing the Accounting Dashboard from a child company with a currency set on the journal would encounter an access error. The fix bypasses specific record rules when a currency is present, ensuring proper access for all users regardless of the journal's currency setting.
Original PR description
Issue before this commit: Opening the Accounting Dashboard from a child company as a non-admin user raises an Access Error when the journal has a currency_id set. The error occurs with journal items which currency id is set Steps to Reproduce ([video](https://drive.google.com/file/d/1Spt5zruNAVAvSdQYk-RuifzynyIfBOLK/view?usp=drive_link )): - Install the account module. - Create child company - Create journal journal with a currency set - Log in as a non-admin user. - Select only the child company - Open Accounting (Dashboard) Cause of the Issue: When the journal does not have currency_id, the system reads company data using sudo(), so no access issue occurs. When the journal has currency_id, sudo() is not used, and reading the company name triggers an Access Error. With This Commit: Bypass record rules when reading the company name if the journal has a currency_id. opw-6017296 Forward-Port-Of: odoo/odoo#253844
This update fixes a technical problem where Chrome was creating unnecessary temporary files, leading to potential performance issues. By directing Chrome to use its temporary directory as its data directory, we now automatically clean up these files during the system's regular cleanup process. This ensures smoother operation and prevents file clutter.
Original PR description
It's unclear since when or under what configuration exactly, but Chrome(ium?) seems prone to creating directories called `org.chromium.Chromium.*` (or some variant thereof) in the temp dir (some people report them to be prefixed by a `.`) and never clean them. By telling chromium that its tempdir is its data dir, it creates its litter in there, and we remove the entire thing during cleanup, solving the littering. Forward-Port-Of: odoo/odoo#253350
This update corrects a typo in the XML format used when sending debit notes to the Italian SDI (electronic reporting system). The original error caused debit notes to be rejected, preventing accurate tax reporting. This fix ensures compliance and proper data transmission.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253905
Forward-Port-Of: odoo/odoo#249284This update fixes a minor issue where closing the emoji or GIF picker resulted in it not reopening immediately. The change ensures the picker state is correctly reset, providing a smoother and more reliable user experience when selecting emojis or GIFs. This prevents users from needing to click multiple times to access these features.
Original PR description
**Current behavior before PR:** When the GIF or emoji picker is dismissed by clicking outside, the component state remains out of sync because `props.onClose` isn't triggered. This causes the next attempt to open the picker to fail, requiring an extra click from the user. **Desired behavior after PR is merged:** Closing the picker now correctly triggers the `props.onClose`. This ensures the component state is always reset, allowing the picker to reopen immediately on the next click. task-[5953015](https://www.odoo.com/odoo/project/1519/tasks/5953015) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253776 Forward-Port-Of: odoo/odoo#250630
This update resolves an issue where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. The fix ensures that stock moves accurately reflect the BoM quantities, improving the reliability of production planning within the barcode app. This prevents errors and discrepancies in inventory management.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110540 Forward-Port-Of: odoo/enterprise#90408
This update resolves an issue where changing a company's VAT setting on Peppol would cause invoices to be rejected by accounting partners. The fix prevents automatic recalculations of EAS/Endpoint values, ensuring invoices are correctly synchronized and avoiding errors. This improves invoice processing reliability for Peppol-registered companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 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#253744 Forward-Port-Of: odoo/odoo#249017
This update corrects a bug that was preventing accurate calculations for salary percentages within the HR contract module. The fix ensures that benefit amounts are correctly calculated based on percentage values, improving the reliability of payroll data. This resolves a minor issue impacting HR reporting.
This update resolves an issue where default values for selection-type salary inputs weren't correctly displayed in payslips. The fix ensures that the form view updates properly when new inputs are added, guaranteeing accurate and consistent salary calculations. This improves the reliability of payroll processing.
Original PR description
Steps to reproduce: - Create a Salary Input of type 'selection'. - Assign a default value to this input. - Add the input to a payslip. Bug Cause: The form view is not re-comupting the values when it's assigned for the first time since the container is not changed Solution: Forcefully update the payroll_properties when we add new inputs in the payslip form task-5357904
This update reverts a recent change related to the Eco Voucher benefit within the Belgian HR payroll module. This change was causing issues with payroll calculations and has been rolled back to ensure accurate and compliant payroll processing. The change ensures continued compliance with Belgian tax regulations.
This update fixes an issue where the website's filter options disappeared when using the 'off-screen menu' style. The change ensures the filter button remains visible when no sort or pricelist options are selected, providing a consistent and user-friendly experience. This improves the usability of product searches on the website.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858
This update resolves a crash in the mobile view of the project kanban when adding a 'Blocked By' task. The fix ensures that the system checks for the existence of the parent task before attempting to access its details, preventing a 'Cannot read properties of undefined' error. This improves the mobile user experience and prevents data entry issues.
Original PR description
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to…
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to mobile view 3) Click on the **Blocked By** page and click **Add Blocked By**. ### **Error:** TypeError: Cannot read properties of undefined (reading 'raw_value') ### **Root cause:** The `project_sub_task_view_kanban_mobile` view inherits the base task kanban and removes the `parent_id` field via xpath `position='replace'` at [1]. However, the wrapping `<a>` element with `t-if='record.parent_id.raw_value'` at [2] remains in the template. Since the field is no longer declared, `record.parent_id` is undefined, and accessing `.raw_value` on it causes the crash. [1]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L759 [2]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L704 ### **Fix:** This commit ensures that in the base kanban template, it checks that `record.parent_id` exists before accessing `.raw_value`. **opw-5920660**
This update resolves an issue where mass email sorting failed due to inconsistent date information in emails. The fix adds a default date of midnight to emails without a defined date, ensuring consistent sorting and preventing errors during email processing. This improves the reliability of email sending operations.
Original PR description
Background: In odoo.com, due to some migration scripts, there are messages without neither a date nor create_date Issue: When sending mass emails to applicants, when determining the parent email, emails are sorted using their date, but since some emails have a date and some don't, comparing them results in an exception (comparing datetime with bool). Fix: Add datetime.min as a fallback for the email's date if neither date nor create_date are set. Task-6041584
A previous change caused an error when starting a new pay run if the date field was left blank. This fix ensures the system validates the date field before processing, preventing the 'value.toFormat is not a function' error. This ensures users can consistently initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338
This update resolves a display issue in the 'By Employee' time off reporting feature. Previously, users only saw record IDs in the list view; now, the report correctly shows relevant employee data. This ensures accurate reporting and simplifies data analysis for HR teams.
Original PR description
**Steps to reproduce** - Go to Time Off > Reporting > By Employee - Switch to graph view - Click on one of the columns Issue: only the id of the records is displayed in the list view **Cause** There's no list view defined for the `hr.leave.employee.report` Issue present since the rework in 1c3f5633ef87f6d9c5a6169eefd51cd42ef442d5 opw-5977793
This update resolves a mobile UX issue where incorrect time off balances were displayed and leave types without maximum limits lacked the 'Available' label. This ensures employees see accurate time off information when using the mobile app, improving usability and reducing potential confusion.
Original PR description
This change fixes 2 problems in the mobile UX side panel: - Time off types with zero allocations were shown. - Leave types without a max leave amount didn't show the "Available” label. task-6030539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users on Firefox couldn't hear incoming calls. The fix ensures that call tracks are processed immediately upon arrival, regardless of the session establishment timing. This improves the Odoo VoIP functionality for Firefox users.
Original PR description
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the…
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller. This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*". The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done). Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists. This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added. [1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf [2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0 [3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e [4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850 task-5902700
This update fixes an issue where the 'Edit Menu' button within the link preview was overlapping its text. The change ensures all buttons in the preview display correctly, providing a cleaner and more professional user experience. This improves the overall usability of the HTML editor module.
Original PR description
Before this commit: the Edit Menu button's text stacks when the url's preview is loaded. After this commit: we make sure the button isn't wrapped for all the buttons inside the link preview. task-6036771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the mobility budget calculation in the Belgian HR contract module was not functioning correctly when the page initially loaded. The fix ensures that the budget is accurately displayed, improving the accuracy of payroll processing for employees relocating within Belgium. This impacts the correct calculation of employee compensation.
This update resolves an issue where the Odoo system was sending incorrect data to Mollie for payment processing. Specifically, when a customer's address information was incomplete, Odoo was generating an error. The fix adds default empty strings to address fields, ensuring Mollie receives valid data and payment transactions can proceed smoothly.
Original PR description
When a partner has no country (or other address fields) set, accessing `partner_country_id.code` (and similar Char fields) returns `False` in Odoo instead of an empty string. This caused Mollie's API to return a 422 error because it expects a string for `billingAddress.country`. Add `or ""` fallbacks to all string fields in `_mollie_prepare_billing_address_payload` to ensure valid JSON types are always sent. opw-6037640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that CTA queries use the current day's currency rate, rather than a rate from the previous day. This correction improves the accuracy of currency calculations within the system, leading to more reliable reporting and financial data. It addresses a previous issue where outdated rates were being used.
Original PR description
We use currency rate at day x - 1 to be applicable at a date x, which shouldn't be applicable in the cta queries. Use same-day rate for the CTA query. task-5969168 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where currency rates were being used retroactively in certain reports (CTA queries). Now, reports will use the correct, same-day currency rate, ensuring more accurate financial reporting and analysis. This improves the reliability of key business reports.
Original PR description
We use currency rate at day x - 1 to be applicable at a date x, which shouldn't be applicable in the cta queries. Use same-day rate for the CTA query. task-5969168
This update corrects a technical issue where changes to contract salary information within the Odoo configurator were not consistently reflected. The fix ensures that all salary-related fields are accurately updated, providing greater control and precision for managing employee compensation. This improves data integrity and reporting accuracy.
This update fixes a technical issue that caused tracebacks when users attempted to insert AI-generated content into knowledge articles via the AI chat quick action. The fix ensures the correct function is passed during AI chat initiation, preventing errors and improving the user experience. This enhancement ensures smooth AI content integration within the knowledge base.
Original PR description
Prior to this fix, the user would get a traceback when trying to insert AI generated content to a knowledge article (IF they opened the AI chat through the quick action button in "New Article"). The traceback was shown because `selectPreviousInsertion`` function was not passed to the `aiSpecialActions`` object when calling the `launchAIChat` function. This function allows us to replace previously inserted content if the user choose to from the same AI conversation. When launching the AI chat from this quick action button, we can be sure that the article doesn't have any content previously inserted, so we can define the passed function but leave it empty. Task-5490199
This update resolves a problem where combo prices were incorrectly doubling when multiple items were ordered during pricelist updates. The fix ensures that free items are scaled correctly and that parent unit prices are accurately updated, leading to more reliable combo pricing in the Point of Sale system. This improves the accuracy of sales calculations and prevents overcharging customers.
Original PR description
Fix combo prices doubling when quantity > 1 during pricelist changes. Correctly scale free items in 'getFreeAndExtraChildLines' and ensure parent unit prices are updated in 'setPricelist'. task-id: 5971935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where adding attributes to archived product templates caused errors. The change now correctly accounts for both active and archived product variants, preventing template deletion and ensuring archived templates retain their attributes.
Original PR description
When adding attributes to an archived product template, an error was raised because the template was incorrectly deleted. This happened because variant counting only considered active variants. Now counts all variants (active and archived) to prevent template deletion, and filters variants before activation to keep them archived when their template is archived. @qrtl QT6449 Forward-Port-Of: odoo/odoo#252927
This update resolves an issue where users were unable to correctly set both a start and end date for a date range field within the web_studio. The system now prevents setting both fields simultaneously, ensuring data integrity and a consistent user experience. This change improves the reliability of date-based configurations.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#110212 Forward-Port-Of: odoo/enterprise#108562
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill activity. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and reducing manual adjustments. This improves data accuracy and efficiency for invoice processing.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#253322
Forward-Port-Of: odoo/odoo#251419This update fixes a bug that prevented users from removing external members with edit access from spreadsheets after archiving. The fix updates validation logic to correctly handle both adding and removing access rights, resolving three related warnings and ensuring proper spreadsheet functionality. This improves the user experience and data management.
Original PR description
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly…
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly prohibited. However, due to a validation error in the access rights wizard, users were unable to fix this. Cause: The validation logic in `documents_sharing.py` performed checks after any action was taken. If an illegal configuration was detected, it set a flag to hide the Save button. Because the check did not distinguish between adding an illegal rule and deleting one, users were blocked from removing the very records causing the validation failure. Solution: The validation checks have been updated to account for the operation- type (addition or deletion). This ensures that while new illegal rules are still blocked, existing illegal rules can be successfully removed to restore the system to a valid state. A test was also added to prevent this problem form happening in the future. This PR applies uses the solution to fix the state of 3 warnings, ensuring they are only displayed when actually relevant. Specifically, it covers: - The warning triggered when removing external users with edit access in `documents_spreadsheets`. - The `has_warning_no_access` warning in documents. - The `has_warning_link_with_more_rights` warning. task-5902391 Forward-Port-Of: odoo/enterprise#108140
This update resolves issues with the formatting of Dutch SBR and ICP reports, specifically correcting incorrect VAT identifiers and date formats within the exported XML files. A cleanup process has been added to improve the readability of these reports for users.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update simplifies the scatter plot chart by removing the unnecessary zoom feature, which created inconsistencies across axes. This change aligns with upcoming plans to allow users to manually set axis minimum and maximum values, providing greater control over chart presentation.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task/PR - Task: 5388389 - [https://github.com/odoo/enterprise/pull/106189](https://github.com/odoo/enterprise/pull/106189) 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#246954
This update removes a confusing zoom feature from the scatter plot chart in Odoo Enterprise. This change simplifies the chart's functionality and aligns with upcoming plans to allow users to manually adjust axis ranges. This improves the overall user experience for this chart type.
Original PR description
## Task Description This PR aims to remove the zoomable feature for the scatter plot, as it's kind of non-sense to be able to zoom on an axis and not on the other for this type of chart. Moreover, we will soon be able to manually set the min/max of each axis manually (in master). ## Related Task - Task: 5388389 Forward-Port-Of: odoo/enterprise#106189
This update fixes an issue where leave hours weren't being calculated correctly for allocations without end dates. The change broadens the allocation timeframe to start from the earliest start date, ensuring accurate tracking of leave hours across all allocations, regardless of their expiry dates. This improves the reliability of leave balance reporting.
Original PR description
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after…
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after each allocation start date - Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report. ### Cause: After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery. ### Fix: Following the same approach we use in if the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date opw-5474596 Forward-Port-Of: odoo/odoo#253831 Forward-Port-Of: odoo/odoo#250432
A test within the Odoo Enterprise system was failing when the 'Accountant' module wasn't present. This update corrects a discrepancy in the expected account used during testing, ensuring the test now runs successfully regardless of the 'Accountant' module's installation status. This resolves a minor technical issue that could have prevented future testing.
Original PR description
Currently test_bank_rec_widget_batch_foreign_currency_journal_without_entries fails when `accountant` module is not installed because the expected account differs opw-5887218 Forward-Port-Of: odoo/enterprise#110917
This update corrects a performance issue in the budget report, ensuring faster execution times. Previously, an installation of the account_budget_purchase module was causing slow report generation due to a bypassed optimization. This fix restores the intended performance improvement.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127 Forward-Port-Of: odoo/enterprise#109322
This update resolves a technical limitation in the Odoo Report Editor, preventing users from applying properties to fields selected within the '/field' command. Previously, this was not supported, leading to inconsistencies. This change ensures correct functionality and data handling within reports.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790 Forward-Port-Of: odoo/enterprise#110409 Forward-Port-Of: odoo/enterprise#109486
This update fixes an issue where the lower portion of the barcode editing page was hidden by buttons. The change ensures that all fields are always visible, regardless of button size or zoom level, improving the user experience when adding or editing barcode items. This prevents frustration and ensures accurate data entry.
Original PR description
# How to reproduce - Set the barcode of a product - Go to Barcode > Operations > (Select any operation) > New - Click on the cog in the top right and type in the barcode you set for the product - Apply and then edit the item you added - Add options to the page (like Expiration Date) or increase the browser's zoom until the list of fields take the whole page # The problem The fields at the bottom of the page are hidden behind the buttons at the bottom # Why The controls at the bottom are positioned absolutely and with a high z-index, so they hide anything behind them. The form css class fixes this issue by adding a margin-bottom roughly the size of the controls. But this fix does not take into account the fact that the controls can grow in size when the DELETE button is displayed opw-5907564 Forward-Port-Of: odoo/enterprise#107496
This update resolves an issue where serial numbers weren't being generated correctly using date-range sequences. The fix ensures that each new receipt creates a unique serial number within the specified date range, improving inventory tracking accuracy. This change was implemented by refining the sequence update logic during lot generation.
Original PR description
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable:…
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable: `Use subsequences per date_range`, add a range date containing today - Create a product tracked by Serial numbers - Create and confirm a receipt for 3 units of your product - Detailed of the move > Generate Serials/Lots > New > Generate #### > 3 serial numbers were created but the date specific sequence has only been updated once. This can be checked by creating a new receipt and processing the same exact flow. ### Cause of the issue: Generating the serial numbers will call the `action_generate_lot_line_vals`. However, this method is not tailored to deal with the `use_date_range` and increments the main sequence rather than the actual subsequence: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/stock_move.py#L1103-L1106 ### Fix: We rely on the apparently unused `_get_current_sequence` method to recover the appropriate sequence by date range to update: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/odoo/addons/base/models/ir_sequence.py#L114-L128 This method has been introduced in an accounting naming IMP: 915aa9e4db3169a4767617b5310721f0d9c16812 and is unused since the accounting is no more relying on name sequences: dfd01b8c5c7e1177f37bf199790a0732a61eed78 In addition, we fine tune the current version of the code updating the serial sequence on lot generation since it is currently updating the sequence only if the first generated lot has been set via the`New` button and hence has incremented the sequence via a `next_by_id` call: https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/lots_dialog.xml#L33 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/generate_serial.js#L48-L56 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L261-L275 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L335-L337 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L53-L55 While if the value of first lot is given manually to the wizzard is given manually to the wizzard, the sequence does not get incremented by the nextval. opw-5931056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253618
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When ‘Create Backorder’ is always enabled, a process triggered a duplicate labour entry. The fix ensures labour costs are recorded only once per backorder work order, preventing inaccurate accounting and maintaining data integrity.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 --- Forward-Port-Of: odoo/odoo#253689 Forward-Port-Of: odoo/odoo#250237
The planned removal of the older RPC service (xmlrpc) has been delayed until Odoo 21.1 or 22. This change ensures continued support for Odoo 20, 21, and 22 under the standard support policy, maintaining existing functionality and avoiding disruption for users.
Original PR description
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was…
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was A Bad Idea. The removal is postponed to Odoo 21.1/22. This makes so that if the [Standard and extended support] policy remains the same until the release of Odoo 22, all versions supported with no additional fees (20, 21, 22) at that time will have JSON-2: | version | supported at 22 release | rpc services | JSON-2 | | ------- | ----------------------- | --------------------- | ------ | | 18.0 | no[^1] | active | absent | | 19.0 | no[^1] | active but deprecated | active | | 20.0 | yes | active but deprecated | active | | 21.0 | yes | active but deprecated | active | | 22.0 | yes | absent | active | [Standard and extended support]: https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html [^1]: with no additionnal fees. Forward-Port-Of: odoo/odoo#252721
This update removes birthday events from automatic synchronization with Google Calendar. These events are complex to manage and don't provide much value, often creating confusion for users. Filtering them out simplifies the calendar sync process and improves user experience.
Original PR description
Birthday events are a special kind of yearly-recurrent event that notably cannot be simply deleted like other events. They also appear as a separate calendar in the google UI to an extent, similar to tasks. As they require special handling, have little functional value and can be confusing due to that "fake calendar" behavior. We will now always filter them out of broad calendar sync. task-5966907 Forward-Port-Of: odoo/odoo#250916
This pull request addresses several issues related to the processing of physical cards through Stripe in the Odoo Enterprise system. Specifically, it fixes problems with UK card handling, improves test coverage, and enhances logging for easier debugging. These changes ensure accurate and reliable processing of UK expense reimbursements.
Original PR description
Forward-Port-Of: odoo/enterprise#110263