Friday, July 25, 2025
52 changes
16 changes
Resolved issues and error corrections
Point of Sale now only shows the product categories explicitly selected in the restriction settings. This prevents empty child categories from appearing to cashiers when a business chooses to limit visible categories, making the sales screen clearer and less confusing.
Original PR description
## Short functional explanation of the error When a category is the child of another category, it is always displayed, despite specifying in the settings that we don't want to display the child. ##…
## Short functional explanation of the error When a category is the child of another category, it is always displayed, despite specifying in the settings that we don't want to display the child. ## Reproduction Steps 1. Go to settings. In "Product & PoS categories", check "Restrict categories", click on PoS Product Categories and create 2 new categories: a parent category and a child category. 2. Close the settings and go to Products and create 2 different products: one to which you'll assign the parent category and one to which you'll assign the child category. 3. Go back to settings. In "Product & PoS categories", under "Restrict categories", only select the parent category. 4. Go to Point of Sales and click on the parent category. ### Expected behavior Only the parent categories and the parent product should show. ### Unexpected behavior The child category shows, with no products inside. ## Origin of the issue This behavior was previously expected. Therefore, there was a line in pos_category.py that would add to the available categories the children of each available category. opw-4877405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216310
This fix removes line breaks from product descriptions in Italian electronic invoices before they are sent to the SDI tax portal. It prevents invoice submissions from being rejected when a product description contains multiple lines.
Original PR description
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on…
**Steps to reproduce:** 1. Install l10n_it_edi module 2. Create an invoice where the product description includes a newline. 3. Make sure the invoice uses VAT tax. 3. Confirm the invoice. 4. Click on send 5. Only enable Send to Tax Agency. 6. Click "Send" again. 7. Go to the Attach files and download the attachment. 8. Check the `<Descrizione>` (description) in the XML file. **Issue:** The `<Descrizione>` field in the `<DettaglioLinee>` tag includes newline characters, which are not accepted by SDI portal. **Causes:** The line description is using '\n'.join(...), which results in actual newline characters in the XML. https://github.com/odoo/odoo/blob/ca7de6b2fbe4626583b67a34d77bbb523d972f79/addons/account/models/account_move_line.py#L513 https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/l10n_it_edi/models/account_move.py#L316-L324 **Solution:** To fix this, replace newline characters in the description with spaces and Strip leading/trailing whitespace. This ensures SDI receives a single-line <Descrizione>value. **Before fix:**  **After fix:**  Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4808826) opw-4808826 co-authored by: Raj Bhuva (bhra@odoo.com) Forward-Port-Of: odoo/odoo#218168
The editor now again converts links pointing to the same website into shorter internal links, with the option enabled by default. This helps avoid exposing Odoo instance domains in published pages and keeps links cleaner and more portable.
Original PR description
*: html_builder This commit restores the feature (lost during the website builder refactoring [1]) that automatically converts absolute URLs pointing to the origin domain into relative URLs. It also introduces a heuristic to detect links pointing to the user's own Odoo instance domain (e.g., https://mydb.odoo.com/...) and treats them as internal links. In both cases, a checkbox (enabled by default) allows the user to opt into this conversion. Mentioning .odoo.com instance domains (especially one’s own) in published URLs is discouraged and considered bad practice. ex: url: http://localhost:8069/contactus [x] Autoconvert to relative link [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
Improves Greece myDATA e-invoicing by fixing VAT formatting, error handling, PDF generation, and invoice type calculation issues. It also makes setup easier by moving myDATA options into settings and adding sensible default classifications for invoices.
Original PR description
First major fixes and improvements for Greece EDI. task-4781479 Forward-Port-Of: odoo/odoo#218927 Forward-Port-Of: odoo/odoo#209078
This fix prevents IoT boxes from deleting existing drivers when a driver download fails or returns an invalid file. It helps keep connected hardware working even if the linked database is offline or temporarily unavailable.
Original PR description
Before this commit, if the IoT box was connected a DB which then went offline (e.g. expired runbot), and it tried to download drivers, the request would fail but it would still delete the old handlers. After this commit, we avoid this problem in two ways. Firstly, we check that we received an OK HTTP status before trying to process the response body. Secondly, we check that the reponse we have received is a valid zip file BEFORE deleting the old handlers. This way we only delete them if we are sure we have something to replace them with. task-4933638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219271 Forward-Port-Of: odoo/odoo#218163
Fixes an error that occurred when users clicked Indirect Subordinates in an employee's organization chart. This keeps the Employees app navigation reliable and prevents users from being blocked by a crash when viewing reporting relationships.
Original PR description
A traceback occurs when clicking Indirect Subordinates in the Organization Chart of an employee. Steps to reproduce the error: - Install ``hr`` module with demo data - Go to Employees > Open…
A traceback occurs when clicking Indirect Subordinates in the Organization Chart of an employee. Steps to reproduce the error: - Install ``hr`` module with demo data - Go to Employees > Open ``Mitchell Admin`` - In the Organization Chart, click the number next to Mitchell Admin. - Then click Indirect Subordinates. Traceback: ``` TypeError: inconsistent models in: hr.employee(1, 6, 5) - hr.employee.public(5,) ``` In this [commit], ``subordinate_ids`` field was changed to be related to ``employee_id.subordinate_ids``. https://github.com/odoo/odoo/blob/cc65ae3854f845e5cc87cb808c4707279bf28be0/addons/hr_org_chart/controllers/hr_org_chart.py#L89 So, ``subordinate_ids`` now returns records of the ``hr.employee`` model. ``child_ids`` is the records of ``hr.employee.public`` model. So, This leads to a traceback at the above line, where it expects consistent models. [commit]: https://github.com/odoo/odoo/commit/21f18b1a6fdbf1a01c3dda83acfa66addd01a759 sentry-6752005852 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the Employees app could fail for non-admin users when homeworking attendance showed someone as working from the office. This update aligns the public employee view with the same status options as the main employee record, preventing the error and restoring access.
Original PR description
Currently an error occurs when we open Employees app with a non admin account. Steps to replicate: - Install `hr_homeworking` with demo data. - Login with admin and open `Employee > Mitchell Admin`…
Currently an error occurs when we open Employees app with a non admin account. Steps to replicate: - Install `hr_homeworking` with demo data. - Login with admin and open `Employee > Mitchell Admin` form view. - On the Work tab you'll find the seven days of the week, set today's field to 'Office'. (For Ex: If Today is monday so fill in Office for monday). - Now Logout and login through some other account like Marc Demo. Open Employees and you will get the error. Error: `ValueError: Wrong value for hr.employee.public.hr_icon_display: 'presence_office'` This error occurs after a recent [refactor](https://github.com/odoo/odoo/pull/202869) in the code and that time they forgot to add the other values for `hr_icon_display` field. In saas-18.3 [1], the code directly inherited from the base model `hr.employee.base`. However, in saas-18.4 [2], the refactor split the code into `hr.employee` and `hr.employee.public`, only `hr.employee` includes the new selection items, while `hr.employee.public` does not. This caused the wrong value error. [1] - https://github.com/odoo/odoo/blob/aa8b09ca61dfd405ebebbeff4e45a08bf7ad84fd/addons/hr_homeworking/models/hr_employee.py#L8-L24 [2] - https://github.com/odoo/odoo/blob/850e575b71b04597d31140cec53a596456370325/addons/hr_homeworking/models/hr_employee.py#L8-L24 This commit solves this issue by adding the necessary values to the `hr_icon_display` field. sentry-6731346730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project task recipients are now automatically added as followers when a task is shared or when they are contacted through the task chatter. This fixes cases where customers received a share or message but still could not see the task in the portal.
Original PR description
Before this commit, when a task was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the task. As a result, they couldn't see the task in the portal. This commit ensures: - Recipients are now added as followers of the task when it is shared with them through the wizard. - A message to a customer in the chatter also adds them as a follower of the task. task-4781259 Forward-Port-Of: odoo/odoo#220195 Forward-Port-Of: odoo/odoo#211169
This fixes overtime calculations when employees use extra hours for time off. Attendance now counts only the relevant daily overtime entry, preventing duplicate overtime records from distorting extra-hour balances.
Original PR description
When you create an attendance entry it will create an attendance overtime entry corresponding to that day. The relation is used to count the ammount of extra hours in that day. Only one overtime is expected per day in order for it to work properly. The issue arises when you create a time off using extra hours. That will also create an overtime This commit aims to filter the overtimes when counting the extra hours. The same was used before a refactoring that happened in a fix [bc1f2cdf3b8d448c9522311393aad728a33a2404] which aparently removed it. opw-4806193 Forward-Port-Of: odoo/odoo#219435
This fixes Spanish TicketBAI reporting so credit notes created using the differences method show negative amounts where required. It helps ensure invoice corrections, tax totals, and POS-related credit notes are reported accurately to the tax authorities.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220300 Forward-Port-Of: odoo/odoo#217172
Self-service POS orders are now sent to preparation only after payment succeeds when an online or terminal payment method is configured. This prevents unpaid kiosk orders from reaching staff too early, while still allowing mobile self-orders to proceed without payment when no online payment option is available.
Original PR description
pos_self_order*: pos_online_payment_self_order, pos_self_order_adyen, pos_self_order_razorpay, pos_self_order_stripe Ensure self-orders are sent to the preparation display only after a successful payment, when a valid payment method is configured. **Issue 1: Orders sent for preparation before successful payment** **Steps:** - Configure the kiosk with an online or terminal payment method. - Open the kiosk, add products, and proceed to payment. **Issue:** - Preparation orders were being sent even if the payment was not completed. **Fix:** - Restrict preparation flow to only orders with a successful payment when a valid payment method is configured. --- **Issue 2: Orders not sent for preparation in mobile mode without the online method** - Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured. Task-4845410 Related: https://github.com/odoo/enterprise/pull/87173 Forward-Port-Of: odoo/odoo#213493
Fixed an issue in the website editor where pressing backspace after selecting content across paragraphs could remove text beyond the selected area. This helps prevent accidental loss of content while editing pages or rich text.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220163 Forward-Port-Of: odoo/odoo#219392
When a helpdesk ticket is shared or a customer is messaged, those recipients are now automatically added as followers. This ensures they can access the ticket through the customer portal, reducing confusion and follow-up support requests.
Original PR description
Before this commit, when a ticket was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the ticket. As a result, they couldn't see the ticket in the portal. This commit ensures: - Recipients are now added as followers of the ticket when it is shared with them through the wizard. - A message to a customer in the chatter also adds them as a follower of the ticket. task-4781259 Forward-Port-Of: odoo/enterprise#90830 Forward-Port-Of: odoo/enterprise#86169
Chilean electronic factoring files now show the transferred invoice total in Chilean pesos, even when the original invoice uses another currency. This prevents incorrect regulatory XML values and helps ensure AEC files match local reporting requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MntTotal tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on Send Now to SII and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MntTotal is in selected currency which is wrong related: https://github.com/odoo/enterprise/commit/4e97c5d008c2879c5d014203fafc2c125d6c5ae7 opw-4830957 Forward-Port-Of: odoo/enterprise#90232
Self-order kiosk and mobile orders are now only sent to the preparation display after payment succeeds when a payment method is configured. This prevents staff from preparing orders that customers have not paid for, while still allowing mobile unpaid orders when no online payment option is available.
Original PR description
pos_self_order*: pos_online_payment_self_order_preparation_display, pos_self_order_preparation_display Ensure self-orders are sent to the preparation display only after a successful payment, when a valid payment method is configured. **Issue 1: Orders sent for preparation before successful payment** **Steps:** - Configure the kiosk with an online or terminal payment method. - Open the kiosk, add products, and proceed to payment. **Issue:** - Preparation orders were being sent even if the payment was not completed. **Fix:** - Restrict preparation flow to only orders with a successful payment when a valid payment method is configured. --- **Issue 2: Orders not sent for preparation in mobile mode without the online method** - Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured. Task-4845410 Related: https://github.com/odoo/odoo/pull/213493 Forward-Port-Of: odoo/enterprise#87173
This fix prevents errors in Mexico payroll and salary offer calculations when an employee does not yet have an initial contract start date. Payroll now uses safe default values so recruiters and payroll teams can continue salary configuration and payslip calculations without interruption.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613 Forward-Port-Of: odoo/enterprise#90648
6 changes
Resolved issues and error corrections
This fix ensures Spanish TicketBAI credit notes created using the differences method report negative line, tax, and total amounts as required. It helps businesses submit accurate electronic tax documents and avoid reporting inconsistencies.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220300 Forward-Port-Of: odoo/odoo#217172
3 changes
Resolved issues and error corrections
Fixes tax report calculations when invoices use the same tax with different analytic distributions. Businesses will see accurate net/base amounts in grouped tax reports, helping avoid misleading tax reporting figures.
Original PR description
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales…
This fix prevents errors when moving floating orders to another order or table in Point of Sale and Restaurant workflows. Staff can now transfer orders consistently regardless of whether they are tied to a table, reducing interruptions during service.
Original PR description
While transferring a floating order to another or a table, a traceback was raised. Is now possible to transfer orders to anything independent of the table or order type. taskId: 4948719 Forward-Port-Of: odoo/odoo#219236
Fixes an issue in the website editor where pressing backspace after selecting text across paragraphs could delete content outside the selection. This helps prevent accidental loss of nearby content when editing pages or emails.
Original PR description
Problem: Given content like: ``` <p>keep<br>[delete</p> <p>delete<br>delete<br>]</p> <p>keep</p> ``` Pressing backspace removes the last "keep" as well, which is incorrect. Cause: The merge logic uses `range.endContainer` as `joinWith`, but does not account for `range.endOffset`. When `range.endContainer` is a `<p>` with a non-zero offset, the condition `next.previousSibling && next.previousSibling === joinWith` fails. During merging, `next` may go inside `joinWith`, making the logic invalid. Solution: Prevent merging when `next` is positioned exactly at `range.endOffset`, preserving the correct boundary. Steps to reproduce: - Add the sample HTML to the editor - Select from `[delete` to `delete]` - Press backspace -> The final `<p>keep</p>` is deleted incorrectly opw-4905047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220163 Forward-Port-Of: odoo/odoo#219392
Subscription renewals that move customers between recurring plans now calculate commissions using transfer activity, so sales compensation better reflects the plan change. The update also prevents duplicate achievement lines when no currency is set and improves commission report loading performance.
Original PR description
PURPOSE In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs SPECIFICATIONS Take into account transfer logs…
PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs
SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal
Example:
If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)
Current:
Renew in into yearly: 100% of MRR change -16.67 = -$16.67
New monthly 80% of MRR change $100 = $80
Total = 63.33 (modifié)
New
New monthly 80% of MRR change $100 = $80
Transfer 1 : 80% of MRR change -100 = -$80
Transfer 2 : 100% of MRR change +100 = +$100
Contraction of MRR: 100% of MRR change -16.67 = -$16.67
Total = 83.33
Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.
taskid-4783929This fixes an issue where failing part of a quality check could incorrectly mark related receipt moves as picked. The change keeps stock receipt status accurate after quality failures, reducing confusion and preventing incorrect warehouse processing.
Original PR description
Steps to reproduce the bug:
- Create two storable products: "P1" and "P2"
- create a quality control point:
- operation: receipt
- products: “P1” and “P2”
- Failure location: any one
- Create a receipt for 1 unit of P1 and 2 units of P2
- Pass the quality check for P1
- For P2, pass 1 unit and fail the other
Problem:
A new move for P2 is created to the failure location, but as a result, both moves for P2 are marked as picked, whereas the move for P1 is not. Solution:
We shouldn’t mark any move as picked during the quality check.
Partial backport of: https://github.com/odoo/enterprise/pull/77985/commits/48bfc8a860fa4b5b5e9ea153932f34b47bdcec6c
opw-4902059
Forward-Port-Of: odoo/enterprise#90178
Forward-Port-Of: odoo/enterprise#89634Mexico payroll calculations now handle employees who do not yet have an initial contract start date. This prevents salary configurator and payslip errors during recruitment or offer creation, helping payroll processes continue reliably.
Original PR description
Before this fix, various computations relying on `employee.first_contract_date` fails if the value was missing, notably: - `_compute_integration_factor` in payslips - Python expressions in MX salary rules (holiday bonus, ISR, etc.) Steps to reproduce: Install the following modules: - Recruitments, Payroll, Salary Configurator - Mexico - Payroll, Mexico - Payroll - Localisation, EDI for Mexico Go to Recruitment -> create or click on application in any offer -> click on generate offer(create a contract templates if needed) -> Click on Salary Configurator, notice the Invalid Operation Error After fix: - Default the integration factor to 1 and years worked to 0 when no start date exists - Safely guard salary rule conditions and computations with proper checks This ensures robust payroll calculation even for employees without an initial contract date. opw-4853613 Forward-Port-Of: odoo/enterprise#90648
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytic because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/odoo#220394
This fix restores product codes in electronic invoices and ensures barcode identifiers use the required format. It also removes an incorrect bank branch attribute for Peppol BIS3 invoices, helping invoices pass validation and reducing rejection risk.
Original PR description
### [FIX] account_edi_ubl_cii: Add SellerItemIdentification and add tests Before the UBL refactor, the `SellerItemIdentification` node was populated with the product code. We restore this behaviour. In addition, the refactor added the `StandardItemIdentification` node without specifying the `schemeID` (which is required by the schematron), then commit f46c10f03e59e8 added `schemeID="0160"` This commit adds tests to enforce this behaviour. task-none ### [FIX] account_edi_ubl_cii: BIS3 rm FinancialInstitutionBranch/schemeID In BIS3, the `FinancialInstitutionBranch` node should not specify the `schemeID` property. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-655/ This was correct before the UBL refactor but was messed up by the refactor. task-none
Malaysia electronic invoices now place prepaid amounts in the format required by MyInvois. This helps prevent submission issues for invoices involving prepayments and keeps generated documents aligned with local reporting rules.
Original PR description
Before: Prepaid Amount was submitted under LegalMonetaryTotal node, which follows UBL format but not supported for MyInvois. After: Introduced separate PrepaidAmount node used specific to Malaysia to support MyInvois. taskID-4947994 Forward-Port-Of: odoo/odoo#219419