Daily updates from Odoo
Navigate
Branch
Wednesday, October 15, 2025
232 changes
23 changes
Enhancements to existing features
Opening the analytic distribution popup on invoice lines with many accounts now avoids unnecessary repeated data requests. This makes the popup load more smoothly and reduces waiting time for users working with complex analytic allocations.
Original PR description
Currently opening the analytic distrubtion popup on an invoice line creates N network requests per account set on the line. Steps to reproduce ----- 1. Edit the analytic distribution on an invoice line and add a lot of accounts 2. Open the popup again 3. A lot of web_read requests are made Issue ----- The display_name for the account and currency is not being passed to the field values in recordProps(), resulting in another fetch when each Field element is rendered. Solution ----- Pass account.accountDisplayName. The display name for the currency is actually not initially loaded by the client, but since that field is invisible, we can safely use an empty string. opw-5106219 Forward-Port-Of: odoo/odoo#231342
A new automated test was added to verify a specific India tax calculation scenario where two similarly configured included taxes should produce equal amounts. This helps reduce the risk of future accounting calculation regressions without changing user-facing behavior.
Original PR description
Added a missing test case in India tax computation, where both taxes have the same configuration as below: - amount: same for both taxes - price_include: True - include_base_amount: True - is_base_affected: False In this case, both tax amounts should be equal. This commit ensures that scenario is properly covered in the test suite. Forward-Port-Of: odoo/odoo#231364
This update prepares Belgian POS blackbox communication for a future queue mechanism by adding a required IoT action and prompting users to update their IoT setup. It helps ensure POS installations are ready for the next improvement that will make blackbox communication more reliable.
Original PR description
This commit is the first of two which will introduce a queue mechanism in the communication between the POS and the blackbox. This commit adds an action to the iot and invites users to update their iot to be prepared for the next commit which will effectively add the queue mechanism and use the new action. Second part: https://github.com/odoo/enterprise/pull/90747 Forward-Port-Of: odoo/enterprise#96639
Resolved issues and error corrections
Combo products now print correctly when a point of sale uses separate preparation printers by product category. Each printer shows the combo title and only the relevant child items for its category, reducing preparation mistakes and duplicate kitchen/bar tickets.
Original PR description
Before this commit: =================== - When using separate printers for product categories, combo products were not printed correctly. - All child products of a combo were sent to every printer, regardless of their category. After this commit: ================== - Combo products are now handled properly in preparation tickets. - Each printer will print the combo product title along with only the child products that belong to its assigned category. Task: 5056115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230982 Forward-Port-Of: odoo/odoo#225658
The privacy lookup now checks for an invalid email address before starting the search. Instead of showing a technical database error, users receive a clear validation message, making the feature more reliable when contact data is incomplete or incorrect.
Original PR description
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address. **Steps to reproduce:** - Install CRM modules. - Create a new contact with an invalid email…
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address.
**Steps to reproduce:**
- Install CRM modules.
- Create a new contact with an invalid email address (missing @ - e.g; `demo`).
- In the contact form, click the gear icon and select "**Privacy Lookup**".
- Click on "**Lookup**" button.
**Error:**
```
UndefinedFunction
operator does not exist: character varying = boolean
LINE 55: WHERE email_normalized = false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Cause:**
Here, Execution of the query fails because `email_normalized` is set to a Boolean value, which is being computed at [1]. And method `tools.email_normalize` returns `False` for invalid email inputs - [2].
**Fix:**
This commit raises an error if the email address is invalid before executing the query.
A similar case is already handled in the mail blacklisting module. ([Ref](https://github.com/odoo/odoo/blob/c7f86c3250c59130ae0b95c6847050d3a6fc7a6d/addons/mail/models/mail_blacklist.py#L29-L31)):
[1] - https://github.com/odoo/odoo/blob/e6c0e963c5379ba7ad8da00ba4ea6c2bb259d95c/addons/privacy_lookup/wizard/privacy_lookup_wizard.py#L49
[2] - https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/odoo/tools/mail.py#L734-L735
sentry-6881416673
Forward-Port-Of: odoo/odoo#227697Fixed an issue where the point of sale screen could keep showing a QR payment prompt after the customer had already paid. Staff can now close the payment popup and continue without running into order finalization errors.
Original PR description
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup…
*: pos_online_payment_self_order Before this commit: =============== - When paying with a QR code, the screen kept showing the QR code even after the payment was completed. - Closing the QR popup manually and performing another action resulted in a `Finalize order` error. - This happened because the WebSocket handler flow were not updating the order state properly. After this commit: =============== - Ensure the frontend refreshes payment status directly from the server when the current order is updated. - Remove unnecessary synchronization calls to prevent stale state. - The order is now correctly marked as paid, and no finalize error occurs after closing the QR popup. Issue: =============== - The frontend WebSocket handler for `ONLINE_PAYMENTS_NOTIFICATION` was fetching the full `pos.order` unnecessarily, because the order state is already updated by another WebSocket flow. - `notify_synchronisation` in the self order flow was redundant, as updates are already handled in the `pos_self_order` module’s `pos.order` file. Task - 5107009 Forward-Port-Of: odoo/odoo#229847
Changing a user's locale can alter which day is treated as the first day of the week. This fix reloads spreadsheet pivot data after a locale update so day-of-week groupings continue to show accurate values.
Original PR description
Chaning the locale can change the first day of the week. But the normalization of the server value depends on this `locale.weekStart`, se we need to reload the pivot when the locale changes, otherwise we might display wrong values for a "day_of_week" grouping. Task: [5149508](https://www.odoo.com/web#id=5149508&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#231337 Forward-Port-Of: odoo/odoo#230949
Accounting users limited to a company branch can now use accounts from the parent company when creating journal entries. This prevents blocked accounting workflows where no accounts appeared available despite the user having the appropriate branch accounting access.
Original PR description
**Steps to reproduce:** - Install accountant - Create a company branch for a company - Create a non-admin user with Accounting rights and access to the branch only - Connect with the created user - Go to "Accounting / Accounting / Journal Entries" - Create a journal entry and try to set an account on a line **Issue:** There is no account available. The accounts from the parent company should be selectable. **Cause:** The accounts are searched with a "parent_of" domain on "company_ids" field, which is a many2many field. However, as the user doesn't have access to the parent company, the parent company is excluded from the search when parsing the domain. opw-5096437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231352 Forward-Port-Of: odoo/odoo#230797
Fixed an issue in Point of Sale where quick-add payment buttons like +10 or +50 could calculate dramatically incorrect amounts for users whose language uses a comma as the decimal separator. This prevents overcharged payment entries and makes checkout totals reliable across localized databases.
Original PR description
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The…
**Steps to reproduce:** - Set your database in a language with a "," as a decimal separator, such as French - Make a purchase, chose a payment method - Before paying, click any +10/20/50 button - The price will be multiplied by 100, then add the desired amount **Why the fix:** There were two places where the decimal separator was causing issues. First when we try to get the current price, *currentBufferValue*, we try to get it when it's in float state, but as we have a language with a decimal separator set as "," the "." in this float will be ignored, and we will take the decimal as units as well, explaining the *100 amount, because the decimals become whole numbers. Secondly, when we try to make the addition of the two and convert it to string again, the *toString* method will convert it with a default "." not taking the current decimal separator into account. Once again, the "." will be ignored later on, leading to an even more over the top number. We now convert the numbers and the strings using the correct decimal separator. opw-5126224 Forward-Port-Of: odoo/odoo#229735
This fix makes reconciliation models accessible when using Invoicing, preventing accounting workflows from getting stuck. It also cleans up confusing views related to creating reconciliation model lines, making the experience smoother for users.
Original PR description
Currently flows are stuck if you don't have the models. And some views are really weird (create a reconciliation model line). 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#230775
IoT users and administrators can now open IoT screens without needing Point of Sale access when the POS IoT module is installed. POS-related options are only shown or used for users with the right POS permissions, preventing unnecessary access errors.
Original PR description
Before this commit, if an IoT user/admin attempted to access any IoT view while `pos_iot` was installed, they would get a permission error if they were not also a POS user. After this commit, we check if the user is in a POS group before showing any POS related fields. We also check the group when autoconfiguring a new IoT box with a POS, this feature will simply be skipped if the user cannot access POS.
This fix ensures that accounting reports stay available only to the appropriate accounting users. It helps preserve the intended access boundaries for financial reporting in the journal dashboard.
Original PR description
Forward-Port-Of: odoo/enterprise#96731
Odoo now handles auto-forwarded emails more accurately when matching email aliases. This prevents unrelated recipients from being automatically added as followers, reducing notification noise and keeping follower lists cleaner.
Original PR description
Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if…
Sending an email that was auto-forwarded would lead to the recipient line having two different emails which would cause any emails that were not set up as aliases to be added as followers even if local part detection was enabled in the alias settings. This was due to the fact that partner detection was changed in 18.2 and now looked for exact email to alias matches. Ban emails were passed to the _find_or_create_from_emails and then directly matched to the emails in the list of recipient emails. When a match was not found for emails that did not have an exact matching alias_full_name, we would then look for or create a partner for that email. This caused erroneous followers to be added. Changing the functionality to also look for matching local parts in order to skip partner finding and creation reverts this functionality to how it previously worked where extra recipients with matching local parts when local part detection was enabled would not add those partners as followers. opw-4896074 Forward-Port-Of: odoo/odoo#230004 Forward-Port-Of: odoo/odoo#216737
This fixes lunch cart behavior so placing a new order for a product only increases the quantity of the matching item still marked "To order". Already ordered items are no longer changed by mistake, keeping order quantities accurate for users and lunch administrators.
Original PR description
**Issue**
When a user has two instances of the same product in their lunch cart, one with state "To order" and one with state "Ordered", and places a new order for that product, both the "To order" and "Ordered" records have their quantity incremented. Only the "To order" record should be updated.
**Steps to Reproduce**
- Add two lunch orders for the same product: one with state "To order" and one with state "Ordered".
- Place a new order for the same product.
- Observe that both records ("To order" and "Ordered") have their quantity incremented.
**Root Cause and Changes Made**
The _find_matching_lines method does not restrict the search to orders with state "new" ("To order"). As a result, it returns all matching records for the product, regardless of their state. When update_quantity is called, it updates the quantity for all these records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228712The Shop Floor “Add Operator” action now uses the public employee list instead of private employee records. This prevents access warnings for users who are not allowed to view private employee profiles, keeping operator assignment smoother while respecting employee privacy rules.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702 Forward-Port-Of: odoo/enterprise#96745
This fix ensures Odoo Studio edits are based on the correct main view instead of accidentally inheriting from a secondary extension view. It helps prevent Studio customizations from being attached to the wrong view structure, reducing unexpected behavior when editing screens.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#96636 Forward-Port-Of: odoo/enterprise#94747
This change moves a required payment method field into the core accounting module so SEPA direct debit can install or update reliably even when the separate payment app is not installed. It prevents setup failures for businesses using direct debit features and keeps accounting workflows available.
Original PR description
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from…
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module. I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)). Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" /> Here’s the screenshot after changing to this commit <img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" /> [OPW](https://www.odoo.com/es_ES/my/tasks/5139827) [PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477) @moduon MT-12067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231052
Point of Sale loyalty rewards now only grant points when an order meets the program's minimum item requirements. This prevents customers from receiving points incorrectly or losing excessive points when redeeming a free product.
Original PR description
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative…
Loyalty points were not being awarded correctly for some orders. The system granted points even when the minimum required quantity of items was not reached. In some cases, it also added negative loyalty points, which led to an excessive deduction for the customer —sometimes just for claiming a single free product. > Setup of the Loyalty Program (Discount & Loyalty): Program Type : Loyalty Card Rule : minimum 5 items => 10 Loyalty Points per $ Reward : Free product (Simple Pen) => in exchange of 5 Loyalty Points Steps to reproduce: ------------------- * Open the pos Shop * Select a customer with loyalty points * Add a Simple Pen * Click on * Reward > Free Product - Loyalty Program > Observation: Customer shouldn't 'win' points here New Total is mathematically correct but not logic Why the fix: ------------ We need to verify that the order is eligible to generate reward points based on the configured rules, before adding the won points. opw-4914774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231056 Forward-Port-Of: odoo/odoo#221570
This fixes a point display issue in the point-of-sale loyalty flow. When staff refresh the receipt screen, loyalty points are recalculated so customers see consistent and accurate balances.
Original PR description
Before this commit: --------- - Loyalty points are not recalculated when the receipt screen is refreshed. After this commit: ---------- - Ensures that loyalty points are properly recalculated when the receipt screen is refreshed, preventing inconsistencies in displayed points. task-5106892
Document upload request emails now greet the person being asked to provide the document, instead of incorrectly using the sender or document owner's name. Invitation and reminder emails are also sent in the requestee's language, making communications clearer and more personal.
Original PR description
Currently, the email template inviting a user to upload a document displays the document owner's name in the greeting instead of the requestee's. This commit updates the template to display the correct name. Steps to reproduce: 1. Log in as Mitchell Admin 2. Go in the Document app 3. Click on the New > Request 4. Enter a document name and select Joel Willis as requestee 5. Send the request by clicking on the "Request" button => The invitation email is correctly sent to Joel Willis but it says "Hello Mitchell Admin" instead of "Hello Joel Willis" Additionally, this PR ensures that the reminders and the invitation emails are sent in the requestee's language rather than the sender's. Task-5130591 Forward-Port-Of: odoo/enterprise#96941 Forward-Port-Of: odoo/enterprise#96161
Reverse charge taxes can no longer be configured as included in displayed prices, and the tax calculation will always treat them as excluded. This prevents incorrect tax handling and keeps accounting results consistent for affected transactions.
Original PR description
After this commit, you no longer can set a custom "price_include_override" on a tax using the UI. Even if you do, the tax engine forces such tax to be price-excluded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231384
This change removes an unreliable automated test assertion in Discuss call testing that could fail unpredictably depending on mobile detection. It helps keep validation runs stable without changing the actual user experience.
Original PR description
Before this commit ([1]), we were testing the absence of a button for mobile, but the test can lead to undeterministic behavior as `isMobileOS` is not reactive as we do not expect a live transition of userAgent, like from desktop to mobile, so testing for this behavior is not useful. A dedicated test for call mobile was introduced in v19 ([2]) https://runbot.odoo.com/odoo/runbot.build.error/233350 [1]: https://github.com/odoo/odoo/pull/177374 [2]: https://github.com/odoo/odoo/pull/218119 Forward-Port-Of: odoo/odoo#231191
Features or functions removed from Odoo
Unused WhatsApp demo data has been removed because it conflicted with test data and did not provide practical value. This helps keep the module cleaner and reduces the chance of false errors during testing or validation.
Original PR description
Conflicts with test data, and according to tde these demo data make no sense as they do nothing useful. Closes #86194 https://runbot.odoo.com/odoo/error/223071
14 changes
Enhancements to existing features
Opening the analytic distribution popup on invoice lines with many analytic accounts now avoids unnecessary repeated data requests. This improves responsiveness for users working with detailed analytic allocations, especially on larger invoices.
Original PR description
Currently opening the analytic distrubtion popup on an invoice line creates N network requests per account set on the line. Steps to reproduce ----- 1. Edit the analytic distribution on an invoice line and add a lot of accounts 2. Open the popup again 3. A lot of web_read requests are made Issue ----- The display_name for the account and currency is not being passed to the field values in recordProps(), resulting in another fetch when each Field element is rendered. Solution ----- Pass account.accountDisplayName. The display name for the currency is actually not initially loaded by the client, but since that field is invisible, we can safely use an empty string. opw-5106219 Forward-Port-Of: odoo/odoo#231342
A new automated test checks a specific India tax setup where two matching included taxes should produce equal amounts. This helps prevent future tax calculation regressions and improves confidence in accounting accuracy.
Original PR description
Added a missing test case in India tax computation, where both taxes have the same configuration as below: - amount: same for both taxes - price_include: True - include_base_amount: True - is_base_affected: False In this case, both tax amounts should be equal. This commit ensures that scenario is properly covered in the test suite. Forward-Port-Of: odoo/odoo#231364
Updates point of sale and IoT-related browser requests so local devices such as IoT boxes and customer displays continue to connect as Chrome introduces stricter local network access rules. This helps avoid disruption for businesses using local hardware with Odoo POS after upcoming browser changes.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/96850 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This commit simply adds this change where appropriate. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231468 Forward-Port-Of: odoo/odoo#231014
This update prepares Odoo Point of Sale IoT connections for upcoming Chrome Local Network Access restrictions. It helps ensure local IoT devices can still be reached from secure Odoo sessions when using the odoo-iot domain, avoiding disruption for businesses using connected hardware.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/231014 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This PR simply adds this change where appropriate. As part of this we have also backported the change from jquery -> fetch. task-5157145 Forward-Port-Of: odoo/enterprise#97124 Forward-Port-Of: odoo/enterprise#96850
Resolved issues and error corrections
Payroll work entry generation no longer fails when a fully flexible employee has overlapping sick leave and a public holiday. This prevents blocking errors during payroll preparation for companies using flexible schedules and overlapping leave scenarios.
Original PR description
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry…
**Issue:** Multiple errors occur when processing payroll for "Fully Flexible" employees and overlapping leave scenarios: 1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation when sick leave overlaps with public holiday **Steps to Reproduce:** 1. Go to the **Employees** app and create a new employee. * Set the working hours to **empty (fully flexible)**. 2. Go to **Contracts** and create a new contract. * Set the **Work Entry Source** to *Attendance*. * Save and make the contract **Running**. 3. Go to **Time Off** → **New**, and create a sick time off for the employee. * Example: from **25th to 29th**. * Approve the time off. 4. Go to **Configuration** → **Public Holidays**, and create a new public holiday. * Example: **27th**, which overlaps with the sick time off. * Work Entry Type = **Paid Time Off**. 5. Go to **Payroll** → **Work Entries**. * A **traceback** occurs. **Root Causes:** - In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types. **Fix:** - Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types This resolves payroll blocking issue for deployments using the Fully Flexible employee feature, where employees may have overlapping leave types and no assigned working calendar. Test : [PR](https://github.com/odoo/enterprise/pull/93902) opw-4979974 Forward-Port-Of: odoo/odoo#223448
The privacy lookup process now detects invalid email addresses before running the search. This prevents a technical crash and gives users a clearer error when contact data needs correction.
Original PR description
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address. **Steps to reproduce:** - Install CRM modules. - Create a new contact with an invalid email…
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address.
**Steps to reproduce:**
- Install CRM modules.
- Create a new contact with an invalid email address (missing @ - e.g; `demo`).
- In the contact form, click the gear icon and select "**Privacy Lookup**".
- Click on "**Lookup**" button.
**Error:**
```
UndefinedFunction
operator does not exist: character varying = boolean
LINE 55: WHERE email_normalized = false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Cause:**
Here, Execution of the query fails because `email_normalized` is set to a Boolean value, which is being computed at [1]. And method `tools.email_normalize` returns `False` for invalid email inputs - [2].
**Fix:**
This commit raises an error if the email address is invalid before executing the query.
A similar case is already handled in the mail blacklisting module. ([Ref](https://github.com/odoo/odoo/blob/c7f86c3250c59130ae0b95c6847050d3a6fc7a6d/addons/mail/models/mail_blacklist.py#L29-L31)):
[1] - https://github.com/odoo/odoo/blob/e6c0e963c5379ba7ad8da00ba4ea6c2bb259d95c/addons/privacy_lookup/wizard/privacy_lookup_wizard.py#L49
[2] - https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/odoo/tools/mail.py#L734-L735
sentry-6881416673
Forward-Port-Of: odoo/odoo#227697A regression test was added to ensure work entries can be generated when a flexible employee has overlapping absences, such as sick leave and a public holiday. This helps prevent payroll or attendance processing errors from returning in future updates.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#93902
Accounting users limited to a company branch can now access and select the appropriate accounts from the parent company when creating journal entries. This prevents blocked accounting work caused by accounts appearing unavailable for branch-only users.
Original PR description
**Steps to reproduce:** - Install accountant - Create a company branch for a company - Create a non-admin user with Accounting rights and access to the branch only - Connect with the created user - Go to "Accounting / Accounting / Journal Entries" - Create a journal entry and try to set an account on a line **Issue:** There is no account available. The accounts from the parent company should be selectable. **Cause:** The accounts are searched with a "parent_of" domain on "company_ids" field, which is a many2many field. However, as the user doesn't have access to the parent company, the parent company is excluded from the search when parsing the domain. opw-5096437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231352 Forward-Port-Of: odoo/odoo#230797
Point of Sale receipts, customer displays, and self-order payment pages now create QR codes directly in the browser instead of relying on the server. This helps stores continue printing receipts with QR codes even when the POS is offline and keeps receipt layouts consistent.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from creating new workplace entries directly from the Swiss payroll contract screen when that shortcut could cause an error. Users can still select existing workplaces, reducing interruptions during HR contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
The Shop Floor "Add Operator" action now uses the public employee list, so users without access to private employee profiles can still add operators. This prevents unnecessary access warnings and keeps manufacturing work order flows running smoothly.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702 Forward-Port-Of: odoo/enterprise#96745
When customers add more of a lunch product, Odoo now updates only the pending "To order" cart line instead of also changing already ordered lines. This prevents accidental quantity changes to confirmed lunch orders and keeps cart totals accurate.
Original PR description
**Issue**
When a user has two instances of the same product in their lunch cart, one with state "To order" and one with state "Ordered", and places a new order for that product, both the "To order" and "Ordered" records have their quantity incremented. Only the "To order" record should be updated.
**Steps to Reproduce**
- Add two lunch orders for the same product: one with state "To order" and one with state "Ordered".
- Place a new order for the same product.
- Observe that both records ("To order" and "Ordered") have their quantity incremented.
**Root Cause and Changes Made**
The _find_matching_lines method does not restrict the search to orders with state "new" ("To order"). As a result, it returns all matching records for the product, regardless of their state. When update_quantity is called, it updates the quantity for all these records.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228712Odoo Studio now bases edited views on the correct main view instead of an intermediate inherited view. This prevents incorrect customizations and helps ensure Studio changes behave as expected for users.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#96636 Forward-Port-Of: odoo/enterprise#94747
This change prevents SEPA direct debit installation or updates from failing when the optional Account Payment module is not installed. It moves a shared payment method field into the core Accounting module so related payment screens can load reliably.
Original PR description
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from…
Odoo 18 have an error, the view `account_sepa_direct_debit.account_payment_register_form_inherit_account_sepa_direct_debit` (Enterprise) references the field `payment_method_code` from `account.payment.register`. This field is added to the model in the `account_payment` module, which is not among the dependencies of `account_sepa_direct_debit`. This means that if the `account_payment` module is not installed, the installation/update of `account_sepa_direct_debit` will also fail. To avoid this error, the field `payment_method_code` in the `account_payment` module needs to be defined instead in the `account` module. I open this PR on the recommendation of @hupo-odoo ([comment](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477)). Here’s a screenshot of the error (runbot) <img width="1498" height="857" alt="runbot_account_sepa_direct_debit" src="https://github.com/user-attachments/assets/e8d66a96-59a3-4cf3-857b-e07a3337338c" /> Here’s the screenshot after changing to this commit <img width="1594" height="725" alt="image" src="https://github.com/user-attachments/assets/ea2fbe2c-31b8-4d61-8cf2-00e003ec3587" /> [OPW](https://www.odoo.com/es_ES/my/tasks/5139827) [PR enterprise](https://github.com/odoo/enterprise/pull/96254#pullrequestreview-3310607477) @moduon MT-12067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231052
5 changes
Resolved issues and error corrections
A regression test was added to ensure payroll work entries continue to be generated correctly when a fully flexible employee has overlapping absences, such as sick leave and a public holiday. This helps prevent a previous error from returning and improves reliability for attendance-based payroll processing.
Original PR description
**Purpose:** Add regression test to verify that overlapping leave scenarios (sick leave + public holiday) do not cause singleton errors for fully flexible employees using attendance-based work entries. **Test Coverage:** - Fully flexible employee with no calendar assignment - Attendance-based work entry source configuration - Overlapping sick leave and public holiday scenario - Work entry generation and validation without singleton errors Related : [PR](https://github.com/odoo/odoo/pull/223448) opw-4979974 Forward-Port-Of: odoo/enterprise#93902
This update prevents users from creating a new workplace directly from the contract workplace field when that shortcut could trigger an error. Users can still select existing workplaces, reducing interruptions when managing Swiss payroll contracts.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
The Shop Floor "Add Operator" action now uses the public employee list instead of private employee profiles. This prevents access warnings for users who are not allowed to view private employee data, making operator selection work smoothly while respecting privacy rules.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702 Forward-Port-Of: odoo/enterprise#96745
This fix ensures that views created or edited in Odoo Studio inherit from the correct primary view instead of an intermediate extension view. This helps prevent unexpected Studio customization behavior and makes view editing more reliable for users.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#96636 Forward-Port-Of: odoo/enterprise#94747
Project budget totals now use the same color logic as individual budgets, including expense budgets entered as positive amounts. This makes dashboard and project card budget indicators easier to trust and prevents misleading status colors.
Original PR description
#### Issue: - Color for project budget and total project budgets are inconsistent #### Step to reproduce: - In Settings: - activate Project > Timesheet - activate Accounting > Budget Management - Create a project - Go to Dashboard - Add a budget of type 'Expense' - Add a line with a positive amount #### Current Behavior: - Color for the budget is correct - Color for the total budget is wrong #### Expected behavior: - Color for the budget and total budget are consistent While computing budget color, expense budget are dealt as if they were negative. Therefore having a positive amount for purchase order result in some problem on the color of the total of different budgets. This commit creates temporary variables to compute progress of the global budget. Project cards in kanban view use the `total_budget_progress` field, so it also needed to be updated the same way. opw-4812468 Forward-Port-Of: odoo/enterprise#93221
24 changes
New functionality added to Odoo
Belgian accounting users can now connect journals to Codaclean through Odoo's IAP service to automatically or manually fetch CODA bank files. This reduces manual bank statement handling, with a small backport fix ensuring imports safely stop when no CODA files are provided.
Original PR description
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server.…
This module adds support for "codaclean" integration. CODA files can be periodically (or on demand) fetched from codaclean and imported into bank journals. The module only connects to the IAP server. The IAP side does the actual calls to codaclean (with a secret API key). To use the module you have to create a connection to IAP / codaclean and set up a bank journal: - To manage the connection to IAP / codaclean go to Settings -> Accounting -> Codaclean -> Manage Connection - To set up the bank journal you need to configure the following in the "Journal Entries" tab on the journal: - Put the IBAN in the "Bank Account Number" field - Select "Codaclean Synchronization" for the "Bank Feeds" field Coda files will be automatically fetched 2 times per day via the scheduled action called "Accounting: Sync Coda Files from Codaclean". They can also be manually fetched by clicking "Fetch from Codaclean" below the journal on the accounting dashboard (only available when the journal and connection are setup correctly). On an empty journal we start fetching from 1 year ago. When the journal is not empty we start fetching after the last bank statement / bank statement line in the journal. task-4844423 backport of commit 518ab9e Forward-Port-Of: odoo/enterprise#96903 Forward-Port-Of: odoo/enterprise#95747
Enhancements to existing features
Austrian POS companies with an email address will now automatically receive an invitation to access their Fiskaly dashboard. If the company email changes, a new invitation is sent, and Fiskaly organization details stay updated even while authentication is pending.
Original PR description
In this commit: ------------------ - If a company email is set in the company information, we send an invitation to that email, allowing the user to access their company data on the Fiskaly dashboard by logging in using the company email. - If the email is later updated, access invitation will automatically be sent to the new email. - If the fiskaly organization exists, we should update the organization data even if the authentication is remaining to keep the data uptodate. Related PR: https://github.com/odoo/iap-apps/pull/1098 Task: 4881786 Forward-Port-Of: odoo/enterprise#88106
Online orders handled through Urban Piper are now protected from manual deletion in the point of sale. This keeps order records aligned with the normal restaurant workflow, where such orders should be cancelled by the aggregator or rejected by the restaurant instead.
Original PR description
Before this commit: =================== - We were able to delete online orders, but generally, online orders are either cancelled by the aggregator or rejected by the restaurant. After this commit: ================== - Online orders can no longer be deleted. Task: 496669 Forward-Port-Of: odoo/enterprise#95074
The AI and WhatsApp features now use a more direct way to open or retrieve chat conversations. This keeps the messaging experience aligned with the main chat system and helps maintain consistency across Odoo communication tools.
Original PR description
This commit updates all calls to getOrFetch to use the method from the discuss.channel model directly. PR community: https://github.com/odoo/odoo/pull/231203
The automated tests for avatar cards were updated to rely on stable class names instead of page structure. This helps reduce false test failures when the avatar card layout changes, supporting smoother future updates without changing the user experience.
Original PR description
Update the user info selector in avatar card tests to use the class names. This will simplify future changes to the avatar card. The tests will be less likely to break if the structure of the avatar card changes, as long as the class names remain the same. pre task of task-4107790 https://github.com/odoo/odoo/pull/231639
The salary configurator sidebar now has better spacing between field labels and their tooltip icons. This small visual improvement makes the interface cleaner and easier to read for users configuring salaries.
Original PR description
In the salary configurator sidebar some fields have a tooltip to explain how the value is calculated, the icon for that tooltip had no margin between itself and the label. This commit adds a margin between them to make it more visually pleasing. Task ID: 5138530 Forward-Port-Of: odoo/enterprise#96483
Peruvian electronic invoices can now include the required withholding reference when selling to customers classified as withholding agents. This helps businesses comply with local invoicing rules by reflecting the total withholding amount correctly in the XML without affecting invoice totals.
Original PR description
Some customers in Peru are considered "agentes de retención", and as such have special considerations that are necessary. We must perform specific actions when working with these customers, when selling to them we must: - recieve a specific document from the customer (A followup task will add this support for companies to generate this document) - Include a retention reference in our XML. This is represented as a specific `AllowanceCharge` node that is the sum of all of the Withholding taxes on the lines with the specific code of 62. We know an invoice is to a withholding customer because all lines must have a tax that is a part of the withholding tax group. This withholding tax is not included in the monetarytotals, tax totals, or invoice line values. And there can be only one AllowanceCharge node per invoice, not one per line. task-4989463 Forward-Port-Of: odoo/enterprise#97071 Forward-Port-Of: odoo/enterprise#94504
The Payroll Employees menu now uses the standard navigation path again because newer platform routing improvements make the previous workaround unnecessary. This avoids a full page reload, helping the Employees screen open more quickly and smoothly.
Original PR description
This reverts commit bbb22f4835197419be538a7e2a82c1743fac3fa3. The fixes in the commit reverted is no longer needed thanks to the recent changes by the framework to better manage the routing in backend. Moreover, the fixes made by calling a client action to change the url will trigger a hard reload and so the employees action will take more time than before since all OWL components have to be mounted instead of just mounting to needed owl components to load the Employees action. Forward-Port-Of: odoo/enterprise#96967
Attachments shared during a website helpdesk live chat are now carried into the related lead description in a cleaner, consistent format. This helps sales and support teams keep customer context and supporting files together when following up.
Original PR description
This commit PR attachment conversion logic with `_attachment_to_html` introduced in the related Community PR. Related: https://github.com/odoo/odoo/pull/227563 Task-4777564 Forward-Port-Of: odoo/enterprise#94970
Resolved issues and error corrections
Corrected a typo in the Australian payroll API cleanup script so database neutralization can complete successfully. This helps prevent failures when preparing safe, non-production database copies.
Original PR description
There is a `s` in the table name of `ir_config_parameter`
```py
2025-10-14 12:30:43,043 278 ERROR ? odoo.sql_db: bad query: b"DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payroll_iap.endpoint';\nUPDATE res_company SET l10n_au_payroll_mode = 'test';"
ERROR: relation "ir_config_parameters" does not exist
LINE 1: DELETE FROM ir_config_parameters WHERE key = 'l10n_au_payrol...
^
2025-10-14 12:30:43,043 278 CRITICAL ? odoo.cli.neutralize: An error occurred during the neutralization. THE DATABASE IS NOT NEUTRALIZED!
```
Forward-Port-Of: odoo/enterprise#97129Payroll payslips no longer trigger an error when a user removes the period date. This prevents an unexpected interruption during payslip creation and helps payroll users continue their workflow smoothly.
Original PR description
This error occurs when the user removes the period date from the payslip. Steps to reproduce: --- - Install `hr_payroll` module - Create a New Payslip - Add `Employee` and remove `Period` date Traceback: --- `TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'` This error occurs because at [1], the `date_to` field is received as `False` after the date is removed from the payslip. [1]: https://github.com/odoo/odoo/blob/4cd1ad3aa46ad4645fc7b5e530b79d53382de6d5/addons/hr/models/hr_version.py#L388 sentry-6925445279 Forward-Port-Of: odoo/enterprise#96492
The Shop Floor "Add Operator" action now uses the public employee list, so users without access to private employee profiles can still select operators. This avoids unnecessary access warnings and keeps production work order operations moving smoothly.
Original PR description
The task 4762527 added a warning for users that were not allowed to access private employee profiles. The "Add Operator" button in mrp_workorder (Shop Floor) was relying on it. I had to change their list model from hr.employee to hr.employee.public This issues was raised by Aerospacelab in the following PR: https://github.com/odoo/odoo/pull/228623 task-5156702 Forward-Port-Of: odoo/enterprise#96745
This fixes an issue where Odoo Studio could attach customizations to a secondary inherited view instead of the main base view. The change helps ensure Studio edits are applied more reliably and reduces the risk of incorrect behavior when customizing screens.
Original PR description
…ry view Accidentally pass an inheriting view id to edit view. Before this commit, the studio view thus created inherited from the extension view After this commit, it inherits from the closest primary view. opw-4930800 Forward-Port-Of: odoo/enterprise#96636 Forward-Port-Of: odoo/enterprise#94747
This fix keeps the restaurant floor screen compatible with recent point-of-sale changes. It helps prevent display or navigation issues when restaurants use appointment-related flows in the POS.
Original PR description
This commit adapts an overriding method to reflect changes in the base method done in this pr https://github.com/odoo/odoo/pull/176016. Forward-Port-Of: odoo/enterprise#95653 Forward-Port-Of: odoo/enterprise#91334
This fix ensures the accounting report remains available only to users in accounting-related roles. It helps keep financial reporting access aligned with intended business permissions and avoids exposing accounting tools to unrelated users.
Original PR description
Forward-Port-Of: odoo/enterprise#96731
Updated WhatsApp test data so its phone number does not duplicate the demo data. This prevents automated tests from failing due to duplicate account phone numbers and helps keep releases stable.
Original PR description
Issue: Before this commit, if we were in 'with demo' test, we would have a WhatsApp account with the same phone number, which would trigger the unique constraint Fix: Modify the phone number to be different from the one in the demo data runbot-223071
Document upload request emails now address the person being asked to provide the document, rather than the sender or owner. Invitation and reminder emails are also sent in the requestee's language, making communications clearer and more professional.
Original PR description
Currently, the email template inviting a user to upload a document displays the document owner's name in the greeting instead of the requestee's. This commit updates the template to display the correct name. Steps to reproduce: 1. Log in as Mitchell Admin 2. Go in the Document app 3. Click on the New > Request 4. Enter a document name and select Joel Willis as requestee 5. Send the request by clicking on the "Request" button => The invitation email is correctly sent to Joel Willis but it says "Hello Mitchell Admin" instead of "Hello Joel Willis" Additionally, this PR ensures that the reminders and the invitation emails are sent in the requestee's language rather than the sender's. Task-5130591 Forward-Port-Of: odoo/enterprise#96941 Forward-Port-Of: odoo/enterprise#96161
Updates Belgian reporting audit check descriptions and translations to make them clearer and more consistent. This helps users better understand validation messages during compliance checks, reducing confusion without changing core reporting behavior.
Original PR description
Forward-Port-Of: odoo/enterprise#97139
IoT users and administrators can now open IoT screens even when they do not have Point of Sale access. POS-specific options are only shown or used for users with the right permissions, preventing unnecessary access errors.
Original PR description
Before this commit, if an IoT user/admin attempted to access any IoT view while `pos_iot` was installed, they would get a permission error if they were not also a POS user. After this commit, we check if the user is in a POS group before showing any POS related fields. We also check the group when autoconfiguring a new IoT box with a POS, this feature will simply be skipped if the user cannot access POS. Forward-Port-Of: odoo/enterprise#97133
This fix prevents spreadsheet list editing from crashing when a referenced field was removed during migration or after deleting a custom field. Business users can continue editing affected lists from the side panel instead of being blocked by an error.
Original PR description
If a field disappeared from a list following a migration or a deleted custom field, the list could no longer be edited in the sidepanel because we tried to access the missing field info (name & string) Task-4915281 Forward-Port-Of: odoo/enterprise#97179 Forward-Port-Of: odoo/enterprise#96158
Project budget totals now use the same color logic as individual budgets, especially for expense budgets with positive amounts. This helps users read project dashboard budget status accurately and avoid misleading visual indicators.
Original PR description
#### Issue: - Color for project budget and total project budgets are inconsistent #### Step to reproduce: - In Settings: - activate Project > Timesheet - activate Accounting > Budget Management -…
#### Issue: - Color for project budget and total project budgets are inconsistent #### Step to reproduce: - In Settings: - activate Project > Timesheet - activate Accounting > Budget Management - Create a project - Go to Dashboard - Add a budget of type 'Expense' - Add a line with a positive amount #### Current Behavior: - Color for the budget is correct - Color for the total budget is wrong #### Expected behavior: - Color for the budget and total budget are consistent While computing budget color, expense budget are dealt as if they were negative. Therefore having a positive amount for purchase order result in some problem on the color of the total of different budgets. This commit creates temporary variables to compute progress of the global budget. Project cards in kanban view use the `total_budget_progress` field, so it also needed to be updated the same way. opw-4812468 Forward-Port-Of: odoo/enterprise#97211 Forward-Port-Of: odoo/enterprise#93221
New timesheet entries on helpdesk tickets now show in the expected newest-first order immediately after creation. This removes the need for users to refresh the form to see the correct timesheet list order.
Original PR description
In version saas-18.3 and later, when creating new timesheets for helpdesk tickets, they are added to the bottom of the list instead of being sorted from newest to oldest. **Steps to reproduce:** 1.…
In version saas-18.3 and later, when creating new timesheets for helpdesk tickets, they are added to the bottom of the list instead of being sorted from newest to oldest. **Steps to reproduce:** 1. Install helpdesk_sale_timesheet 2. Navigate to Helpdesk > Tickets > Timesheets 3. Create a new timesheet **Issue:** The timesheet is added to the very bottom of the list. It is not sorted from newest to oldest until the form view is refreshed. **Causes:** When helpdesk_sale_timesheet module is installed, an issue occurs. The overridden `write()` method on `helpdesk.ticket` accesses `self.timesheet_ids` too early, before the new timesheet is actually added, resulting in the new entry being appended at the end of the list. **Solution:** Avoid evaluating `self.timesheet_ids` when there is no need to process recompute_so_lines. This prevents premature evaluation and allows the ORM to attach and sort the new timesheet correctly, ensuring it appears in the expected order without requiring a form refresh. [opw-4864981](https://www.odoo.com/odoo/project.task/project.task/4864981) Forward-Port-Of: odoo/enterprise#97254 Forward-Port-Of: odoo/enterprise#94369
This update ensures attachments linked to Indian tax return reports can be found correctly when needed. It prevents access-related lookup issues that could block or disrupt report workflows involving supporting documents.
Original PR description
Follow-up of fd4fcb1bd87, we should set `bypass_search_access` on `ir.attachment` many2many fields. Forward-Port-Of: odoo/enterprise#97278
Miscellaneous changes
Related: https://github.com/odoo/design-themes/pull/1167 Related: https://github.com/odoo/industry/pull/1204 Related: https://github.com/odoo/odoo/pull/230615 Forward-Port-Of: odoo/enterprise#96645
Original PR description
Related: https://github.com/odoo/design-themes/pull/1167 Related: https://github.com/odoo/industry/pull/1204 Related: https://github.com/odoo/odoo/pull/230615 Forward-Port-Of: odoo/enterprise#96645
6 changes
Enhancements to existing features
A new automated test was added to confirm that matching India tax rules produce equal tax amounts when configured the same way. This helps reduce the risk of future accounting calculation regressions without changing user-facing behavior.
Original PR description
Added a missing test case in India tax computation, where both taxes have the same configuration as below: - amount: same for both taxes - price_include: True - include_base_amount: True - is_base_affected: False In this case, both tax amounts should be equal. This commit ensures that scenario is properly covered in the test suite. Forward-Port-Of: odoo/odoo#231364
Companies using Austrian POS localization can now automatically invite the email listed in company information to access the related Fiskaly dashboard. If the company email changes, a new invitation is sent, and existing Fiskaly organization data is kept up to date even while authentication is still pending.
Original PR description
In this commit: ------------------ - If a company email is set in the company information, we send an invitation to that email, allowing the user to access their company data on the Fiskaly dashboard by logging in using the company email. - If the email is later updated, access invitation will automatically be sent to the new email. - If the fiskaly organization exists, we should update the organization data even if the authentication is remaining to keep the data uptodate. Related PR: https://github.com/odoo/iap-apps/pull/1098 Task: 4881786 Forward-Port-Of: odoo/enterprise#88106
Resolved issues and error corrections
This fix corrects a table name error that caused the database neutralization process to fail when the Australian HR Payroll API module was installed. It helps ensure test or copied databases can be safely neutralized without interruption.
Original PR description
****Behavior:**** When calling neutralize, an error occurs. The table name in the SQL file was wrong. **Steps to reproduce:** - Create a new DB and install this application (odoo-bin -d TESTDB --addons-path=odoo/addons,enterprise -i l10n_au_hr_payroll_api --stop-after-init) - Run Neutralize (odoo-bin neutralize -d TESTDB --addons-path=odoo/addons,enterprise) - You should see the error opw-5142610
Privacy Lookup now checks whether a contact's email address is valid before running the search. This prevents an unexpected error and gives users a clearer issue to correct when a contact has an invalid email address.
Original PR description
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address. **Steps to reproduce:** - Install CRM modules. - Create a new contact with an invalid email…
Currently, an error occurs when running a privacy lookup on a contact with an invalid email address.
**Steps to reproduce:**
- Install CRM modules.
- Create a new contact with an invalid email address (missing @ - e.g; `demo`).
- In the contact form, click the gear icon and select "**Privacy Lookup**".
- Click on "**Lookup**" button.
**Error:**
```
UndefinedFunction
operator does not exist: character varying = boolean
LINE 55: WHERE email_normalized = false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Cause:**
Here, Execution of the query fails because `email_normalized` is set to a Boolean value, which is being computed at [1]. And method `tools.email_normalize` returns `False` for invalid email inputs - [2].
**Fix:**
This commit raises an error if the email address is invalid before executing the query.
A similar case is already handled in the mail blacklisting module. ([Ref](https://github.com/odoo/odoo/blob/c7f86c3250c59130ae0b95c6847050d3a6fc7a6d/addons/mail/models/mail_blacklist.py#L29-L31)):
[1] - https://github.com/odoo/odoo/blob/e6c0e963c5379ba7ad8da00ba4ea6c2bb259d95c/addons/privacy_lookup/wizard/privacy_lookup_wizard.py#L49
[2] - https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/odoo/tools/mail.py#L734-L735
sentry-6881416673
Forward-Port-Of: odoo/odoo#227697Preparation tickets in Point of Sale now handle combo products correctly when different printers are assigned to different product categories. Each printer receives the combo name plus only the relevant items for its category, reducing kitchen or service confusion.
Original PR description
Before this commit: =================== - When using separate printers for product categories, combo products were not printed correctly. - All child products of a combo were sent to every printer, regardless of their category. After this commit: ================== - Combo products are now handled properly in preparation tickets. - Each printer will print the combo product title along with only the child products that belong to its assigned category. Task: 5056115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230982 Forward-Port-Of: odoo/odoo#225658
This update removes an unstable automated test assertion in Discuss that could incorrectly fail depending on how mobile detection behaved during testing. It improves test reliability without changing the product experience for users.
Original PR description
Before this commit ([1]), we were testing the absence of a button for mobile, but the test can lead to undeterministic behavior as `isMobileOS` is not reactive as we do not expect a live transition of userAgent, like from desktop to mobile, so testing for this behavior is not useful. A dedicated test for call mobile was introduced in v19 ([2]) https://runbot.odoo.com/odoo/runbot.build.error/233350 [1]: https://github.com/odoo/odoo/pull/177374 [2]: https://github.com/odoo/odoo/pull/218119 Forward-Port-Of: odoo/odoo#231191
25 changes
New functionality added to Odoo
Users in Turkey can now upload e-Receipt XML files exported from the Nilvera Portal directly from the Receipts list. Odoo creates draft receipts from the uploaded files and opens the resulting receipts, reducing manual data entry and speeding up receiving workflows.
Original PR description
This PR introduces a new option to import e-Receipt XML files exported from the Nilvera Portal. - An "Upload e-Receipt (XML)" button is now added in the list view of Receipts (stock picking). - Upon upload, draft receipts are created based on the XML data. - After successful import, the user is redirected to a new view displaying the generated receipts. TaskID:4452521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Updates Uruguay localization so reduced VAT rates can be configured and reported separately for eligible consumer sales paid by debit card or electronic money. This helps companies produce compliant tax reporting and electronic invoice XML totals for VAT rates outside the standard exempt, minimum, and basic categories.
Original PR description
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and…
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).
1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra> (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact>
*Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update adjusts Mexican electronic invoicing to match a change in how taxes are rounded. It helps keep generated CFDI invoice documents compliant and reduces the risk of rounding discrepancies in tax reporting.
Uruguay electronic invoicing now handles reduced VAT rates beyond the standard exempt, minimum, and basic rates. This ensures invoices report these taxes correctly in required XML fields and adds a dedicated tax grid for consistent VAT reporting.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999The analytic distribution popup now reuses already available account and currency display information instead of requesting it repeatedly. This reduces unnecessary network activity when invoice lines contain many analytic accounts, making the popup open more smoothly for users.
Original PR description
Currently opening the analytic distrubtion popup on an invoice line creates N network requests per account set on the line. Steps to reproduce ----- 1. Edit the analytic distribution on an invoice line and add a lot of accounts 2. Open the popup again 3. A lot of web_read requests are made Issue ----- The display_name for the account and currency is not being passed to the field values in recordProps(), resulting in another fetch when each Field element is rendered. Solution ----- Pass account.accountDisplayName. The display name for the currency is actually not initially loaded by the client, but since that field is invisible, we can safely use an empty string. opw-5106219 Forward-Port-Of: odoo/odoo#231342
Updates made to POS categories, such as name or display order, are now reflected in UrbanPiper when the menu is synced again. This helps restaurants keep their online menus consistent without manual corrections.
Original PR description
Before this commit: ----------------------------------------- - After syncing the menu, changes in a POS category (e.g., name or sequence) were not reflected in UrbanPiper when the menu was synced again. After this commit: ----------------------------------------- - Category updates (name or sequence) are now synced with UrbanPiper on subsequent menu syncs. Task-5122804
Italian electronic invoices are now sent one at a time instead of in larger batches to reduce timeout errors. This helps prevent scheduled processing from getting stuck when companies submit many invoices at once.
Original PR description
Some clients reported that when they send a full batch size=20 invoices at once, they get a timeout response and the cron job get's stuck. Processing invoices one by one instead of a full batch. IAP-apps PR: https://github.com/odoo/iap-apps/pull/1230 Task [link](https://www.odoo.com/odoo/project.task/5045529) task-5045529
Resolved issues and error corrections
This fix stops users from creating new workplace names directly from the Swiss payroll contract screen when that shortcut could trigger an error. Users can still select existing workplaces, reducing interruptions and avoiding invalid workplace entries during contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#93424
Text highlighting added to eLearning article content now appears correctly in fullscreen viewing mode. This ensures learners see the same formatted course material whether they read articles normally or in fullscreen.
Original PR description
**Steps to reproduce:** - Go to eLearning course on the website - Edit an article - Add the highlighting effect on the text - Save the changes - The text is properly displayed in normal article - Go to the fullscreen version - The highlighting is not present in this version **Issue:** This is an ordering issue caused by the dynamic rendering of fullscreen slides. When in normal mode, the content is initialized and then the `TextHighlight` widget is started. But the rendering of the slides in fullscreen mode is delayed and occurs after the widget is applied. **Fix:** Recreate and restart the widget on `_renderSlide` in the `slides_course_fullscreen_player`` opw-4978798 related: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225150
This fixes an intermittent automated test failure in the Mail app by ensuring the message editor is ready before simulating the Escape key. The change helps keep development checks stable without changing the user experience.
Original PR description
Before this commit, test "discard on pressing escape" failed non-deterministically with the following error: ``` Failed to find 0 of ".o-mail-Composer" (Timeout of 3 seconds). Found 1 instead. ``` This happens at the very last step of the test: we click on composer of message to have the focus, so that we can then press ESCAPE and discard the editing of message and thus remove the composer. The issue happens because while we click on composer, we don't await the composer being logically focused, which is necessary for the good working of the ESCAPE feature to discard the message editing. This commit fixes the issue by awaiting the composer is logically focused after click on composer, so that pressing ESCAPE is properly expected to cancel the editing and thus remove the composer. Fix runbot-error-233394
This fixes a problem where users without the right access could trigger repeated reconnection attempts and excessive log messages in the web editor. The system now avoids subscribing to notification channels when access checks fail, keeping the service stable and reducing unnecessary noise for administrators.
Original PR description
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img…
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" /> Each reconnect attempt causes a log entry: ``` 2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Marc Demo (id=6) doesn't have 'write' access to: - Lead/Opportunity, Modern Open Space (crm.lead: 25) Blame the following rules: - Personal Leads If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. ``` Current behavior before PR: Reconnect loop. Desired behavior after PR is merged: Do not add channels without sufficient rights. Related to: https://www.odoo.com/de_DE/my/tasks/5026412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Contacts can no longer be deleted when they are already linked to Point of Sale orders. This prevents past sales records from losing customer information, helping keep order history accurate and traceable.
Original PR description
Before this commit, it was possible to delete a contact record even if it was linked to PoS orders, which would cause it to be unlinked from those orders. opw-5164368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Argentina VAT report exports now correctly generate both required AFIP text files for type C vendor bills and invoices without taxes. This helps businesses meet AFIP reporting requirements and avoids incomplete tax return submissions.
Original PR description
…afip code '0' **Description of the issue/feature this PR addresses:** This PR addresses an issue identified in the generation of .txt files for invoices that utilize AFIP tax code '0' **Current behavior before PR:** The system is only generating one of the two .txt files required by AFIP for specific invoice types. Affected Cases: - Invoices of type 'C'. - Invoices that have no taxes. **Desired behavior after PR is merged:** Two .txt files should be generated for all invoice types, as per AFIP requirements. [HERE](https://app.screencastify.com/watch/2mtioGVxEOwW0rAHJS2v) is a video replicating the issue: 1. In localization Argentina, create a vendor bill type 'C' 2. In 'Tax Return' report, filter by date and 'Tax Type: Purchase' 3. Download .ZIP file and see only one .txt
Uruguayan electronic invoices now include invoice lines that have a zero total value, such as free delivery or fully discounted items. This ensures these lines are correctly reported to the tax authority as free delivery, improving compliance and invoice completeness.
Original PR description
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by…
## Description of the issue The client wants to register 0.0 line to the CFE (delivery line with price 0.0): based on our findings, the only way to report lines with 0 values to the DGI is by configuring the line as a "free delivery." (invoice indicator 5). But this lines is not been reported as part of the CFE xml (neither as a Free Delivery line or discount ## Steps to reproduce 1. Create a Uruguayan electronic invoice (sales default journal on a UY company) 2. Add a line with quantity 1. price 0 3. Add a second line with quantity 1, price 500 and discount 100% ## Before this PR 1. if we have a line with price unit != 0.0 but with total price of the line 0.0 (as the second line), then we are reporting the invoice line as Free Delivery. 4. But, If we have an invoice with line with price unit 0.0 (example first line) then is not being informed in the CFE at all ## After this PR Both lines are informed to DGI using the invoice indicator 5 (Free Delivery) You can check this on to generate CFE XML in demo mode (not need to connect to UCFE) If you want more visual example please connect to UCFE in testing enviroment and check the generated PDF file. References [Odoo task](https://www.odoo.com/odoo/project/967/tasks/5015691) LATAM 1350 / ADHOC task 53445
This fixes rounding issues where price-included taxes could make invoice or sales line totals differ by a cent from the displayed price. It also simplifies the tax calculation logic and updates country-specific handling for Mexico and Portugal to keep totals consistent.
Original PR description
== Fix bug price-included == Suppose a line of 24.99 with a 20% tax price-included. base: 24.99 / 1.2 = 20.825 tax: 20.825 * 0.2 = 4.165 If we round both, we get 20.83 + 4.17 = 25.0 != 24.99 == Split and simplify round_base_line_tax_details == Easier implementation of this method to be easier to understand and easier to be customized (see PT override). Also, we now use the aggregate methods to aggregate the amounts instead of doing that by hand. opw-4505888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where one-day time off requests could appear as multi-day events in the Calendar app for users in certain time zones. This keeps employee leave calendars accurate and avoids confusion when planning absences.
Original PR description
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…
**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817 Forward-Port-Of: odoo/odoo#224298
Website editors no longer lose a field's spacing offset when adjusting or previewing display settings such as label position or description. This prevents accidental layout changes and saves editors from having to reapply formatting after minor customization actions.
Original PR description
Before this commit, changing display parameters of a field (label position, description, etc.) would remove the offset already added. It would require to add them again if a change was made on the display, even if the mouse just hovered the buttons. This commit solves the issue. Steps to reproduce the bug: - Add a form snippet - Add an offset to a field - In the snippet customization, hover over the label position (The offset was removed for good) task-3675509 Forward-Port-Of: odoo/odoo#181344
This change makes an editor test use a clearly defined border color instead of relying on environment defaults. It helps keep automated validation consistent and reduces false build failures, with no expected impact on end users.
Original PR description
Problem: Runbot build fails due to different resulting `border-color` values. Cause: The default `border-color` can change depending on the environment, leading to non-deterministic behavior. Solution: Specify the `border-color` explicitly to ensure consistent results. runbot-233297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Failed email replies for accounting journal aliases now use the company linked to the journal alias instead of defaulting to the main company. This prevents customers or vendors from receiving bounce messages with the wrong company name or email address in multi-company setups.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project revenue calculations now include products that have been archived, so revenue no longer disappears from project status after a product is archived. This keeps project profitability views accurate for service products sold through Sales, Project, and Timesheets.
Original PR description
**Steps to reproduce:** 1. Install the Sale, Project, and Timesheet modules. 2. Create a service-based product with `invoicing policy > Prepaid`, linked to `Create on Order > Project and Task`. Add a project template. 3. Create a sale order with that product. 4. Go to the created project and check the project status. **Observed behavior:** * Revenue is visible in project status while the product is active. * Once the product is archived, its revenue disappears. **Root cause:** Archived products were not considered when calculating revenue. **Solution:** Backport the fix from v18 to include archived products in revenue calculations. v18 pr : https://github.com/odoo/odoo/pull/129089 added test for product archive case. opw-5070289 Forward-Port-Of: odoo/odoo#229485
This fixes a problem where the import screen could crash when a model offered more than one sample import template. Users can now reliably see and choose from multiple templates, with slightly cleaner button spacing.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.
Forward-Port-Of: odoo/odoo#231407This fix allows Odoo to create related one-to-many list fields when no reverse link field is available. It removes a setup blocker for certain custom data relationships, helping configurations work as intended without manual workarounds.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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#231187
This fixes an issue in Odoo Studio where creating a related field to a customer's child contacts could save an invalid setting. The correction prevents crashes during later form updates, making Studio-created customizations safer for sales workflows.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#96950
Fixed an issue where using keyboard navigation in the Helpdesk knowledge base search suggestions could trigger an error page. This improves the reliability of self-service support by allowing customers to search help articles without interruption.
Original PR description
Steps to Reproduce: 1. Navigate to '/helpdesk/customer-care-1/knowledgebase'. 2. Enter any text in the search bar to trigger suggestions. 3. Press the down arrow key twice. 4. A traceback error occurs, indicating an Odoo Client Error. Before this commit, we had a crash when a user types something in a searchbar in the website helpdesk and do keydowns: "Cannot read properties of undefined (reading 'nextElementSibling')" To fix this, we need to add the 'data-bs-toggle' attribute to let BS find it to set '_element' (which must be the previous sibling of the dropdown-menu). This data attribute was probably not set before because in this case the BS dropdown is not used on a button or a link as documented; we use it as an autocomplete functionnality. task-4752497 Forward-Port-Of: odoo/enterprise#90228
Tooltip text in Live Chat, Discuss/Mail, and Point of Sale is now included in the app translation process. This helps users working in other languages see consistent translated guidance across these areas.
Original PR description
Unless you tell Owl to do so, custom attributes like data-tooltip aren't translated. This commit adds the data-tooltip attribute to the list of translated attributes when missing. *: im_livechat, mail, point_of_sale Forward-Port-Of: odoo/odoo#231006
3 changes
Resolved issues and error corrections
This fixes issues in the Social app when commenting on Twitter posts. Images now upload with the correct file type, and comment text is no longer lost when adding files or emojis.
Original PR description
Issue 1 ======= Steps to reproduce ----------------------- 1. Go to the Social app. 2. Create or Select any twitter post. 3. Add a comment to that post with an image. 4. Press Enter. ---> An error…
Issue 1
=======
Steps to reproduce
-----------------------
1. Go to the Social app.
2. Create or Select any twitter post.
3. Add a comment to that post with an image.
4. Press Enter.
---> An error notification will be shown.
When adding an image in a post comment to Twitter, the image was not uploaded properly because the MIME type was not set, and it defaulted to `application/octet-stream`.
This caused the following error:
```
{"errors": [{"parameters": {"$.media_type": ["'application/octet-stream'"]},
"message": "$.media_type: does not have a value in the enumeration
[video/mp4, video/webm, video/mp2t, video/quicktime, text/srt, text/vtt,
model/gltf-binary, model/vnd.usdz+zip, image/jpeg, image/gif, image/bmp,
image/png, image/webp, image/pjpeg, image/tiff]"}], "title": "Invalid Request",
"detail": "One or more parameters to your request was invalid.",
"type": "https://api.twitter.com/2/problems/invalid-request"}
```
From the above error, it's clear that Twitter only accepts specific MIME types.
This fix ensures the image has the correct MIME type so it can be uploaded without issues.
-------------------------------------------------------------------------------------------------------------------------------
Issue 2
=======
Steps to Reproduce
------------------------------
1. Select any post from social feed.
2. Add text comment or edit existing comment.
3. Upload file or add emoji.
=> The comment text is cleared/reset to its initial value.
Technical
------------------------------
With commit [1] we added `t-att-value` which sets the value of the textarea
on every re-render of the component.
After this commit
------------------------------
The initial value is only set once when component is mounted.
Removed `remove image` button for attachment while posting comments.
[1] https://github.com/odoo/enterprise/commit/ced5e88f433b7b9a8e1429259cd8bb6594b34852
Task-4845385Users can now print or export their own timesheets from a single private project without encountering an access error. This removes an inconsistency that blocked valid reporting for assigned users while keeping the same information visibility already available elsewhere in Odoo.
Original PR description
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as…
****Behavior:**** **Current:** When a user with only 'User' access to Projects and Timesheets, is assigned to a task in a Private project by an admin user, they can then log timesheets on the task as it appears under "My Tasks". The user might then want to print or export the timesheets form the list view. - If the selected timesheets come from only a single private project : an Access Error is raised - If the selected timesheets come from multiple private projects, or a mix of public and private ones : no Error is raised The issue comes from the need to access to the project's name (since the project is private to the user the code raises the error) as well as the company's name. And it only happens when single projects are selected, in the other cases, the exported pdf shows the project's name at another location without error. **Expected:** Since the information is already accessible through multiple other places in odoo (and even in the exported pdf), we should allow the access here aswell. So now when printing or exporting a timesheet from a single private project, no Access Error is raised. **Steps to reproduce:** - Create 2 different projects - Create a task in each - Assign it to another user (Make sure the other user only has user access to timesheets and projects) - Set each project's visibility setting to private - Log in with the other user - Go to Timesheets --> List View Single projects: - Select one or multiple timesheet entries from one of the private projects - Select Print -> Timesheets - You should see an Access Error Multiple projects: - Select one or multiple timesheet entries from a combination of both private projects - Select Print -> Timesheets - You should not have any Errors opw-5127526
Miscellaneous changes
opw-5018450
Original PR description
opw-5018450