Friday, July 17, 2026
268 changes
1 change
Resolved issues and error corrections
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Original PR description
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
1 change
Resolved issues and error corrections
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Original PR description
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
11 changes
Enhancements to existing features
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
Original PR description
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
1 change
Resolved issues and error corrections
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Original PR description
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
1 change
Resolved issues and error corrections
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit chara
Original PR description
9 changes
Resolved issues and error corrections
Fixes translation-related issues in accounting screens so users see consistent guidance and correctly ordered labels in their chosen language. Bank Matching now keeps the same empty-state help after reloads or language changes, and the fiscal year wizard can use natural wording in languages such as French.
Original PR description
The empty-state message in Bank Matching differs depending on how the view was reloaded. In particular, after changing language from inside the view, the message loses the sentence explaining that users can create or import bank transactions. Ensure the Bank Matching empty-state help remains consistent across all reload flows. --- The fiscal year setup wizard was building the tax periodicity label from two separate translated parts. This produces an incorrect word order in some languages, such as "TVA Périodicité" in French which is supposed to be "Périodicité TVA". Use a single translatable label instead, so translations can place the tax label where it belongs in the sentence. task-6265141
1 change
Resolved issues and error corrections
Odoo Studio no longer fails when users rename fields with Arabic or other non-Latin labels. This prevents an unnecessary validation error and makes field labeling more reliable for multilingual users.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O
Original PR description
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in…
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line. Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler. Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation) _(To do: testing/review, credit note, cancellation/reversal of the payment)_ Task [link](https://www.odoo.com/odoo/project.task/6037525) task-6037525 Forward-Port-Of: odoo/odoo#259197
Resolved issues and error corrections
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483
Original PR description
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483f6ddab87da0c55 Task-6372638 Forward-Port-Of: odoo/odoo#274972
Problem: When a user attempts to create a new partner, and before saving the partner, they attempt to create a bank account in the same form view, they will be faced with a validation error for missing partner_id on the bank account. Solution: This commit solves this issue by only allowing the user to modify bank accounts for existing partners (with id). task-6373918
Original PR description
Problem: When a user attempts to create a new partner, and before saving the partner, they attempt to create a bank account in the same form view, they will be faced with a validation error for missing partner_id on the bank account. Solution: This commit solves this issue by only allowing the user to modify bank accounts for existing partners (with id). task-6373918
[1] added a bus channel for discuss categories. This can be done with or without any token. When the token is not passed, `verify_limited_field_access_token` is still called and crashes. When no token is provided, we should use category access rights instead and avoir verifying the token (which is `None`). [1]: https://github.com/odoo/odoo/pull/243131 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
[1] added a bus channel for discuss categories. This can be done with or without any token. When the token is not passed, `verify_limited_field_access_token` is still called and crashes. When no token is provided, we should use category access rights instead and avoir verifying the token (which is `None`). [1]: https://github.com/odoo/odoo/pull/243131 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
### STEPS TO REPRODUCE: 1. Install AI, Livechat, and Website 2. Open Livechat and create a new channel 3. Ensure there is a welcome message 4. Add a rule with any AI Agent 5. Navigate to Settings > Website, enable Live Chat, and select the channel you just created 6. Go to the Website, click on the chat bubble, and verify that the first message shows "unnamed" as the sender of the welcome message ### CAUSE When a default message exists, the `author_id` is resolved by looking at the c
Original PR description
### STEPS TO REPRODUCE: 1. Install AI, Livechat, and Website 2. Open Livechat and create a new channel 3. Ensure there is a welcome message 4. Add a rule with any AI Agent 5. Navigate to Settings > Website, enable Live Chat, and select the channel you just created 6. Go to the Website, click on the chat bubble, and verify that the first message shows "unnamed" as the sender of the welcome message ### CAUSE When a default message exists, the `author_id` is resolved by looking at the current channel's history. However, it only checks `livechat_agent_history_ids`. Since a bot can also send the welcome message instead of an agent, `livechat_bot_history_ids` should also be checked.
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403
Original PR description
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403
The service worker required for push notifications is only available to internal users. This commit fixes the test setup by ensuring non-internal users are no longer registered, matching the expected flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269210
Original PR description
The service worker required for push notifications is only available to internal users. This commit fixes the test setup by ensuring non-internal users are no longer registered, matching the expected flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269210
Steps to reproduce: 1. Drop a .s_tabs snippet 2. Click inside a tab to move the selection in it 3. Press backspace (remove each tab name + the last one should be empty) 4. Click on the "+" in the sidebar to add a Tab => Crash or on step 3: 3. Press backspace to delete one tab => Check the DOM: the tab has been removed, but the tab-pane element is still in the DOM and won't be deleted. This is easily fixed by adding `oe_unremovable` on tab links. task-4671317 Forward-Port-Of: odo
Original PR description
Steps to reproduce: 1. Drop a .s_tabs snippet 2. Click inside a tab to move the selection in it 3. Press backspace (remove each tab name + the last one should be empty) 4. Click on the "+" in the sidebar to add a Tab => Crash or on step 3: 3. Press backspace to delete one tab => Check the DOM: the tab has been removed, but the tab-pane element is still in the DOM and won't be deleted. This is easily fixed by adding `oe_unremovable` on tab links. task-4671317 Forward-Port-Of: odoo/odoo#275240
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: - Enable Sale Credit Limit in the settings of My Company (San Francisco) - Set a Credit Limit of 100 on a customer, e.g. Deco Addict - Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected - Switch the active company to any other company, fo
Original PR description
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: -…
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: - Enable Sale Credit Limit in the settings of My Company (San Francisco) - Set a Credit Limit of 100 on a customer, e.g. Deco Addict - Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected - Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies - Open the same quotation again => The warning banner is gone, although neither the quotation nor the customer changed The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one. Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276308
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the
Original PR description
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and…
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`. Expected behaviour: - Saving should be allowed with a default image, that is similar to other images. This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck. Commit [2]: resolve traceback when leaving edit mode via browser Steps to reproduce: 1. Go to Website > Edit. 2. Open the snippet modal and select any snippet. 3. Press the 'Back' button in your browser. 4. A dialog will appear asking to discard changes; click 'OK'. 5. A traceback error occurs, and an empty space appears in the editor. Issue: - Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange. - Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener. - As a result, the editor is left in an unstable state, causing a traceback error. Solution: - This commit ensures the 'window' event executes before the browser event. - It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser. task-4570164 Forward-Port-Of: odoo/odoo#275334 Forward-Port-Of: odoo/odoo#199193
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and…
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit characters are stripped, and the identification number is silently changed to `1234567890`. **Expected behaviour:** Any Identification Type other than CUIT (80), CUIL (86), and DNI (96) should be kept unchanged without stripping alphabetic characters. **Root Cause:** At [1], `_get_id_number_sanitize` sanitizes identification numbers based on the selected Identification Type. - For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes separators (e.g., spaces and dashes). If the identification number contains alphabetic characters, they are preserved and called `int()` on the resulting value, raising a `ValueError`. - For all other identification types, valid alphanumeric values are unintentionally modified by stripping non-digit characters. **Fix:** This commit validates identification numbers before sanitization for `CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric identification numbers are converted. For all other identification types, it preserves alphanumeric characters by removing only non-alphanumeric separators. [1]: https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136 Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729 opw-6333998
This fix ensures the Avalara tax connection is disabled when a database is neutralized, such as in test or copied environments. It helps prevent those environments from accidentally connecting to the live tax proxy service.
Original PR description
Community: https://github.com/odoo/odoo/pull/272495
This change removes unused template markers from Helpdesk knowledge base search results and eCommerce subscription product pages. It prevents harmless backend warning messages during page rendering, keeping system logs cleaner without changing the customer-facing experience.
Original PR description
When rendering specific server-side pages (Knowledge Base search results and the eCommerce subscription product page), the Python QWeb engine logs the following warning:
"Unknown directives or unused attributes: {'t-key'} from..."
The `t-key` attribute is an OWL-specific directive required for client-side `t-foreach` loops. It is not recognized by the backend Python QWeb engine and serves no purpose in server-rendered templates.
This commit removes the inert `t-key` attributes from these Python-rendered templates.
task-6385543This fix makes map pin popovers open reliably after selecting a record from the pin list. It removes a timing issue that could cause the popover to disappear unexpectedly during automated mobile testing, improving stability without changing user-facing behavior.
Original PR description
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and…
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and opened the marker popover. This was racy. Closing `pinListPopover` triggers a re-render of the view, during which all markers are removed and re-added. If that re-render happened after the popover was opened, the marker element the popover was anchored to no longer existed, and the popover closed itself through `Popover.onTargetMutate()` (which closes the popover when its target element leaves the DOM). Depending on timing, the popover would sometimes be destroyed right after being opened, making the test flaky and leaving no popover open in the browser. To fix this, `centerAndOpenPin` is split in two parts: * it now only closes `pinListPopover` and raises a `shouldOpenMarkerPopover` flag; * on the next `onPatched`, once the markers have been re-rendered, the new `centerAndOpenPinOnPatched` method centers the map on the marker and opens the popover. Opening the popover after the re-render guarantees the marker element is present, removing the race condition. runbot-error-944199
This fixes an issue where opening a Belgian Dimona declaration could fail if an employee's private street information was missing. The change ensures payroll users can continue the declaration process without an unexpected error.
Original PR description
action_open_dimona guards on `self.employee_id.private_street` but then runs re.findall on `self.private_street` Forward-Port-Of: odoo/enterprise#124029
New planning slots now use the company’s working hours in the company timezone, so default start and end times appear correctly. This prevents schedule entries from being shifted by timezone differences when no resource is selected.
Original PR description
Issue: ---------------------------------------- When creating a new slot, no resrouces are set so we use the calendar of the company but the hours are offset because of the timezone. Steps to reproduce: ---------------------------------------- - Have planning Installed - Have an hour based calendar, from 8 to 16 each day for example - Have the company timezone in UTC+2, same for you the user - Go in Planning "Schedule By Resource" view - Click "New" - The default start and end time are 10am and 6pm (2h offset) Cause: ---------------------------------------- `default_get()` calls `_company_working_hours()` to get the company calendar hours. But they are returned in UTC, so when displaying them they are converted to the user timezone and are offsetted. Solution: ---------------------------------------- `_company_working_hours()` should return the compny hours in the company timezone. opw-6333993 Forward-Port-Of: odoo/enterprise#123033
Code cleanup and technical improvements
The grid view was updated to use the newer interface expected by the latest Odoo web framework. This keeps keyboard navigation and time entry behavior working reliably while reducing reliance on outdated internal code.
Original PR description
Replaced `useLayoutEffect` with `signal.ref` + `useEffect` && `onMounted()` + `onPatched()` && `useListener` because `useLayoutEffect` is deprecated in OWL3. The useLayoutEffect refactored in this PR had test coverage — below are some tests that failed when the effect was commented out, and are now passing: - @web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key - `@web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key` - `@web_grid/grid_cells/float_time_grid_cell/FloatTimeGridCell in grid view` see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624598/build/116553722 see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624595/build/116553684
This update simplifies internal test setups for sales and rental flows, making them easier to maintain. It also starts aligning some tests with standard salesperson permissions, helping ensure checks better reflect typical day-to-day usage.
Original PR description
Simplify specs, and start converting some tests to run with standard salesmen rights.
This change updates several Odoo Enterprise screens and components to use the supported OWL3 lifecycle approach instead of a deprecated method. It helps keep the platform maintainable and compatible with newer frontend framework versions while preserving existing behavior when screens open and close.
Original PR description
useLayoutEffect is deprecated in OWL3, so replace the calls that used an empty dependency array (run-once-on-mount) with the native OWL3 lifecycle hooks onMounted and onWillUnmount. Effects that returned a cleanup function have their teardown moved into onWillUnmount so the unmount behaviour is preserved. Community PR: https://github.com/odoo/odoo/pull/276619