Daily updates from Odoo
Friday, July 25, 2025
39 changes · saas-18.4
Resolved issues and error corrections
This update adjusts an automated test for the Point of Sale sales flow so it uses the correct testing helper. It helps keep quality checks reliable and reduces the chance of false failures blocking releases.
Original PR description
Replace `start_tour` by `start_pos_tour`. Trying to fix runbot error 230078. opw-4819708 Forward-Port-Of: odoo/odoo#220159 Forward-Port-Of: odoo/odoo#219940
Point of Sale sessions now use a custom sequence prefix exactly as configured, instead of adding the shop name in front. This prevents confusing session IDs and makes it easier for staff and administrators to track sessions consistently.
Original PR description
Description of the issue/feature this PR addresses: The sequencing for new PoS Session isn't right when set to another value than the default. Current behavior before PR: The PoS name was added before the intended sequence. For example, if you set the pos.session sequence to TEST/ with the Furniture Shop, it return Furniture ShopTEST/00001. Desired behavior after PR is merged: The PoS Session name should be using only the sequence if the sequence isn't the default one. When the pos.session sequence is set to TEST/ and you open the Furniture Shop, it should return TEST/00001. Steps to reproduce: - change the default sequence prefix for pos.session - open a pos session and Open Register - go to Point of Sale > Orders > Sessions - check the Session ID opw-4822673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212775
This update removes an unnecessary test dependency from the Discuss full test suite. It helps keep automated checks simpler and more reliable without changing any customer-facing behavior.
Original PR description
remove the dependency on `TestPortal` from `test_discuss_full`, as it is not needed. [runbot-226366](https://runbot.odoo.com/odoo/error/226366) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220259 Forward-Port-Of: odoo/odoo#213161
The website event guided tour and its related automated test have been updated to work with the newer website builder. This helps ensure event ticket and question flows continue to be checked reliably after builder changes.
Original PR description
`website_event_tour` tour was broken and disabled after the new website builder changes. This PR adapts the tour steps accordingly and re-enables the related test.
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
Point of Sale test data was adjusted to remove fields that only exist in the Enterprise edition. This helps ensure the tests can run reliably in environments where Enterprise modules are not installed, reducing false test failures.
Original PR description
Remove fields that are declared in enterprise from the Hoot tests in point of sale. This is to ensure that the tests can be run without the enterprise module being installed. Forward-Port-Of: odoo/odoo#220051
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
This update reverts a previous change that caused an automated test tour for creating project sales order lines to fail. It helps keep the sales project workflow validation reliable without changing customer-facing functionality.
Original PR description
This reverts commit bde64f4dd19d30f807142fea6f04409de0696c54. runbot-error-226711 Forward-Port-Of: odoo/odoo#216695 Forward-Port-Of: odoo/odoo#216542
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
A previously disabled website redirect test has been updated to work with the latest website builder changes. This helps ensure website navigation behavior remains reliable during future updates, with no direct change for end users.
Original PR description
`test_01_client_action_redirect` tests was broken and disabled after the new website builder changes. This PR adapts the tour steps accordingly and re-enables the related test.
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
Original PR description
To reproduce: ============= -1 Install Peru accounting -2 Change language to Spanish PE -3 Go to add a new Tax form -4 Change code to ISC -5 Debug mode you will see the selections are not well translated Problem: ======== Translation team requested to change selections translations Solution: ========= Update translations opw-4954487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220353
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
Deleting the checkbox from a checked checklist item now also removes the leftover checkmark. This prevents confusing visual artifacts in edited documents and keeps checklist formatting consistent.
Original PR description
Problem: After commit 02ae5a645a80e6088a596b6273e70b5476e79e88, pressing backspace on a `li` adds the `oe-nested` class. If that `li` is a checked checkbox item, only the checkbox is removed, but the checkmark remains visible. Solution: Always remove the `o_checked` class when converting the list item to `oe-nested`. **After we backspace on checked item:** Before: <img width="975" height="324" alt="image" src="https://github.com/user-attachments/assets/374bf407-25d7-45fa-a84e-0aef72aa3690" /> After: <img width="972" height="366" alt="image" src="https://github.com/user-attachments/assets/33575d7c-ea1c-432c-b4b6-4ce248e2fc78" /> Steps to reproduce: - Add a checklist - Check an item - Press backspace to remove the checkbox -> The checkmark remains visible, even though the box is gone opw-4953981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219838
Mass email notifications now show the properly rendered email subject instead of raw template text in the chatter. This makes sent-email records clearer for users and also includes a temporary fix to avoid duplicate signatures in these messages.
Original PR description
This commit fixes an issue with the notifications sent when the user sends en masse emails with a template. The issue is that the notification logged in the chatter uses the created mailing's display_name, which is computed on the subject of the mailing. This subject is set to a value that is an unrendered inline template. To fix this, the value of the mailing_name in the body of the message is set to the rendered subject if there is a template linked to the composer. The subjects are rendered based on the list of res_ids notified. task-4813503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211409
Fixes an issue where removing broken links through the SEO dialog could accidentally delete protected website content and make the site unusable. This keeps important page elements safe while still allowing users to clean up broken links.
Original PR description
Steps to reproduce: - Open website builder - Site > Pages and delete "contact us" page - Go to home page - Site > Optimize SEO > Check broken links - Remove the broken links "contact us" - Save - Observe : Website is dead, and really dead... Forward-Port-Of: odoo/odoo#220377
This fixes an internal issue where the IoT drivers used an outdated method to identify devices. It helps prevent failures in IoT device handling after recent platform updates.
Original PR description
In a forward port, we missed a call to `helpers.get_mac_address()` which does not exist anymore, as it was replaced by `helpers.get_identifier()`.
Point of Sale category labels now display Chinese names horizontally instead of stacking characters vertically. This makes category navigation clearer for Chinese-speaking users and avoids truncated labels in the POS interface.
Original PR description
**Issue** Using `max-width: min-content `combined with `d-flex` caused Chinese characters to stack vertically, as each character is treated like a word and with a 2-line height, only first two 2 characters were visible **solution:** Switch to grid layout and remove max-width to ensure label width isn't constrained by its content length. opw-4766145 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#210312
Subscription product prices on the website now display currency symbols according to each currency's standard format. This prevents confusion for customers using currencies such as the Euro, where the symbol should appear after the amount.
Original PR description
Issue: The currency symbol was always rendered in front of the amount, which is incorrect for currencies like the Euro (where the symbol comes after the amount). Step to reproduce: - install website_sale_subscription - create a product with currency as Euro (with BE company) - go to "Recurring Prices" tab, enable "Accept One-Time" - Open website from smart button Observation: - pound symbol appears in front of price Fix: Use the appropriate options for the monetary field to render the currency symbol Before: <img width="792" height="221" alt="image" src="https://github.com/user-attachments/assets/8c8424da-2222-455c-880d-a34df7eb16c8" /> After: <img width="823" height="203" alt="image" src="https://github.com/user-attachments/assets/97362df2-cc4a-4be5-b836-e15e47e2313b" /> opw-4943114
Belgian Intrastat XML exports now respect the “Hide lines at 0” option used in the report view. This prevents zero-cost transactions from being included in exported compliance files, keeping the XML output consistent with what users see on screen.
Original PR description
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide…
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide lines at 0'. Doing this will prevent 0 cost transactions from appearing in the report. However, when exporting to XML, such transactions are still displayed. Note: this is related to Belgian companies only. ## Reproduction Steps 1. Go to settings and make sure the company you're operating with is Belgian. Then, in accounting, under the Custmer Invoices section, check the 'Intrastat' option. 2. Go to products and create a new product of type 'Goods'. Then, in the 'Accounting' tab, click on a random commodity code. Set the country of origin as a country belonging to the European Union (for example, Austria). Click on save. You should see a field named 'Intrastat Supplementary Unit Amount' appear. 3. Go to accounting. Click on the 'Vendors' tab and 'Bills'. Click on New. Select a random vendor, and add a line containing the product you just created. Add the column 'Intrastat' and set the corresponding field at '11 outright...'. Then, set a price. In the 'Other Info' tab, set the field 'Intrastat Country' as a random country in the European Union (for example, Australia). Set the fiscal position at 'Import/Export' and set the 'Intrastat Transport Mode' field at '1. Sea transport'. Finally, click on confirm. 4. Duplicate the vendor bill you just created. On this new vendor bill, set the Intrastat at '12 Direct trade...'. Display the column 'Disc.%' and set the field at 100. Then click confirm. 5. Click on the 'Reporting' tab, and under 'Audit Reports', click on 'Intrastat Report'. Set the month to the current month, then click on 'Report: Intrastat(Services....)' and select 'Intrastat (Goods)'. You should be able to see the 2 vendor bills you just created. Click on 'Options' then 'Hide lines at 0': you should see the bill having a 0 cost disappear. Finally, click on the cog on the top left next to 'Intrastat Report' and click on 'XML'. 6. Once the XML file has finished downloading, open it. ### Expected behavior The transaction having a 0 cost shouldn't appear. ### Unexpected behavior The transaction having a 0 cost appears. ## Origin of the issue In the code responsible for the display of the XML report, there isn't any condition responsible for checking if the transaction should be displayed or not. _________________________________________ opw-4464123 --- Forward-Port-Of: odoo/enterprise#90193 Forward-Port-Of: odoo/enterprise#89285
Helpdesk tickets created from the website contact form no longer show an unnecessary description field when no extra fields are present. When the field is shown, its label now follows the visitor's selected language, improving clarity for multilingual users.
Original PR description
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ##…
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ## Reproduction Steps 1. Go to the general settings. Add a language where the term "description" differs from the english word (for example, Spanish). Do the same for the website settings. 2. Go to the website app. Scroll down and change the language. Then, click on the translated "contact us" tab. Fill the form and send the ticket. 3. Go to the helpdesk app and open the ticket you just created. ### Expected behavior The description field shouldn't show, as it appears in the description page. The field should only show if there are additional fields on the "contact us" page. ### Unexpected behavior The description field shows, untranslated. ## Origin of the issue In the ticket code, the field.name is used, instead of the field .field_description, which is translatable. Moreover, there isn't a condition checking if the field should appear or not. -- opw-4876726 Forward-Port-Of: odoo/enterprise#88913
This update makes automated checks for report editing in Studio more dependable by replacing a fragile scroll timing check with a more robust wait. It helps reduce intermittent test failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
Linked tests: - `test_add_field_blank_report` - `test_field_placeholder` These tests contained scroll-related indeterminacies that caused them to fail from time to time. This was due to the fact that we were modifying the scroll and we used this code to make sure it was done: ```js await new Promise(requestAnimationFrame); ``` However, sometimes this wasn't enough, so we now use `waitUntil`, which is more robust https://runbot.odoo.com/odoo/runbot.build.error/181989 runbot-181989 Forward-Port-Of: odoo/enterprise#90806
This change moves Point of Sale configuration tests into the Enterprise POS module where the related features belong. It helps keep automated checks aligned with the correct product area, reducing build issues without changing user-facing behavior.
Original PR description
move tests for POS configuration settings from point_of_sale to pos_enterprise refer to this commit :https://github.com/odoo/odoo/pull/215611/commits/0074d743451834424706608fc76f32b0df9c5f1c build_error-227602 Forward-Port-Of: odoo/enterprise#89351 Forward-Port-Of: odoo/enterprise#88742
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
Installing the Partner Commission module no longer fails if the default Services product category was previously deleted. The setup now leaves the category blank when it is unavailable, helping businesses avoid an installation blocker.
Original PR description
Currently, a ParseError is arising when the user installs the `partner_commission` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently, a ParseError is arising when the user installs the `partner_commission` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `partner_commission` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/partner_commission/data/data.xml:3, somewhere inside <record id="product_commission" model="product.product">
<field name="name">Commission</field>
<field name="purchase_ok" eval="True"/>
<field name="categ_id" ref="product.product_category_services"/>
<field name="type">service</field>
</record>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6754387015
Forward-Port-Of: odoo/enterprise#90598Chilean 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
This fix ensures AI-related email templates update correctly even when Odoo is used in languages other than English. It prevents template customization failures caused by translated text, improving reliability for multilingual users.
Original PR description
Texts are translated before template compilation so xpaths that depend on text content fails on odoo instances that use language aside from EN. We are now searching for the div inside the content page beside the attachment_ids field to find the div to replace. OPW: 4964821
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
The Belgian certified POS setup now shows the correct cash rounding requirement in its validation message. This prevents confusion by stating that rounding must be set to 0.05 with HALF-UP/Nearest behavior, and includes updated translation entries.
Original PR description
The message `"The rounding method must be set to 0.5 and HALF-UP"` was wrong in `pos_blackbox_be/models/pos_config.py`
```py
def _check_cash_rounding(self):
if not self.cash_rounding:
raise ValidationError(_("Cash rounding must be enabled"))
if (
self.rounding_method.rounding != 0.05
or self.rounding_method.rounding_method != "HALF-UP"
):
raise ValidationError(
_("The rounding method must be set to 0.05 and HALF-UP")
)
```
It should be `"The rounding method must be set to 0.05 and HALF-UP"` as indicated in that documentation :
https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/belgium.html?highlight=blackbox#certified-pos-system
It's the same for 18.0
I also added the field for translation into `pos_blackbox_be.pot`
opw-4862967
Forward-Port-Of: odoo/enterprise#90321
Forward-Port-Of: odoo/enterprise#87496The AI resources banner now appears correctly when no documents are provided. This prevents unnecessary processing and gives users clearer feedback sooner.
Original PR description
Fixed displaying resources banner if no docs provided to stop before running the computation query. Forward-Port-Of: odoo/enterprise#89432
Zero-cost point-of-sale orders in Brazil now include the required payment information when sent for electronic invoicing. This prevents Avalara submission errors and helps businesses issue invoices successfully even when an order has no amount due.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094 Forward-Port-Of: odoo/enterprise#90724