Daily updates from Odoo
Navigate
Branch
Tuesday, March 17, 2026
288 changes
7 changes
Resolved issues and error corrections
This update fixes a persistent 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 and then cleaning up this directory during testing, we've eliminated this file clutter. This ensures smoother testing and a more stable development environment.
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 visual issue where the unit price wasn't shown on product pages when using the 'boxed' layout in the ecommerce section. The fix adds the necessary code to display the unit price correctly, ensuring a consistent and informative shopping experience for customers regardless of the layout they choose. This improves the clarity of product pricing on the website.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253071
Forward-Port-Of: odoo/odoo#250319This update resolves an issue where the offer simulation feature in employee paychecks was incorrectly using existing employee data. The fix ensures a temporary version is used for simulations, generating accurate payroll projections. This improves the reliability of pay calculations.
Original PR description
### Steps To Reproduce:
- Go to any employee > generate payslip
- Come back to employee's form view and click on simulate button
### Issue:
- We were using actual employee's version in simulation.
### Fix:
- Instead of using existing employee version, use the temporary created
employee's version
### Additional Issues Encountered:
- When creating simulate payslip, model('hr.payslip.worked_days') need version_id
- When click on simulate button, the values, salary, pay structure, work schedule should be filled with value corresponding to selected employee.
task: 5936444This update fixes a key issue preventing UK users from correctly setting up their Stripe accounts for expense reimbursement. The team added specific instructions for UK account creation and implemented a secondary check (Stripe currency set to Euros) to ensure users in the UK flow are properly configured. This improves the user experience for UK employees.
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros. Forward-Port-Of: odoo/enterprise#110103 Forward-Port-Of: odoo/enterprise#109667
This update fixes an issue where delivery batches weren't correctly grouped with the selected carrier after order confirmation. Now, when changing the carrier during the delivery process, the new batch will be associated with the original carrier, ensuring accurate batch management for shipments. This improves order fulfillment efficiency.
Original PR description
**Problem:** If you have group by carrier option in automatic batches, when you create an SO with a stocked product, confirm the order, and in the delivery step you set/change a carrier, it creates a…
**Problem:** If you have group by carrier option in automatic batches, when you create an SO with a stocked product, confirm the order, and in the delivery step you set/change a carrier, it creates a new batch transfer, and it doesn't group it with the appropriate batch with that carrier. **Steps to reproduce:** 1) In the settings enable: Batch, Wave & Cluster transfers 2) Inventory > Configuration > Warehouse Management > Operation types 3) Enable Auto-batches, Batch grouping by carrier on Delivery orders 4) Make sure there is no batches made before contains the carrier you're going to use (to cleanly test this issue) 5) Make a sales order, add storable product, press on 'Add shipping' button and add 'standard delivery' 6) Go to the delivery of the pick from the smart button > validate it 7) Go to the next transfer to see the batch number 8) Make a new sales order, add storable product > confirm it > go to the delivery step > additional info 9) Add 'standard delivery' in the carrier field > validate the delivery > go to the next transfer button 10) check the batch it got added to, you will find it is a new one and didn't get grouped to the last batch created with the same carrier. **Expected behaviour:** It should get grouped in the batch containing that same carrier. **Cause:** When the SO is confirmed without a carrier, and then you edit the carrier in the delivery step (pick) then press on validate, it gets the carrier from the vals in the SO (blank), then along the way while validating the pick, `find_auto_batch` gets called with the empty carrier, so it creates a new batch, *AND then* it propagates the carrier from the SO to the pick using `get_new_picking_values` method, but by then it's too late as the batch is already created with the blank carrier. **Solution:** The problem happened because of this commit: https://github.com/odoo/odoo/commit/7c32adcd82119c35485addd1b198a7fcc0053c9f We need to add the propagation of the carrier_id to the vals if it was already changed or set before the validation of the pick. opw-5882310 Forward-Port-Of: odoo/odoo#248490
This update resolves a technical error in the Point of Sale app that was causing a display issue on order forms. The problematic widget was removed, eliminating a dependency on a field that wasn't present, and ensuring the order forms function correctly. This improves the overall user experience for Point of Sale operations.
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. This change now hides the field for employees associated with non-Indian companies, ensuring data accuracy and a consistent user experience.
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
14 changes
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
1 change
Resolved issues and error corrections
This update fixes an issue where multiple email addresses associated with a contact were being overwritten when creating a helpdesk ticket. The change ensures that all email addresses linked to a contact are correctly captured, improving the reliability of ticket creation. This addresses a potential data loss scenario.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
9 changes
Resolved issues and error corrections
This update fixes an error that occurred when testing the Point of Sale module with Fiskaly in test mode. The fix now intelligently skips subscription checks during testing, allowing users to test fiscalization without needing a valid subscription. In live mode, subscription validation continues as normal.
Original PR description
Steps to Reproduce: ------------------------ - Install the Point of Sale module and `l10n_at_pos`. - Generate Fiskaly credentials in test mode. - Change the document layout from Settings. Issue:…
Steps to Reproduce:
------------------------
- Install the Point of Sale module and `l10n_at_pos`.
- Generate Fiskaly credentials in test mode.
- Change the document layout from Settings.
Issue:
-------
- Saving the settings triggers an IAP error.
Cause:
---------
- Whenever fields related to Fiskaly configuration are updated, Odoo attempts
to update the corresponding values in Fiskaly through IAP. However, IAP always
performs a subscription validation on updates, which fails in test environments
where no valid subscription exists.
Fix:
----
- Handle the subscription check based on the Fiskaly environment:
- TEST MODE
- Skip the IAP subscription validation.
- Allow the flow to proceed normally so anyone can test fiscalization without requiring a subscription.
- LIVE MODE
- Ensured subscription validation occurs before attempting to create or update the company in Fiskaly.
Related PR: https://github.com/odoo/iap-apps/pull/1494
opw: 5560958This update fixes an issue where Saudi POS orders with both regular sales and settlement lines weren't being properly validated. The recent update to the pos_settle_due module required a change in how settlement lines were identified, but this wasn't initially applied. Now, the validation flow correctly detects and prevents processing of mixed orders, ensuring accurate settlement reporting.
Original PR description
# Description of the issue/feature this PR addresses: From saas-18.3 onward, the pos_settle_due module updated the method used to identify settlement lines from isSettleDueLine() to…
# Description of the issue/feature this PR addresses: From saas-18.3 onward, the pos_settle_due module updated the method used to identify settlement lines from isSettleDueLine() to isAnySettleLine(). This change was not reflected in the Saudi POS EDI integration during forward-porting, which caused incorrect validation when processing POS orders containing both regular sale lines and settlement lines. # Current behavior before PR: - Orders containing a mix of new sale lines and settlement lines could bypass the intended validation. - The validation logic relied on the deprecated isSettleDueLine() method, which is no longer available in newer versions when the pos_settle_due module is installed. # Desired behavior after PR is merged: - Update the validation flow to use isAnySettleLine() (when available) to correctly detect settlement lines. - Prevent validation of POS orders that contain both settlement lines and new sale lines. - Ensure compatibility with newer versions of the pos_settle_due module and restore the intended settlement validation behavior. I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
A bug was preventing portal users from submitting website forms that create tasks. This update resolves an AccessError that occurred when the system tried to access a specific field on the task. The fix uses a temporary workaround to bypass portal access restrictions, ensuring smooth task creation for all users.
Original PR description
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website…
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website form that creates a task 3) Set a project on the form 4) Submit the form as a portal user ### **Error:** `AccessError: You do not have enough rights to access the field project_privacy_visibility on Task (project.task)` ### **Root Cause:** The confirmation template evaluates `task.project_privacy_visibility` in a t-if condition at [1]. since [commit](https://github.com/odoo/odoo/pull/203891/changes/17664b3f118491f954dd6a810521ce5865d51a43), project task restricts portal users to a whitelist of fields defined by [_portal_accessible_fields()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1015-L1019). Field access is then validated in [_has_field_access()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1021-L1031), which denies read access to fields not present in this whitelist. `project_privacy_visibility` is not part of the portal readable fields list. When the template tries to read it, _has_field_access() rejects the operation and raises an AccessError. [1]- https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/website_project/views/project_portal_project_task_template.xml#L13-L16 ### **Fix:** Use `sudo()` when reading `project_privacy_visibility` in the template to avoid the portal field access restriction. **opw-6010622**
This update resolves a technical error that prevented users from placing lunch orders with vendors when a 'Until Date' was specified. The fix ensures the system correctly handles date comparisons, allowing users to consistently create lunch orders. This improves the reliability of the Lunch module.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Lunch module 2. Lunch > configurations > Vendors 3. Open any vendor and set Until date to any near future date 4. Go to My Lunch > New Order 5. Click on Any product with above vendor > Add to Cart 6. Click on Order Now Observation: ------------------------------ Traceback Occurs: ``` return not (self.recurrency_end_date and date.date() >= self.recurrency_end_date) and self[fieldname] ^^^^^^^^^ AttributeError: 'datetime.date' object has no attribute 'date' ``` Issue: ------------------------------ `_available_on_date` calls `date.date()` unconditionally, which fails when passed a `datetime.date` object (from `lunch.order`) since date objects lack the `date()` method. Solution: ------------------------------ Check instance type before calling `date()` to handle both `datetime.datetime` and `datetime.date` objects correctly. opw-5948688 Forward-Port-Of: odoo/odoo#249449
This update fixes an issue where multiple email addresses on a contact were being overwritten when creating a helpdesk ticket. The change ensures that a contact's email addresses are correctly captured, resolving a potential data loss problem. This improves the reliability of ticket creation and management.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes any rental amounts from this calculation, ensuring accurate reporting and compliance with Hong Kong tax regulations. This improves the reliability of payroll data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919
This update fixes a bug in the accounting module that occurred when multiple reconciled lines were present. The fix prevents a traceback by skipping the computation within '_compute_full_amount_switch_html' when multiple reconciled lines are detected, ensuring accurate reporting. This improves stability and reliability of the accounting process.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879
This update resolves a technical issue that caused a traceback when using the pivot table autofill feature. While the fix doesn't fully correct the autofill behavior, it ensures the system doesn't crash, and the result is now consistent with vertical autofills. This improves the stability of the pivot table functionality.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110129 Forward-Port-Of: odoo/enterprise#109620
This update fixes a bug where invoices could be created for timesheets that had already been billed. The issue stemmed from the system not correctly tracking and preventing the repeated invoicing of timesheet hours, leading to inaccurate financial records. The fix ensures that invoices are only generated for timesheets that haven't been previously billed.
Original PR description
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet…
__ ## Short functional explanation of the error When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month. In the wizard, we set the timesheet period from the first to the last day of last month. Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter. ## Reproduction Steps 1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded. 2. Record 2 hours with a random date for last month. 3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form, set the invoice date to last month (after the day on which you recorded the timesheet hours) and confirm. 4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month. 5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`. 6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February. 7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm. ### Expected behavior The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced. ### Unexpected behavior An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal). ## Origin of the issue When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet. __ opw-5426434 Forward-Port-Of: odoo/odoo#250946
4 changes
Resolved issues and error corrections
This update resolves an issue where links within Helpdesk ticket templates were incorrectly identified as links instead of buttons. The change ensures buttons are properly recognized by the editor, allowing users to correctly interact with ticket templates. This improves the overall functionality of the Helpdesk module.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#107888
This update fixes an issue where multiple email addresses associated with a contact were being overwritten when creating a helpdesk ticket. The change ensures that all email addresses linked to a contact are correctly captured, improving the reliability of ticket creation and communication. This addresses a potential data loss scenario.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
This update resolves a technical issue that caused a traceback when using the pivot table autofill feature. The fix corrects a misidentification of the function being called, ensuring consistent behavior with vertical autofills. While the core autofill functionality remains unchanged, this ensures stability and prevents errors.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110129 Forward-Port-Of: odoo/enterprise#109620
This update resolves an issue where the bulk payments feature would crash if a linked bank account wasn't properly connected. A new user message has been added to inform users that the journal needs to be linked to a bank before checking the status of a payment batch. This prevents unexpected errors and improves the user experience.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#109956
52 changes
New functionality added to Odoo
This update introduces a new report specifically for the Belgian localization of Odoo. It allows HR managers to track and summarize the total amount of meal vouchers paid to employees on a monthly basis, providing a clear audit trail and improved reporting capabilities.
Original PR description
Add a new meal vouchers report model for the Belgian localization to track and summarize paid meal vouchers per month. This report provides a clear overview of employees’ meal voucher entitlements and totals for a given period. task-5907053
This update adds a new field to contract templates, aligning with Belgian payroll requirements. This ensures that relevant employee information is automatically populated based on the selected contract type, streamlining payroll processing. It improves data accuracy and compliance for Belgian employees.
Original PR description
In order to match the current structure for the employee payroll view and automatically fill all the fields based on the contract template selected, the joint committee field will be added to the contract template following the belgian localization. Task: 6023068
This update adds a 'Notice Period' section to the End of Collaboration wizard, streamlining the process for employees leaving the company. It now allows for immediate payslip generation or scheduling of departures, and automatically sends a notification email to the employee, ensuring a smoother transition.
Original PR description
## Before: - End of Collaboration wizard did not have Notice Period details. - FNF Payslip could not be generated directly from the wizard. - No email was sent to the employee on apply or validation. ## After: - Added a "Notice Period" tab in the End of Collaboration wizard. - Enabled FNF Payslip generation directly from the wizard. - If notice duration is 0, the button shows “Apply & FNF Payslip” and generates the payslip immediately. - otherwise the button shows “Schedule” and schedules the departure on the notice end date. - Sends an email to the employee when the End of Collaboration is scheduled. Task-3505331
This update introduces a new report that tracks the growth of Emirati employees within specific skill levels. It compares this growth with a new data model to record emiratization compliance percentages, providing valuable insights into workforce development efforts aligned with UAE regulations.
This update introduces a new interactive onboarding tour for the Planning Field Service module. The tour guides new users through the key features and functionalities, helping them quickly understand and utilize the system. This improves user adoption and reduces the time it takes for users to become proficient.
Original PR description
task-5265667 Forward-Port-Of: odoo/enterprise#110352
Enhancements to existing features
This update enhances the clarity of salary rules within Odoo's payroll system. The display name for salary rules has been standardized to 'Display Name', and a tooltip provides immediate context. Reports now consistently show the salary rule description when available, improving readability and understanding for payroll administrators.
Original PR description
-The display name of description has been changed to "Display Name" -Tooltip has been added for the description field. -Report has been adjusted to show the salary rule description, instead of rule name, if present.
This update improves the handling of private car reimbursements within the HR payroll module. It now provides a warning if an employee's salary is below a certain threshold or if no other transportation benefits are defined, and automatically processes the reimbursement. A tooltip is also added for employees exceeding a minimum threshold.
Original PR description
. Add warning if annual salary below max_sal_privatecar_reimb or no other transportation benefit defined . Reimburse the private car if no other transportation benefit defined . Add a tooltip if the employee is above the minimum task-5993972
This update fixes a display issue in the employee simulation wizard, ensuring it correctly shows the employee's actual salary. The change involved updating the system's context to accurately reflect salary data, leading to more reliable simulation results. This improves the accuracy of forecasting and planning related to employee compensation.
Original PR description
Pass the correct default context to make the wizard show the employee's salary Task-6025688
This update adjusts the layout of product views to align the Avatax category field with sales taxes. This change ensures a cleaner, more organized presentation of product information, particularly for sales tax calculations. The change improves the user experience by streamlining the product view.
Original PR description
The base unit count/price field needs to be exactly below the sales taxes field in the product view, and the Avatax category field is the only field that positions itself right below the sales tax div, getting between the sales taxes and base unit fields. Task ID: [4277792](https://www.odoo.com/odoo/project/966/tasks/4277792)
This update enhances the accuracy of ONSS rate calculations for Belgian payrolls by incorporating company size (importance code). It simplifies company configuration and improves the selection process for employer types. This ensures compliance with Belgian regulations and provides more precise payroll reporting.
Original PR description
In order to accurately compute the ONSS rate of a given company following the Belgian localization of payrolls, importance code (company size) field is added to the configuration of a given company with its different buckets. Moreover, some improvements where added for the label and selections of FFE employer type. To ensure a streamlined process for configuring a company following the belgian localization, the default values and requirement of the field were removed Task: 5923029
This update introduces a new field for tracking partial work time specifically for Belgian employees within Odoo Enterprise. This allows for more accurate payroll calculations when employees work less than full-time, addressing a key requirement for Belgian labor regulations. The change is designed to improve the accuracy of HR and payroll data for this specific region.
Original PR description
Added a part-time field on the employee form only visible for Belgian employees and when the employee is not full-time (i.e. work_time_rate < 1) task-5979825
This update simplifies payroll configuration for US companies by removing unnecessary account codes. The system now supports configuring payroll using XML IDs instead, aligning with the lack of a standardized US CoA. This change improves flexibility and reduces complexity.
Original PR description
We are removing account codes from the US CoA because there's no normalized CoA in the US and account codes are optional. _configure_payroll_account() only worked with codes. An alternative parameter was added to configure payroll with XML IDs instead. The _configure_payroll_account_generic_coa() was removed as well, because it no longer appears necessary. task-5891104
This update simplifies report generation by setting the journal filter to 'off' by default. Now, when a ledger exists, users will automatically see a dropdown menu to select the specific ledger, ensuring relevant financial data is always displayed without requiring manual adjustments. This enhances report usability and clarity.
Original PR description
On the majority of reports, the journal filter is not necessary by default. But we need to still show the ledgers, independently of the journals. So when the journal filter is disabled, but a ledger exists, show a dropdown menu with the ledgers. task-6032881 Forward-Port-Of: odoo/enterprise#110506
This update streamlines the testing process for the stock barcode module by optimizing how test data is prepared. Moving setup configurations to `setUpClass` reduces test execution time slightly. Additionally, the code now creates records in batches where possible, further enhancing efficiency.
Original PR description
This commit moves the records' creation and the configuration of the `stock_barcode` tests from the `setUp` to the `setUpClass` method, so those are done only once and not at the beginning of every test. The purpose of this change is to slightly speed up the run of tests. Forward-Port-Of: odoo/enterprise#110000 Forward-Port-Of: odoo/enterprise#109624
Resolved issues and error corrections
This update resolves several issues related to the integration of Field Service into planning, improving access to intervention portals and enhancing the user experience within the Field Service module. Key changes include streamlined portal access, improved reporting, and enhanced functionality for scheduling and communication.
Original PR description
[FIX] planning_field_service: fix follow-up (round 4) This commit continues to fix the various issues found due to the refactoring of Field Service feature to integrate it into planning instead of…
[FIX] planning_field_service: fix follow-up (round 4) This commit continues to fix the various issues found due to the refactoring of Field Service feature to integrate it into planning instead of being an extension of project. This commit will: - fix 'Print' action and ticket to intervention portal access - always display in range mode for planned dates in planning.slot view - update billable and non-billable filters to take into account `under_warranty` field - review search view of planning.slot, some filters have been renamed and moved. - use employees instead of resources in portal list (no need to display the material resource in the portal views in other words) - add "Send mail", "Send SMS", "Send Report" and "Add/Remove followers" buttons in cog menu of list and kanban views of planning.slot model. - remove helper in ticket button since it does not bring useful information. - add ticket description on related shift, when the user plans an intervention from a helpdesk ticket, the new shift created from that action, will have the description of the related ticket inside Note field (name field) - fix display_name, to avoid displaying the field used in the group by in the display name since it is a bit redundant - take into account worksheet set in product as default - fix some labels, visibility conditions, dates format, group_expand - add default company of the slot when the user creates a resource from the form view of planning.slot model - show customer preview stat button once the intervention is completed and a report is available for that intervention - update tooltip for employee product to bring more context to explain how that new field works. - make sure the SOL for timesheet is not generated when we complete an intervention if the project linked is non billable - add icon on stat button of timesheet - make sure the user can only create service product in product field in employee - show "X Products" button to non sale user in the form view of planning.slot - make project billable and timesheetable by default when the user wants to create a new project from the project_id field inside the form view of planning.slot model - hide schedule stat button in the form view of project.task if the task is a template or linked to a project template - update visibility condition of sign in in calendar, to make visible for planning manager when the slot is published even if the shift is not assigned to that user and the slot is in the past. task-6009593 Forward-Port-Of: odoo/enterprise#110178
This update automatically closes sign activities when a signature request is cancelled. Previously, cancelled requests left lingering active activities, which could mislead users. This change ensures a cleaner workflow and accurate tracking of signature requests.
Original PR description
When a signature request is cancelled (e.g. due to a new one being created), the related sign activity for the responsible user was not closed, leaving a misleading active activity. After this improvement, when a sign request gets cancelled, the associated signature request activity is automatically closes. task-[5920466](https://www.odoo.com/odoo/project/1251/tasks/5920466)
This update enhances the visual presentation of alias email addresses within the Helpdesk module. The change improves the user experience by making alias emails more clearly visible, streamlining communication and reducing potential confusion for support agents. This is a minor visual improvement.
Original PR description
task-6013894
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 data accuracy and a consistent user experience.
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 Forward-Port-Of: odoo/enterprise#109775
This update fixes a formatting issue in Odoo's payslip PDF reports. Previously, hours were displayed as decimals, which was difficult for employees to understand. Now, hours are shown in a more user-friendly HH:MM format, improving clarity and accuracy.
Original PR description
The hours in the payslip PDF file are displayed as a decimal which is not user friendly. The commit changes the payslip report template to display the hours as HH:MM. Task: 5975766
This update fixes an issue where payslips weren't properly connected to their corresponding pay runs. Now, when a payslip is added to a pay run, it's correctly linked to the employee version, ensuring accurate payroll processing. This improves data integrity and reporting.
Original PR description
**Description** . When creating or adding a payslip to a Pay Run, the corresponding employee version (contract record) was not being linked to the Pay Run's version_ids. Instead it include all the employee versions **Implementation** . Link payslip's version_ids to payrun . Remove create() method . Add dates constraints . Add corresponding tests task-5959481
This update resolves an issue preventing the Indian payroll demo data from installing correctly. The fix adds a required field ('structure_id') to the demo data, ensuring compatibility with the system's requirements. This allows users to properly test and utilize the Indian payroll features within the Odoo Enterprise environment.
Original PR description
After this https://github.com/odoo/enterprise/pull/103118 (New Employee Type), Indian payroll failed to install with demo data. Issue: `structure_id` is a required field in the hr.payslip.run model, but after refactoring, it is not updated in the pay run demo data. Fix: Add `structure_id` to pay run demo data. task-6040571
This update fixes an issue where the lower portion of the barcode operation page was hidden by buttons. The fix ensures all fields are visible, regardless of button size, improving usability when adding or editing barcode items. This prevents users from missing important information.
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 changing the 'Kitchen Note' on a food item after a quantity update would cause an error. The fix ensures that the note can be updated successfully, regardless of previous quantity changes, improving the reliability of the POS system.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946 Forward-Port-Of: odoo/enterprise#110184 Forward-Port-Of: odoo/enterprise#104889
This update optimizes the process of deleting `mail.activity` and `mail.message` records linked to `voip.call` records. Previously, a slow scan of the database occurred, impacting performance. Adding an index significantly speeds up these deletions, resulting in faster database operations.
Original PR description
Description ----------- Commit odoo/enterprise@5751f93c53d3cf37ae8cb627fb8d10a81b7b8833 adds a few new `Many2one` fields, but they're are not indexed, leading to a `Seq.Scan` on `voip.call` when deleting a `mail.activity` or `mail.message`, whos tables are usually large. This commit adds an index on the fields to speed up the deletion. Benchmark --------- Deletion of a `mail.activity` on a database with a `voip.call` table with ~13M rows. (on hot) | Before | After | |--------|---------| | 2.3s | 0.85 ms | Forward-Port-Of: odoo/enterprise#110707 Forward-Port-Of: odoo/enterprise#110622
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes these rental amounts, ensuring more accurate payroll reporting and compliance with local tax regulations. This improves the reliability of financial data within the Odoo Enterprise system.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#110730 Forward-Port-Of: odoo/enterprise#109919
This update allows portal users to upload attachments to knowledge articles. Previously, access restrictions prevented this functionality. This change improves the user experience by enabling users to share richer content within the knowledge base.
Original PR description
Previously, portal users were unable to upload attachments due to access restrictions on ir.attachments. This task overrides those access rights, allowing portal users to upload attachments. Task-4334962
This update adds a warning to salary rules in Odoo when critical fields are missing from their XML definitions. This prevents unexpected runtime values from being used, ensuring accurate payroll calculations. The system automatically backfills existing rules with these missing fields to maintain data integrity.
Original PR description
Reset cron restores salary rules from XML values. If reset-critical fields are omitted in explicit rule definitions, cron can keep unexpected runtime values instead of restoring intended defaults.…
Reset cron restores salary rules from XML values.
If reset-critical fields are omitted in explicit rule definitions, cron can keep
unexpected runtime values instead of restoring intended defaults.
This change does 2 things:
- adds create-time warning for missing reset-critical explicit fields
- backfills existing standard/localization salary rule XML records with those
fields
Warning scope:
- selector fields: condition_select, amount_select
- amount-dependent: quantity (for fix/percentage)
- property_input technical fields only (kept strict, low-noise)
- excludes cosmetic fields (name/description/section/etc.) to avoid warning
noise
Example:
```
<record id="l10n_au_ote_structure_1" model="hr.salary.rule">
<field name="category_ids"
eval="[(6, 0, [ref('l10n_au_hr_payroll.rule_category_ote')])]"/>
<field name="name">Ordinary Time Earnings</field>
<field name="code">OTE</field>
<field name="sequence">20</field>
+ <field name="condition_select">none</field>
<field name="amount_select">code</field>
<field name="amount_python_compute">
...
</field>
</record>
```
Example (amount-dependent quantity):
```
<record id="some_fixed_rule" model="hr.salary.rule">
<field name="condition_select">none</field>
<field name="amount_select">fix</field>
+ <field name="quantity">1.0</field>
<field name="amount_fix">1000.0</field>
</record>
```
task-6033101This update simplifies a technical component within the Stock Barcode module, resulting in a slight performance improvement. The change focuses on internal processes and doesn't directly impact users. It's a routine maintenance update to ensure the module continues to operate efficiently.
Original PR description
community https://github.com/odoo/odoo/pull/253890
This update enforces a critical rule: each pay structure must have unique salary rule codes. Previously, duplicate codes caused errors, and the system would use only one. Now, a validation error alerts users to duplicates, and the system adds '(copy)' to the code to differentiate them, ensuring accurate payroll calculations.
Original PR description
Before: - Salary rules with the same code could exist in the same pay structure. - Only one of them was used during payroll computation. - Duplicated salary rules kept the same code. After: - Salary rule codes must be unique within a pay structure. - A validation error is shown when a duplicate code is used. - Duplicated salary rules now get `(copy)` added to the code. task-5424386
This update fixes a minor visual issue in the VoIP call history by moving the 'Open full history' button back to its original position. Previously, the button was hidden due to the infinite scrolling design of the tab, now it's more easily accessible. This improves the user experience for accessing the full call history.
Original PR description
Commit [1] moved the top-right icon-button in the recent calls tab to the bottom of the tab as a real "Open full history" button. The problem is that this tab is an infinite scroll one... so this button is never reachable in real use-cases. This moves it back at the top-right, with the same icon as the Odoo list view. Note: we discussed keeping both buttons and limiting the infinite scrolling but it was judged not worth the lines of code, as it is not an important button to discover. [1]: https://github.com/odoo/enterprise/commit/8be431afdfd9450155535a4b4552e2e774d291c6 task-5475238
This update resolves an issue where the annual report generated from the accountant_knowledge module was not fully translated, displaying only the title and index in the selected language. By restoring the original field definition, the full content of the report sections is now correctly translated, ensuring consistent localization for all users.
Original PR description
### Issue before this commit: When changing the system language, the annual report generated from the accountant_knowledge module was only partially translated. While the index and article titles…
### Issue before this commit: When changing the system language, the annual report generated from the accountant_knowledge module was only partially translated. While the index and article titles were correctly displayed in the selected language, the content of each section remained in English. This behavior was also visible in the exported PDF version of the report, resulting in a document where only structural elements were localized while the body text of the report sections was not. ### Steps to reproduce the issue: 1. Install another language than english and switch to that one 2. Install Accounting app and audit modules 3. Go to Accounting > Revision > Annual Report 4. Create an Annual Report and click on it 5. Index is in the correct language but the text inside a title is not ### Cause of the issue: The issue was caused by a modification in the knowledge_article model where the template_body field definition was changed. In the previous implementation, the field was defined as a Text field with translate=html_translate, which allowed the HTML content of the template body to be extracted and processed by Odoo’s translation system. In the modified version, the field was converted to an Html field without specifying the translate parameter. As a result, the content stored in template_body was no longer marked as translatable, preventing the translation extraction mechanism from generating translation entries for the article body. ### Reason to introduce the fix: Restoring the translation capability for the template_body field ensures that the full content of the annual report can be localized according to the user’s selected language. opw-5958383
This update fixes a potential issue where incorrect payroll property settings could lead to inconsistent payroll calculations. The change enforces validation rules to prevent setting properties on incompatible salary rules, ensuring more reliable and accurate payroll processing. This improves the overall stability and trustworthiness of the Odoo Enterprise payroll system.
Original PR description
Issue: - Payroll properties could be set on salary rules not configured for employee inputs, leading to inconsistent behavior during payroll computation. Fix: - Raise a validation error when attempting to set a payroll property on an invalid salary rule. - Remove incorrect test usages relying on unsupported salary rules. - Align payroll property update logic with employee input configuration. Task: 5410254
This update corrects a visual issue where the subscription status badge was incorrectly aligned to the left side of the form. A recent UI change caused a default width issue, and this commit restores the intended right alignment. This ensures a consistent and professional appearance for users.
Original PR description
A recent UI framework update caused `o_field_widget` containers outside of groups to default to 100% width. This broke the `float-end` class on the subscription state badge, forcing it to render on the left side of the form sheet. This commit adds the `w-auto` class to the field to constrain its width to its content. This restores the intended right-aligned floating behavior. task: 6030343
This update resolves a bug in the Saudi payroll module that caused salary rules to reset unexpectedly. The issue stemmed from a file name error, which prevented the correct data from loading. This fix ensures accurate salary rule calculations for Saudi users.
Original PR description
[FIX] l10n_sa_hr_payroll: fix salary rule reseting Bug reproduction: Select Saudi l18n, payroll app -> salary rules -> edit one of Saudi salary rules -> there will be reset button -> press to that -> traceback Bug cause: hr_salary_advance_and_loan_data such file is tried to be loaded but there is not such a file. Bug solution: The name of that file is hr_salary_rule_salary_advance_and_loan_data indeed. I fixed the name only to load the correct data back. task - 6040484
This update corrects a bug that prevented the creation of 'Cash Supplement' cash moves in German POS systems. The original code incorrectly capitalized the type string, causing an error with the Fiskaly accounting system. Now, the correct casing is maintained, ensuring proper cash move processing and avoiding errors.
Original PR description
When creating a cash move of type "Cash Supplement", the type sent was "Zuschussecht" instead of "ZuschussEcht", which caused is not an allowed type. Steps to reproduce: ------------------- * Setup a PoS with a TSS for a German localization * Start a session and open the cash control popup * Create a cash move of type "Cash Supplement" * Close the session > Observation: You get an error from Fiskaly that the type is not allowed Why the fix: ------------ When doing `.capitalize()` on a string it would make the first letter uppercase and the rest lowercase. In this case "ZuschussEcht" would become "Zuschussecht", which is not the correct type expected by Fiskaly We now keep the original casing for all the type. opw-5462364 Forward-Port-Of: odoo/enterprise#110270 Forward-Port-Of: odoo/enterprise#109235
This update simplifies the IoT connection process by removing a temporary feature that disabled longpolling after connection errors. Now, the system assumes a correctly configured network, allowing for faster reconnection attempts. This change aligns with our new recommendation for LNA clients.
Original PR description
We used to disable longpolling for 5 min after a failure, in order not to lose time while making requests to an unreachable device, and jump directly to WebSocket. As we now recommand using LNA, clients should have a correctly configured network: if an error occurs the next one should work correctly. We then removed the longpolling auto disable feature. Forward-Port-Of: odoo/enterprise#110158 Forward-Port-Of: odoo/enterprise#108335
This update fixes an issue where users could successfully cancel subscriptions that already had invoices generated. The change adds a check to ensure subscriptions with active invoices cannot be cancelled after they've been closed, preventing potential revenue discrepancies. This ensures accurate subscription management and billing.
Original PR description
Steps to reproduce: -------------------------------- 1. Install Subscription module 2. Create a new subscription quotation and confirm it 3. Generate an invoice for the subscription 4. Attempt to…
Steps to reproduce: -------------------------------- 1. Install Subscription module 2. Create a new subscription quotation and confirm it 3. Generate an invoice for the subscription 4. Attempt to cancel the subscription * A ValidationError is correctly raised 5. Close the subscription by selecting any close (churn) reason 6. Attempt to cancel the same closed subscription again Observation: -------------------------------- The subscription is successfully cancelled even though it already has invoices Issue: -------------------------------- In the following code: https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices Solution: -------------------------------- Added an additional condition to prevent cancelling churned subscriptions that still have active invoices opw-5479719 Forward-Port-Of: odoo/enterprise#109755 Forward-Port-Of: odoo/enterprise#106596
This update resolves a delay issue experienced on iOS devices when interacting with the Point of Sale system. The fix involves adjusting how the system responds to user touches, specifically addressing differences between iOS and Android devices. Additionally, pinch-zoom functionality has been temporarily disabled to ensure optimal performance.
Original PR description
On IOS devices, there was a latency issue when hitting different elements in the POS and self. Actually, the issue is because IOS devices don't react in the same way as Android devices. IOS adds a delay of +/-300ms when the element is not considered as a button. Instead of replacing a lot of elements with a button element we can add the parameter role="button". I also disabled the pinch zoom in the POS, self and preparation display. It's mandatory to add the parameter touch-action: pan-x pan-y to the * selector. task: 5976364 community pr : https://github.com/odoo/odoo/pull/251198 Forward-Port-Of: odoo/enterprise#110627 Forward-Port-Of: odoo/enterprise#109483
This update incorporates Uzbek translations from Odoo 19.0 into the enterprise version. The translations were applied directly to specific modules, focusing on correcting missing translations and ensuring consistency. A key focus was on verifying the accuracy of the translations within each module to maintain quality.
Original PR description
Copying translations from 19.0, only direct module matches. I.e. Missing translations were not filled in + moved terms were not matched across modules (i.e. no translation context to ensure correctness) Forward-Port-Of: odoo/enterprise#110497
This update resolves an issue where employee skills weren't being copied to newly created appraisals generated by the automated appraisal process. The fix adds a necessary step to ensure skills are correctly populated when appraisals are initially created in the 'pending' state, guaranteeing accurate appraisal data.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date…
Steps to reproduce: ------------------------------------- 1. Install `hr_appraisal_skills` module 2. Create a new employee and assign at least one skill to the employee 3. Set the Next Appraisal Date to today 4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually 5. Open the newly created appraisal for the employee Observation: ------------------------------------- In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage Issue: ------------------------------------- When the cron `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via `create()`. The skill-copying logic only lived in the `write()` override, which triggers on state transitions from 'new' to 'pending'. Since `create()` bypasses `write()`, Employee skills were never copied to cron-created appraisals https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15 Solution: ------------------------------------- Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied. opw-5491433 Forward-Port-Of: odoo/enterprise#110601 Forward-Port-Of: odoo/enterprise#107760
This update resolves a limitation in the Odoo Report Editor where certain field types were not properly supported. Previously, the /field command in the report editor couldn't handle properties, leading to incorrect report configurations. This change ensures that all field types can be correctly selected, improving report customization capabilities.
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#110561 Forward-Port-Of: odoo/enterprise#109486
This update fixes a visual issue where payslip PDFs appeared as 'draft' even after payruns were validated. The change ensures the correct, finalized PDF is displayed in the foreground, eliminating confusion for users. It also updates the default attachment used when generating the final PDF.
Original PR description
When creating a payrun and using the Test Print button, the pdfs with the yellow banner saying that the payslip is still draft are generated correctly. When validating the payrun a cron runs to generate the real pdfs. In 19.2 there is a preliminary problem (fixed here) where the payslips are not marked for pdf creation and therefore are not taken by the cron (in master they are correctly marked for it). After that, the pdfs are correctly computed but the pdf in the foreground remains the draft one, generating confusion. With this PR we also change the default attachment when we generate de final pdf, solving the problem. Task: 6023186 Forward-Port-Of: odoo/enterprise#110604
A test was failing due to a mismatch between the user's language setting (French) and the tour content (originally written for English). This commit resolved the test failure by ensuring the tour correctly displays regardless of the user's language preference. This prevents potential issues with the web_studio feature.
Original PR description
Before this commit, a test set the language of the user to French and then opened the browser with that user and that language. The tour in question, written for English failed. After this commit, the tour doesn't fail runbot-error-241983 Forward-Port-Of: odoo/enterprise#110765
This update fixes an issue where the system incorrectly calculated demand for dependent components within the MRP planning process. Previously, it defaulted to the oldest BoM, leading to inaccurate forecasts. Now, the system uses the BoM selected by the user within the MPS, ensuring accurate demand calculations and updated component quantities.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693This update fixes a performance issue in the Web Studio module by ensuring binary asset bundles are pregenerated during test runs. Previously, tests repeatedly regenerated these bundles, slowing down the testing process. Now, bundles are created once and reused, significantly improving test execution speed and stability.
Original PR description
The commit odoo/odoo@a5c02da5c24bfc85b3bbb7d1410d489d3c7185b8 introducing binary asset bundle support overlooked the pregeneration of said bundles for the tests runs. This leads to hot-regeneration of those bundles during tests runs on the runbot (multiple hundreds of times) instead of only once and reusing them. This commit adds support for those binary bundles during pregeneration. Forward-Port-Of: odoo/enterprise#110555
This update fixes a key issue preventing UK users from correctly setting up their Stripe accounts for expense reimbursement. The team added specific instructions for UK account creation and implemented a secondary check for Euro currency settings to ensure users in the UK receive the appropriate funding instructions. This improves the user experience and ensures compliance with Stripe's UK implementation.
Original PR description
### [IMP] hr_expense_stripe: Rework tests for UK Rework the test framework to handle the United Kingdom specific tests ### [FIX] hr_expense_stripe: Fix UK account creation Add UK account creation funding instructions as it was made available to us by Stripe ### [FIX] hr_expense_stripe: Fix funding instruction EU Before this commit: The funding instructions were using the country group Europe as a reference to see if the country should use the EU funding instructions The issue comes from the fact that a lot of people remove their country from that country group, locking themselves out of stripe issuing EU. This adds second way of telling the user is in the EU flow if their stripe currency is set to Euros. Forward-Port-Of: odoo/enterprise#110416 Forward-Port-Of: odoo/enterprise#109667
Features or functions removed from Odoo
This pull request addresses minor formatting inconsistencies within the Odoo Enterprise rental module. The changes remove unnecessary whitespace from XML files, improving code readability and maintainability. This is a routine maintenance task that ensures the codebase remains clean and consistent.
This update removes an outdated and unused QUnit test framework from the web_studio module. This streamlining simplifies the codebase and reduces maintenance overhead. The removal does not impact any existing functionality.
Original PR description
Remove the now useless legacy QUnit test framework.
Code cleanup and technical improvements
This pull request enhances the Odoo Enterprise website's live chat functionality by streamlining the connection between live chat visitors and helpdesk channel members. Specifically, it moves relevant data fields to the channel level, improving organization and efficiency for support teams. This change ensures a smoother experience for both visitors and agents.
Original PR description
PR community: https://github.com/odoo/odoo/pull/242575
This update combines the Mexican reporting modules into a single, streamlined package. This simplifies maintenance and installation for users needing Mexican accounting reports, ensuring consistent reporting across the Odoo Enterprise platform. It maintains existing functionality without impacting current operations.
Original PR description
This PR merges the `l10n_mx_reports_closing` and `l10n_mx_xml_polizas` modules into `l10n_mx_reports`, as they all provide Mexican accounting reports and are required for standard reporting flows for any company. This consolidation keeps all existing features unchanged while simplifying module maintenance and installation. Related PR-https://github.com/odoo/odoo/pull/247185 Upgrade PR-https://github.com/odoo/upgrade/pull/9202/ task-5431997
This update streamlines the integration with UrbanPiper by consolidating related modules and making the data synchronization process more efficient. The changes improve how order and store information is sent to UrbanPiper, leading to smoother delivery operations and better data management.
Original PR description
- Merged UrbanPiper modules into the `pos_urban_piper` module:
- `pos_urban_piper_enhancements`
- `pos_urban_piper_ubereats`
- Modularized the integration code.
Each model now exposes its own methods for handling UrbanPiper data, such as:
- `get_urban_piper_data` for preparing payloads sent to UrbanPiper.
- Webhook event handlers implemented directly in their respective models:
- Order-related events in `pos.order`
- Store-related events in `pos.config`
- Removed the `product.urban.piper.status` model.
Sync information is now stored in a JSON field: `urbanpiper_synced_json`.
Related: https://github.com/odoo/upgrade/pull/8966
task-[5361075](https://www.odoo.com/odoo/project/1737/tasks/5361075)This pull request updates the tests for the l10n_mx_edi module to align with recent changes in Mexican VAT reporting requirements. This ensures the Odoo Enterprise system continues to accurately handle and validate invoices related to Mexican e-invoicing (CFDI).
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/253922
5 changes
Enhancements to existing features
This update brings the Balance Sheet and Profit & Loss reports for Chinese businesses in line with the latest accounting standards (ASBE and ASSBE). The changes improve report consistency and accuracy, ensuring compliance and reliable financial reporting.
Original PR description
### [IMP] l10n_cn_reports: update BS & PnL We update the Balance Sheet and Profit & Loss reports to be consistent with updated ASBE and ASSBE standards odoo-[251681](https://github.com/odoo/odoo/pull/251681) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) --- We encountered an issue where setting `groupby = False` still resulted in an error (no groupby and children lines). This was resolved by setting a co-dependent variable `user_groupby = False`. The reports has lines with "Includes:" and sibling lines' name are expected to be aligned with it. Hierarchy lines and using various space characters (CJK space `　`, and "en" space ` `) was a maintenance nightmare. We instead chose to remove `includes:` as it's implied by the natural indentation of grouped lines.
Resolved issues and error corrections
This update fixes errors in the Dutch SBR and ICP report exports, specifically correcting incorrect VAT identifiers and date formats. It also cleans up the XML formatting for improved readability, ensuring accurate reporting for tax compliance.
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 resolves an issue where the offer simulation in the payroll module was failing when processing contracts that had already ended. The fix ensures the simulation uses a temporary employee version, preventing errors and accurately calculating potential salaries. This improves the reliability of the payroll process.
Original PR description
### Steps To Reproduce: - Go to Payroll > Employees > Salary Calculator - Choose an employee whose contract already ended. - Boom you got an error(In Simulation) ### Issue: - We were using actual employee's version in simulation. ### Fix: - Instead of using existing employee version, use the temporary created employee's version Task: 5936444
This update restores crucial VAT validation checks within the Belgian tax reporting module. Previously, these checks were bypassed after returns were implemented, leading to potential errors when uploading tax information. Now, the system proactively validates VAT returns, ensuring accurate data and preventing issues with Intervat.
Original PR description
Since the implementation of returns, some VAT checks were no longer being executed. This led to warnings when uploading the XML to Intervat. To catch these issues beforehand, this commit: - Restores the warning checks directly on the report. - Adds a new check on the VAT return that passes only if no warnings are raised. task-5883037
This update corrects an issue where cancelled vendor bills were incorrectly included in the Sweden (l10n_se) SIE export reports. The fix ensures that cancelled transactions are properly excluded, aligning the export data with the general ledger and providing accurate financial reporting. This improves the reliability of the export data for Swedish accounting.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#108767
4 changes
Resolved issues and error corrections
This update ensures that shift notifications are automatically sent to employees in their preferred language, regardless of the user's language settings. Previously, emails were generated in the current user's language, leading to confusion. This fix corrects a technical issue in the Planning module to improve communication clarity.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#109619
This update fixes a test failure related to email notifications in the Google Calendar and Mail modules. The previous test incorrectly checked for empty timeout emails, leading to false positives. The change ensures tests accurately verify that emails are not sent based on message ID, improving test reliability.
Original PR description
No need to always check the timeout email_to always contains formatted emails. task-5152917
This update ensures that all users involved in an appointment booking – including internal staff and organizers – receive a notification, regardless of whether the booking syncs with external calendars. Previously, notifications were limited, leading to a poor user experience. This change simplifies the notification process and ensures everyone stays informed.
Original PR description
In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar. However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account. Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant. As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once. task-5152917 [1]: https://github.com/odoo/enterprise/pull/60913
This update fixes a bug where project timesheets didn't accurately reflect labor costs when changing the employee assigned to a manufacturing order. The fix automatically updates the AAL (analytic accounting line) associated with the work center, ensuring accurate tracking of employee hours and costs within the project dashboard. This improves the reliability of project cost reporting.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321
4 changes
Resolved issues and error corrections
This update fixes a technical issue in Odoo's testing environment related to the demo certificate for Peru's electronic invoicing (PE) requirements. The certificate's lifespan was extended by ten years to ensure accurate testing and compliance with evolving regulations. This change ensures the demo certificate remains valid for future testing scenarios.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058
This update corrects a technical issue where Avatax settings weren't correctly identifying the company they were associated with. Adding the missing 'company_dependent' key ensures Avatax data is accurately linked to the correct company within Odoo. This improves the reliability of Avatax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. task-none
This update resolves a technical issue that caused the restaurant order tour to fail. The fix ensures the system waits for order updates to complete before proceeding, preventing duplicate order transmissions and improving the reliability of the test. This ensures a smoother experience for users placing restaurant orders.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846
This update resolves a memory issue that occurred when running procurement crons with a large number of orderpoints. The change optimizes how orderpoint data is processed, preventing a MemoryError and ensuring these critical tasks complete successfully. This improves the reliability of our inventory management system.
Original PR description
When running the procurement crons with a lot of orderpoints in the database, typically tens of thousands, a MemoryError can get triggered in `_run_scheduler_tasks` thanks to the line `orderpoints_batch._compute_qty_to_order()`. The Orderpoints recordset here is the result of a search in the whole database and can contain thousands of records. This computation puts every prefetched fields and every computed fields into the cache, leading to a MemoryError. In this commit the explicit compute call is replaced by a context key that is used down the stack to call `add_to_compute`. Thanks to the commit at the end of the `_procure_orderpoint_confirm` the cache gets cleared after 1000 orderpoints so the memory is stable and no MemoryError is thrown. Before PR: MemoryError (more than 2GB of `self.env.cache._data`) After PR: Procurement cron terminates without memory error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr