Thursday, July 2, 2026
60 changes · saas-19.3
Resolved issues and error corrections
This change fixes an unstable test that could sometimes misread the activity counter shown in the interface. It ensures the test starts from a clean state so the counter reflects only the activities created for that test, improving reliability of the discussion app checks.
Original PR description
The avatar card tour asserts the systray activity counter, which the browser maintains from "mail.activity/updated" bus notifications. The counter is seeded at page load with a snapshot (activityCounter) and a baseline bus id (activity_counter_bus_id), and only notifications newer than that baseline are applied. The activity unlink/create done while preparing the test emit such notifications whose bus.bus rows are only materialized at precommit, so their ids could land after the baseline and be double-counted, leaving the counter wrong. Reset the bus right before the tour so those setup notifications are dropped and the baseline starts clean, and clear only the user's own pre-existing activities so the snapshot counts just this test's activities. https://runbot.odoo.com/odoo/error/237779 Forward-Port-Of: odoo/odoo#273103
This fix prevents invoice notifications from crashing when they are sent in a different language than the one used while creating the invoice. It ensures Quick Edit invoice confirmations render properly for customers and users, avoiding failed notifications and interrupted workflows.
Original PR description
**Steps to Reproduce:** - Install the Accounting and Contacts modules. - Enable Quick Encoding for Customer Invoices and Vendor Bills in the company settings. - Create a new customer: Assign a…
**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company
settings.
- Create a new customer: Assign a salesperson.
- Ensure:
- The salesperson is not a login user.
- The customer language, salesperson's language, and Login user's language
are different. Example:
- Customer language: English
- Salesperson language: French
- Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.
**Issue:**
- When the invoice notification is rendered in a language different from the one
used during the write operation, the notification rendering flow calls
_notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```
**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359)
in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it
maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes
protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail
notification flow renders the email using the recipient's language. If the
corresponding language-specific cache entry for tax_totals is not available,
the ORM cannot recompute the protected field and returns False instead
of the expected dictionary.
- The rendering code assumes tax_totals is always a dictionary and directly
calls .get(), leading to the crash.
**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting
it is unnecessary. This allows the field to be recomputed during notification
rendering when required.
**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.
**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**
**opw-6209647**
Forward-Port-Of: odoo/odoo#266335This fix avoids an error that could appear when a user removes the currency while registering a payment. It keeps the payment flow working smoothly in the Argentine withholding setup and prevents an unexpected interruption.
Original PR description
When the user removes the currency from the payment register, a traceback is raised. Steps to reproduce the error: - Install ``l10n_ar_withholding`` module - Switch to ``(AR) Exento`` company - Create a new invoice > Confirm > Pay > Unset the currency Traceback: ```py ValueError: Expected singleton: res.currency() ``` https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/l10n_ar_withholding/wizards/account_payment_register.py#L27 This line causes a traceback with an empty currency when the user removes the currency from the payment register. sentry-7362499567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272891 Forward-Port-Of: odoo/odoo#255825
This update fixes a test in the salary configuration flow that was failing because the employee’s private address was not properly set up. It helps keep the payroll setup process stable by ensuring the test matches the expected employee data.
Original PR description
Task-6329628 Forward-Port-Of: odoo/enterprise#122091 Forward-Port-Of: odoo/enterprise#121626
Fixed an issue where new employee document folders were being created in a user's personal drive instead of the company’s main folder. This keeps employee folders organized in the correct company location and makes them easier to find and manage.
Original PR description
Steps to reproduce =================== - Install documents_hr. - Log in with admin. - Create a new company `Test`. - Go to Document and choose the new company (top right). - Go to `My Drive`: a folder named `Employees - Test` has been created. This new folder should be created in the `Company` root instead of the `My Drive,` which will hold all the employee folders. Technical =========== When the main employee folder is created via `_generate_employee_documents_main_folders` `owner_id` falls back to the current user, which leads to computing the `user_folder_id` as `My drive,` and so that's why the newly created folder starts appearing there instead of the `Company` root. This PR addresses the issue and sets the `owner_id` to False, which leads to show the main employee folder in the company root. Task-6267352 Forward-Port-Of: odoo/enterprise#120677
This change prevents an access error that could block delivery validation when a user can manage inventory but only sees their own sales documents. The system now checks the related subscription status in a safer way, so deliveries can be completed without exposing additional sales data or changing the existing business rules.
Original PR description
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by…
## **Issue:** When validating a delivery, users with Sales: Own Documents Only and Inventory Administrator access rights can encounter an access error if the delivery belongs to a sale order owned by another salesperson. ## **Steps to reproduce:** - Install sale_subscription_stock. - Create a user with Sales: Own Documents Only and Inventory Administrator access rights. - Create a sale order as another user. - Validate the delivery with the restricted user. ## **Solution:** During _action_done(), [This line](https://github.com/odoo/enterprise/blob/19.0/sale_subscription_stock/models/stock_picking.py#L45) is checking subscription_state. Since the user does not have read access to the sale order, reading this field raises an access error and prevents the delivery from being validated. As the method only needs to read the subscription state, access the field with sudo() to avoid the unnecessary access error while preserving the existing business logic. Runbot Video : [Video](https://drive.google.com/file/d/1d7U2jTCxaaVk2YJcy3bi2SlYuT-yXMsu/view?usp=drive_link) OPW - 6295712 Forward-Port-Of: odoo/enterprise#122420
This change prevents an error that could appear when opening the Stock report after the Manufacturing app had been removed. It restores the report settings to a safe default during uninstall, so users can continue accessing stock reporting normally.
Original PR description
Currently an error occurs when user opens stock report after uninstalling mrp. Steps to replicate: - Install mrp. - Uninstall mrp and open `Stock > Reporting > Stock`. Error: ``` ValueError: Invalid…
Currently an error occurs when user opens stock report after uninstalling mrp.
Steps to replicate:
- Install mrp.
- Uninstall mrp and open `Stock > Reporting > Stock`.
Error:
```
ValueError: Invalid field product.product.is_kits in condition ('is_kits', '=', False)
```
Cause:
- The `mrp` module overrides the `stock.action_product_stock_view` window action domain with `is_kits` field referenced inside [1].
- When mrp is uninstalled, the `is_kits` field is removed from `product.product` but the overridden action domain remains stored in the database. Opening the action then tries to evaluate a domain referencing a non-existent field, resulting in this error.
Solution:
- Restore the original `stock.action_product_stock_view` domain during mrp uninstallation to remove the `is_kits` condition.
[1]: https://github.com/odoo/odoo/blob/c8390638cae4b4dafb805bc0d3a4149fb5194934/addons/mrp/views/product_views.xml#L164-L166
sentry-7332688253
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#269512This change corrects a rounding issue that could make overtime time entries overlap by a few seconds, especially around midnight. It now orders the entries more reliably and prevents one interval from starting before the previous one has finished, improving the accuracy of attendance and payroll data.
Original PR description
__Issue:__ `duration` is rounded to 3 decimals (~1.8s drift) while `time_stop` is exact, so the back-projected start could land before midnight on overnight overtime or middle of the day causing overlaps with the previous line Example: - time_start = 03/05 00:00:00 - time_stop = 03/05 07:07:14 actual duration 7h07m14s gets stored as `duration = 7.121` (= 7h07m15.6s) after `round(_, 3)`. Back-projection yields `datetime_start = 07:07:14 - 7.121h = 02/05 23:59:58`, overlapping by ~2s with the prior line ending at `02/05 23:59:59.999`. __Fix:__ Sort lines by `time_stop` within each date and clamp `datetime_start` to the previously emitted interval's stop when the two intervals genuinely intersect. opw-6170828 Forward-Port-Of: odoo/enterprise#121564 Forward-Port-Of: odoo/enterprise#116565
This update corrects how two internal guided flows simulate user typing, so they now behave more like a real person using the interface. It helps prevent Knowledge tours from failing and makes Studio text insertion work more reliably.
Original PR description
#### Description of the issue: - Since the search powerbox plugin now checks for the actual existence of `/` in the DOM, some knowledge tours were failing because only the input event was dispatched without inserting `/`. - In web_studio, `insertText` was not positioning the selection correctly after insertion and was not dispatching beforeinput event before the DOM insertion. #### After this commit: - Adapt the `openPowerbox` utility in knowledge to insert `/` in the DOM before opening the powerbox. - Dispatch `beforeinput` before DOM insertion and `input` after it in web_studio, and move the selection after the inserted text. Community PR-https://github.com/odoo/odoo/pull/266284 task-6243724 Forward-Port-Of: odoo/enterprise#118310
PDF generation for certain Guatemala vendor bills could fail with an error, preventing users from downloading the document. This update corrects the data setup and template reference so the PDF can be generated successfully again.
Original PR description
**Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a `GT Company`. - Create a new vendor bill with: - Vendor: GT Company - GT Document Type: `FESP` - Add taxes `VAT Withholding…
**Steps to reproduce:** - Install the `l10n_gt_edi` module and switch to a `GT Company`. - Create a new vendor bill with: - Vendor: GT Company - GT Document Type: `FESP` - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines. - `Confirm` the bill and `Send to SAT`. - From the gear icon, click `Download` > `PDF`. **Error1:** `KeyError: 'gran_total'` **Error2:** `KeyError: 'retencion_grand_total'` **Root Cause:** In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` before `_l10n_gt_edi_add_withholding_values()`. However, `_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`. Additionally, the report template at [3] references `retencion_grand_total` instead of the correct key `retencion_gran_total`, causing another `KeyError`. **Fix:** This commit prevents errors and ensures users can successfully download the PDF by applying a fix similar to [4], [1]: https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8 [2]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328 [3]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72 [4]: https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800 opw-6323049 Forward-Port-Of: odoo/enterprise#122398 Forward-Port-Of: odoo/enterprise#122030
This change prevents the system from crashing when a session entry is missing an expected trust flag. It improves stability for affected devices and sessions by handling incomplete data safely instead of failing.
Original PR description
Some devices may not have a `trusted` key in their entry. This is the case for sessions created between these two commits: - https://github.com/odoo/odoo/commit/b6c2aafae2112ef98edca8a7f027716d9c15be11 - https://github.com/odoo/odoo/commit/61f22175ef3df37087887e7419dac54a620bbd55 Task-6348650 Forward-Port-Of: odoo/odoo#273062
This update prevents manually entered timesheet details from disappearing when users close the Timesheets systray after saving or resetting an entry. It helps ensure the description, project, and task they entered are kept and shown again later, reducing user frustration and rework.
Original PR description
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install…
## Issue When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray. ## Steps to reproduce 1. Install *Timesheets* (`timesheet_grid`) 2. Open the Timesheets systray 3. Click *Reset* and set a description, a project and/or a task, then close the systray 4. Open the systray again 5. **The description/project/task set in step 3 do(es) not appear anymore.** ## Cause Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`: https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174 ## Fix After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore. opw-6284016 Forward-Port-Of: odoo/enterprise#121605
This update prevents the editor menu from opening when an emoji shortcut is typed and converted into an emoji. It also makes emoji shortcuts work more reliably within a paragraph, so users can insert emojis without unexpected interruptions.
Original PR description
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler`…
#### Description of the issue this PR addresses: - When an emoji shortcut ending with `/` (e.g. `:/` for 😕) is typed, the emoji plugin replaces the characters before the powerbox `on_input_handler` runs. Since `ev.data` still reflects the original typed `/`, the powerbox was incorrectly opening. - Emoji shortcuts works only when it is used at the end of a text node, because the matching logic checked the whole remaining substring from the current position. - Sometimes, pressing Backspace splits one text node into two, and then an emoji shortcut works at the end of the first text node even when the paragraph is visible as a single line. #### Desired behavior after PR is merged: - Check the DOM character at cursor position instead of `ev.data` to determine whether `/` is actually present before opening the powerbox. - Emoji shortcuts now works when used with a preceding space anywhere in the paragraph. Enterprise PR-https://github.com/odoo/enterprise/pull/118310 task-6243724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266284
This fix makes UNSPSC code 10171500, “Organic fertilizers and plant nutrients,” available again in the product accounting list. It matters because users can now correctly classify these products when setting up product accounting information.
Original PR description
The code 10171500 - Organic fertilizers and plant nutrients wasn't appearing. In the file that has the unspsc product codes this one was set to False. Steps to reproduce: - Activate module product_unspsc. - Go to product > accounting. - Verify that this code is not listed. Ticket [link](https://www.odoo.com/odoo/project.task/4461974) opw-4461974 Forward-Port-Of: odoo/enterprise#121914
The Point of Sale now shows the real underlying error when a database transaction fails instead of a generic message. This makes it easier to understand what went wrong and speeds up troubleshooting.
Original PR description
Before this commit the error "Transaction could not be created" was thrown when the transaction could not be created. This commit changes the behavior to throw the actual error that caused the transaction creation to fail, providing more context for debugging. Forward-Port-Of: odoo/odoo#273116
The attendance overtime calculation now includes all work periods that overlap the updated day, even when an attendance crosses midnight. This prevents overtime from being undercounted in cases where a later attendance was previously calculated without taking earlier overlapping hours into account.
Original PR description
Issue: ---------------------------------------- The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap. Steps to reproduce:…
Issue:
----------------------------------------
The overtime calculation ignores attendances overlapping midnight when creating an attendance on the day they overlap.
Steps to reproduce:
----------------------------------------
- Have the standard 8 hours per day working schedule
- Use the default overtime ruleset:
- Quantity, per day, more than the contract
- Have no rule on weeks
- Create an attendance of 8+ hours overlapping midnight on a day:
- From 10pm to 10am (2h + 10h = 12h)
- Create another attendance on the day the first ended:
- From 2pm to 6pm (4h)
- The first attendance has 2h of overtime:
- 0h from the first worked day (from 10pm to midnight = 2 < 8)
- 2h on the next day (10h worked from midnight to 10am)
- The second attendance have 0h of overtime even though it should be 4h
- We only considered this attendance in the calculation, ignoring the 10h worked in the morning
Cause:
----------------------------------------
In `_update_overtime()` we create a domain to include all useful attendances in the calculation. As all rules are based on days, the domain will use the date of the attendance to get overlapping attendances. But the date of the attendance is the date of its `check_in` ([src](https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/hr_attendance/models/hr_attendance.py#L91)). So when creating the second attendance, the domain only fetches attendance with their `date` on the same date as the `check_in` of the second one. This excludes the first one even though it overlaps on the same day.
Solution:
----------------------------------------
Don't use `date` but `check_in` and `check_out` in the domain to really get all attendances overlapping a day with an updated attendance.
As this domain was used on both `hr.attendance` and `hr.attendance.overtime.line`, we adapt it so it uses the correct fields (`time_start` and `time_stop`) from the overtime lines.
opw-6253777
Forward-Port-Of: odoo/odoo#272447This fix ensures the Italian withholding tax return is calculated independently from the regular tax return. As a result, the amount due on a withholding return no longer incorrectly includes balances from other tax returns, preventing wrong payment amounts.
Original PR description
Steps to reproduce: - setup an Italian company - make an invoice (for example in May) with a withholding tax and make a transaction to pay it - generate tax returns (opening date in June so that it generates from May) - validate regular tax return for May - validate withholding tax return for May -> The withholding tax return shows an amount to pay with a balance that is a combination of both the regular tax return and the withholding one, while it should be independent of the regular one. task-6116304 Forward-Port-Of: odoo/enterprise#121254 Forward-Port-Of: odoo/enterprise#119375
This change fixes an automated test in the self-order point of sale feature that could incorrectly create multiple orders for the same table. It ensures the test uses a separate table per configuration, preventing false failures in validation and build checks.
Original PR description
In the test test_self_order_table_sharing, the test could fail due to multiple orders being created for the same table on different config since the same table was used on multiple config. This commit fixes this test by creating a new table for the config. runbot-error: 240898, 240896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253862 Forward-Port-Of: odoo/odoo#253081
This fix adds descriptive alternative text to language flag images when the website language selector shows flags without text. It improves accessibility for screen readers and gives search engines the context they need to understand the language options.
Original PR description
Steps to reproduce: 1. Enable the language selector in the website header. 2. Enable the "Inline" and "Flag" options. 3. Inspect the flag images rendered in the inline variant. Issue: Flag images in the list items have an empty `alt=""` attribute in "Flag only" mode, where the flag is the sole visual indicator of the language, making the selector inaccessible to screen readers and providing no context for search crawlers. Expected behavior: Inline + Flag should have a descriptive ALT tag since there is no adjacent text or code to identify the language, the flag is not decorative. opw-6246464 Forward-Port-Of: odoo/odoo#273025 Forward-Port-Of: odoo/odoo#271362
The translation dialog now shows translated text with a cleaner, more consistent layout in normal use. In debug mode, translations are no longer preselected when multiple options exist, which helps avoid accidental choices and makes the confirmation button stay disabled until a selection is made.
Original PR description
Before the commit: the translated text is with green background color. In debug mode, the translation generated by the last translator is selected by default. After this commit: In non-debug mode, the translated text is now wrapped in a div and with a similar style as the previous versions. In debug mode, when there are multiple translators, the translated text is no longer automatically selected. When there's no translation selected, the confirm button is disabled. The translated texts are now wrapped inside gray/dark gary background color. task-6250193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents the accounting automation from marking work as complete when an unexpected error occurs. As a result, failed items are less likely to be skipped silently, improving the reliability of scheduled posting tasks.
Original PR description
The previous fix commits progress even when an unexpected exception escaped the loop iteration when _autopost_draft_entries. Now progress is only committed on success or when a UserError is explicitly handled. Reference: https://github.com/odoo/odoo/pull/271509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273115
Public links for shared audio files will no longer try to play in the browser preview. This avoids Chrome-specific preview failures and keeps the sharing experience consistent by downloading the file instead of exposing it as streaming media.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a sound file (mp3 for example, but the behavior is the same for other formats) - Share the document and copy the link - Log out - Paste the…
**Steps to reproduce:**
- Install Documents app
- Upload a sound file (mp3 for example, but the
behavior is the same for other formats)
- Share the document and copy the link
- Log out
- Paste the link
- Click on preview button
- Media is working fine on Firefox
- Media won't read on Chrome
```
Loading media from '' violates the following Content Security Policy directive: "default-src 'none'".
Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback.
The action has been blocked.
```
**Issue:**
Since [1] default CSP Headers are too strict for Chrome default media rendering, which breaks the file preview (and force user download).
This only impacts Chrome as they seem to render generate `<video><source>` elements to render the file which triggers a secondary request and fails due to the CSP constraint.
**Fix:**
Could re-apply the header fix of 17.4 (see [2]), but it seems better to block the preview of audio files as well by default (to match how we manage videos).
(Note: we don't want to be used as a media streaming platform)
[1] (set csp to none by default) https://github.com/odoo/odoo/commit/64beb80205dffe4b432c8b5813a3271b073fa85e
[2] (similar issue which was not fixed in 18.0+) https://github.com/odoo/enterprise/commit/a7af78eeb2b9763045a5bda8714172f5e7402df8
[3] (mp4 preview removed) https://github.com/odoo/enterprise/commit/ea88cf7c6d5f077b60fb59347659507fded0e2fe
opw-6235043
Forward-Port-Of: odoo/enterprise#119644The website cookie bar now keeps the intended spacing between buttons and links, even when edited in the page builder. This prevents the elements from appearing cramped or touching each other in the “Discrete” layout.
Original PR description
[FIX] website: preserve cookie bar button spacing Steps to reproduce: - Enable the cookies bar in the website settings. - Go to the website and enter edit mode. - Open the cookies bar from the invisible elements panel. - Select the "Discrete" layout in the options. => The buttons and link are rendered without the expected spacing. Before this commit, the client-side cookie bar template relied on whitespace-only text nodes to separate inline elements. Those nodes are not kept in the same way when the template is rendered by Owl, so selecting the layout could make adjacent buttons touch each other. After this commit, the spacing is carried by explicit Bootstrap spacing classes, so the rendered layout no longer depends on text nodes preserved by the XML formatting. task-6251151 Forward-Port-Of: odoo/odoo#272641 Forward-Port-Of: odoo/odoo#267488
Fixed an issue that could prevent POS managers from saving changes to a POS configuration when self-order images had been uploaded by someone else. This removes an unnecessary access error so teams can manage POS setups without needing Settings or Admin rights.
Original PR description
When editing a POS config, `_ensure_public_attachments` wrote `public=True` on the self-ordering background/home images on every write. These images are Many2many attachments created with a `res_model` but no `res_id`, so the attachment access check denies write to any non-system user who is not their creator.
As a result, a POS manager without Settings/Admin rights could not edit a config whose images were uploaded by another user (e.g. an admin during setup), getting:
AccessError: Sorry, you are not allowed to access this document.
(Operation: write) - Records: ir.attachment(...), User: ...
Steps to reproduce:
1. Enable self-ordering on a POS and select a background image
2. Set self-ordering back to disabled
3. Log in as a POS admin without Admin/Settings rights
4. Try to edit the POS -> error
opw-6331261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273299This update fixes an unreliable test in the Viva.com POS payment flow that could sometimes hang during automated runs. It now waits for the payment step to complete before sending the simulated webhook response, making the test process more stable and dependable.
Original PR description
The Viva.com POS tour was failing intermittentely due to the mocked webhook response not waiting for the payment/refund request to finish. This would cause the tour to hang as it missed the webhook confirmation. We fix the issue by changing the `waitingCard` status to only be set after the payment request returns, and wait for this status before sending the fake webhook response. runbot-243758 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273111
This update corrects the GSTR-1 export for SEZ invoices issued in foreign currency so the invoice value is shown in the company currency, INR, instead of the foreign currency amount. This helps ensure the GST return spreadsheet reflects the proper values for filing and reporting.
Original PR description
Currently, when generatign GSTR-1 return spreadshee, SEZ invoices issued in a foreign currency are exported with their totals in the foreign currency rather than the company currency (INR) Steps to reproduce: - Create a B2B SEZ invoice in foreign currency - Go to Accounting > Reporting > [India] GST Return periods - Generate the GSTR-1 report for the period Issue: In the resulting spreadsheet, the "Invoice Value" column takes the invoice total in USD rather then INR opw-6292913 Forward-Port-Of: odoo/enterprise#121972 Forward-Port-Of: odoo/enterprise#121157
This update fixes two manufacturing issues that could block production completion in certain multi-step and split-order scenarios. It ensures expected component quantities are correctly taken into account even when reservations are missing, and prevents an invalid negative reservation error when generating serial numbers on split manufacturing orders.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set your warehouse to manufacture in 2 steps (pick then manufacture). - Create a final product (FP) with a BOM in flexible…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set your warehouse to manufacture in 2 steps (pick then manufacture). - Create a final product (FP) with a BOM in flexible consumption: - 1 x COMP (lot tracked) - Create and confirm an MO for 1 units of FP - Set the quantity producing on the MO to 1 > The consumed qty was updated to 1 unit - Set a lot on the pre-production pikcing and validate #### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less ### Cause of the issue: The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand: https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426 In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been. Issue 2: Steps to reproduce: - In the settings Enable Multi-Steps Routes - Unarchive MTO - Create 3 products: - Final Product: Tracked by SN with a BOM: 1 X Super Component - Super Component: Tracked by SN, MTO with a BOM: 1 X Component - Basic Component: Put 10 units in stock - Create and confirm an MO for 3 units of Final Product > This should create an MO for 3 units of Super Component - Go to the Child MO > Cogs wheel > Split in 3 MO's - Click "Generate serial" on each Child MO and validate the first one - On the MO for Final Product > Cogs wheel > Split in 3 MO's - On the first MO, click "Generate Serial" > Error: Reserving a negative quantity is not allowed. ### Cause of the issue: The `action_generate_serial` calls in turn the `set_qty_producing`: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601 However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426 But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error: https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470 opw-6128575 opw-6317083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273168 Forward-Port-Of: odoo/odoo#271123
This update resolves issues with the loyalty program module, ensuring new invoices correctly award points based on defined rules. Previously, the system defaulted to a flat point amount and incorrectly invoiced negative amounts when loyalty points were exhausted. This fix improves the accuracy and reliability of the loyalty program for our subscription customers.
Original PR description
This commit fixes the following problems in the new module: - New invoices sometimes could not grant points according to the specified rules. - The reward point mode was not being taken into account and was giving a flat amount of points. - Reward lines were being invoiced with a negative amount when there was no more points in the loyalty card. - The 'Recurring' option in conditional rules and reward were not showing sometimes for an unknown reason. task-6153127
This update adjusts the appearance of a key button within Odoo to align with the previous version's design (M3). Additionally, the code has been simplified by removing custom styling and leveraging existing Odoo components, and a touch device issue related to hover states has been addressed. This ensures a consistent and user-friendly experience.
Original PR description
In this commit, we adjust the margin/padding of the `boolean_icon_field` button to match the M3 design. We also remove the custom CSS and rely on existing `bootstrap` classes that provide the same behavior. Finally, we remove the hover color on touch devices, since a tap can trigger the hover state, but there isn’t a proper "unhover" afterward because the element remains focused. task-6305864 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents the preparation display from crashing when a customized product line is deleted in the PoS. Previously, deleting a line with a custom attribute value caused a blank screen, disrupting order processing. The fix ensures the display remains functional by gracefully handling the removal of the associated order line.
Original PR description
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display…
When an order is sent to the preparation display and one of its products has an attribute with a custom (free text) value, completely deleting that line in the PoS makes the whole preparation display crash and show a blank white screen, so the kitchen can no longer see any order. Steps to reproduce: ------------------- * Configure a PoS product with an attribute whose variant that has a custom (free text) value. * In the PoS, add the product, select that attribute value and send the order to the preparation display. * Back in the PoS, completely delete that order line (do not just set its quantity to 0) and send the order to the preparation display again. > Observation: The preparation display crashes and only a white screen is shown. The browser console reports "TypeError: Cannot read properties of undefined (reading 'id')". Why the fix: ------------ Completely deleting the line deletes the source pos.order.line, so the preparation line that is still displayed no longer resolves its `pos_order_line_id`. While building the attributes to display, the orderline component dereferenced `.id` on that (now undefined) relation, as well as on the related custom value records, which threw and brought down the whole preparation display instead of only that line. We now guard those relations: when the originating order line is gone, the unresolvable custom value is simply dropped and the attribute is still shown, keeping the preparation display alive. opw-6282607
This change reverts recent updates that allowed employees to directly edit personal information like marital status. Management requested this to mitigate risks to payroll accuracy and compliance, as this data impacts tax deductions and benefits. HR will now maintain this information to ensure data integrity and legal documentation.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031 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
This update reverts a recent change that allowed employees to directly edit sensitive payroll information like marital status. This change was removed due to concerns about potential inaccuracies impacting tax calculations and compliance. HR will now maintain all payroll-related data to ensure accuracy and adherence to regulations.
Original PR description
This reverts the recent changes that exposed the "Family" and "Personal Info" sections (such as Marital Status) in the employee's "My Preferences" menu. While the initial addition was intended to improve employee self-service, management requested this revert because allowing employees to directly edit these fields poses a risk to payroll accuracy and compliance. Data points like marital status or family dependents directly impact tax deductions and benefit enrollments. To ensure data integrity, any modifications to payroll-affecting information must remain the exclusive duty of the HR team, who can require and verify the proper legal documentation before updating the system. task-6304031
This update corrects a problem in the automated tests for Odoo's payroll module. The fix ensures that tests accurately reflect access permissions for different employee types, preventing potential issues with payroll calculations. This improves the reliability of the payroll system and reduces the risk of errors.
Original PR description
task-6348716
This update enhances the accuracy of clock-in and clock-out data sent to the blackbox, preventing potential errors. It also strengthens the system's stability by preventing conflicting clock entries and automatically logging cashiers out when a screen is idle.
Original PR description
Trim strings data before sending to the blackbox. Also make clock-in/out more robust: - call handleClockInOut through a Mutex to avoid concurrent races - clock the cashier out when the idle SaverScreen is shown FW of this PR: https://github.com/odoo/enterprise/pull/122471
This update resolves an issue where header text on mobile was too dark against certain background colors, making it difficult to read. The fix corrects a conversion error that prevented CSS styling from applying correctly, ensuring optimal text contrast and readability for users.
Original PR description
Steps to reproduce: - Set the header position to "Over the Content" - Set the background color to the last preset (dark) - Go to mobile view => If you are at the top of the page when opening the menu, the text is too dark to be readable. When the conversion from publicWidget to interaction was done, a mistake was made when converting HeaderGeneral. `o_top_menu_collapse_shown` was not toggled on `header#top` anymore. Therefore some css was not applied, leading to issues with the color constrasts. This commit fixes this issue by fixing the selector in dynamicContent. task-6311038 Forward-Port-Of: odoo/odoo#271410 Forward-Port-Of: odoo/odoo#270560
This update fixes an issue where customer names weren't being correctly populated when booking appointments through Google Reserve with Google. Now, customer names (first and last) from the Google booking are accurately displayed in Odoo, improving the user experience and ensuring accurate contact information for appointments.
Original PR description
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to…
When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177 That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc. Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name. Steps to reproduce: 1. Enable Reserve with Google on an appointment type. 2. Book a slot from Google Maps with given name John and family name Doe. 3. Open the created booking and its contact in Odoo. => the contact name is the email instead of John Doe Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318) opw-6232318 Forward-Port-Of: odoo/enterprise#120604
This update resolves an issue where users could select customers from different companies within the Helpdesk module. The fix adds a restriction to the customer dropdown, ensuring users only see customers from their own company. This prevents data inconsistencies and improves the accuracy of Helpdesk ticket management.
Original PR description
Steps to reproduce: - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - Customers from other companies are visible in the customer field, Cause: - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - Added a domain on partner_id in the ticket quick create form view. task-4971466 Forward-Port-Of: odoo/enterprise#122358 Forward-Port-Of: odoo/enterprise#121944
This update fixes an issue where flexible employee schedules were incorrectly calculating weekly hours, leading to inaccurate hour projections. By aligning the week start day with the user's locale setting (e.g., Sunday instead of Monday), the system now accurately reflects the employee's available work hours, ensuring accurate planning.
Original PR description
**Steps to reproduce** - Install planning - Switch to English (UK) and change the "First day of the week" to Sunday in the technical settings - Have an employee with a flexible schedule with a total of 40h/week, average 8h/day - In the planning app, after creating a shift to display the employee in the gantt view, notice that when hovering over the progress bar on the left, 48 worked hours are expected for the current week, which is more than what is defined in the employee's calendar **Cause** The displayed week, starting on Sunday, could accumulate more hours than the weekly cap due to the Sunday being part of another week with the locale default first day (Monday). opw-6110395 Forward-Port-Of: odoo/odoo#272900 Forward-Port-Of: odoo/odoo#259600
This update fixes an issue where the activity counter in the Odoo interface was displaying incorrect values, sometimes going negative. The root cause was a mismatch between how the counter was calculated on the server and client sides. The fix ensures the counter accurately reflects the number of relevant activities, improving the user experience.
Original PR description
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there…
# Setup Ensure you currently have no activity # How to reproduce - Go to any form view with a chatter (e.g. Quotation form view) - Add 2 activities with a due date of today or before > Notice there activity counter next to the activity clock icon in the top right should be 2 - Click on the activity clock icon in the top right > Notifce the activity counter decreases to 1 - Mark as done both To-Do activites # The problem The activity counter is negative # Cause This issue is due to a desync between the activity counter client side and server side. When clicking on the activity clock icon, the front-end fetches the mail store data from the backend, which is why we see the activity counter decrease. The server computes the activity counter the following way : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457 It searches for up to 1000 activities and group them by the record they are associated to (e.g. a sale.order). Then, for each of these records, if atleast one activity is late or for today, increase the counter by 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509 Essentially, server side, we get a single +1 in the activity counter by record, not by activity On the other hand, client side, we simply add 1 in the activity counter every time a new activity is created. If an activity is deleted, then we remove 1 : https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30 https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309 # Proposed solution Both the client and server side logic were edited fairly recently Server side : https://github.com/odoo/odoo/pull/234899 Client side : https://github.com/odoo/odoo/pull/215880 According to experts, the activity counter should count records, not activities, so we should fix the client side but properly doing so would introduce too much complexity. We instead simply prevent the counter from going below 0. opw-6116821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259602
This update fixes an issue where splitting a restaurant order didn't correctly carry over the original order's fiscal position and pricelist to the new order. Now, when an order is split, the new order inherits the correct tax settings and pricing rules, ensuring accurate financial reporting and customer billing. This improves order accuracy and reduces potential errors.
Original PR description
When splitting an order, the new order was created without the original's fiscal position and pricelist, so its lines fell back to the default taxes Steps to reproduce: 1. Create a fiscal position with some tax mapping 2. Create a pricelist with some price rules 3. Add the fiscal position and pricelist to the delivery preset 4. Create a restaurant order as delivery 5. Split the order 6. Pay both of them 7. First order will have the default taxes and prices list instead of preset's ones Part of: https://github.com/odoo/odoo/pull/268862 -opw-6246434 Forward-Port-Of: odoo/odoo#273174 Forward-Port-Of: odoo/odoo#272837
A recent issue in the Odoo barcode scanner was preventing it from working correctly in the latest Brave Browser. This update automatically restarts the video preview after the first scan, ensuring a smooth scanning experience. This fix improves usability for all users.
Original PR description
Issue: ====== - In the latest Brave Browser version (1.90+), the first scan works properly, but the video preview disappears during the second scan. Fix: ==== - During the second scan, the video is unexpectedly paused. We now automatically play the video again if it is paused. task-6218047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265436
This update fixes a potential issue where users could refund an order line more times than allowed, leading to inaccurate financial reporting. The change now ensures that refunds are limited to the original amount refundable, improving the reliability of point-of-sale transactions. This resolves a previous vulnerability (opw-6340931) and protects against financial discrepancies.
Original PR description
Before this commit, if an order line was already refunded, it was possible to refund it again. opw-6340931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272408
This update fixes a bug where minimal rights employees could accidentally enter negative quantities when using the keyboard. The fix prevents users with restricted permissions from using the '-' key to modify quantities, ensuring accurate order management. This improves data integrity and reduces the risk of errors.
Original PR description
Currently minimal rights employee cannot select the "+/-" button to have a negative quantity line. However if they have a keyboard and press the "-" key they can modify the quantity to negative. Steps to reproduce: ------------------- * Modify the shop settings, give some employee minimal rights * Open shop and use the minimal employee as cashier * Add a product to the order * Press the "-" key on the keyboard > The line quantity becomes -1 Why the fix: ------------ The button on the product screen is disabled for the employee with minimal rights https://github.com/odoo/odoo/blob/4a2aa33ded628200935b22c501a5f94c21dffb1f/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L154 We extend that to the input key "-". opw-6248098 Forward-Port-Of: odoo/odoo#267748
This update corrects a bug where quality checks remained active after merging multiple Manufacturing Orders. Previously, the merge process didn't trigger the standard cleanup, leading to unnecessary quality check entries. This fix ensures that pending quality checks are automatically removed when Manufacturing Orders are merged, streamlining the workflow.
Original PR description
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that…
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that product - Create and confirm multiple Manufacturing Orders - Verify that each MO generates a quality check - From the MO list view, select the MOs and merge them from the gear menu(merge) Issue: ------ When Manufacturing Orders are merged, All MOs are cancelled but it keep their quality checks in the 'To Do' state. As a result: - The quality checks remain linked to cancelled MOs - The 'Quality Checks' smart button is still displayed on cancelled MOs Expected behavior: ------------------ - Pending quality checks should be deleted when the MO is cancelled - The 'Quality Checks' smart button should no longer be displayed Cause: ------ A previous fix introduced logic to remove pending quality checks when a Manufacturing Order is cancelled: odoo-dev@db93bd2 This logic was implemented in `action_cancel()` by unlinking quality checks associated with the cancelled MO: https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97 However, when MOs are merged, the merge flow does not call `action_cancel()`. Instead, it directly invokes `_action_cancel()` on the source Manufacturing Orders: https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480 Since the quality check cleanup is implemented only in `action_cancel()`, it is bypassed during the merge process. As a result, the source MOs are cancelled but their pending quality checks remain in place. --- opw-6260735 Forward-Port-Of: odoo/enterprise#121809 Forward-Port-Of: odoo/enterprise#119525
This update ensures that VAT displayed on exported invoices is correctly translated into the customer's chosen language, rather than the user's. Previously, VAT was shown in English regardless of the customer's preferred language setting. This change improves accuracy and a better customer experience.
Original PR description
Issue: While exporting an invoice as PDF, Customer VAT is translated according to user language instead of customer chosen language. Steps to reproduce: - In a Belgian company - Install Greek language, but keep English as user language - Create a Customer and select Greek as their language - Create an invoice - Export as PDF Current behavior: - VAT is displayed in user language Expected behavior: - VAT is displayed in customer language (ΦΠΑ) opw-6264065 Forward-Port-Of: odoo/odoo#270574
This update fixes an issue where refund discounts were incorrectly calculated in the sales details report. Previously, refunds inflated discount amounts instead of canceling them, leading to inaccurate reporting. This change ensures refunds are properly accounted for, providing a more reliable view of sales discounts.
Original PR description
The sales details report computes a line discount as `original_price - price_subtotal_incl`. On a refund line the quantity is negative, so `original_price` is negative, while `price_subtotal_incl` is stored positive. Subtracting the two then inflates the discount instead of cancelling it, understating "discount_amount" by `2 * price_subtotal_incl` for every refunded discounted line. opw-6281752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271008 Forward-Port-Of: odoo/odoo#270592
This update fixes a misclassification of sales from European companies to Northern Ireland (XI) customers. Previously, these service sales were incorrectly treated as intra-community transactions, leading to potential tax discrepancies. The change adds a check to ensure these sales are accurately categorized as third-country transactions, aligning with regulations.
Original PR description
…stomers The services sales done from a European company to a Northern Ireland (XI) company should not contain intra-community taxes but should be treated as third country (non-EU) transactions. We solve it by adding a check in the EC Sales List return that is only visible when a wrong record occurs. task-6007931 Forward-Port-Of: odoo/enterprise#121487
This update fixes an error in the generation of CFDI documents when payments are made in foreign currencies (like USD). Previously, the CFDI document incorrectly displayed the payment amount and rate. The fix ensures the correct payment amount and rate are used, accurately reflecting the transaction details for Mexican tax reporting.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#121515 Forward-Port-Of: odoo/enterprise#115779
This update ensures GIF functionality in Odoo continues to work smoothly. The system has switched from the now-discontinued Tenor GIF API to the Klipy GIF API. Users should update their API keys to Klipy to maintain GIF support, as the Tenor key will no longer be valid.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit makes the Tenor API key input settings use a Klipy GIF API key instead of a Tenor GIF API key. To keep GIF working after this commit, the API key must necessarily be changed to a Klipy GIF API key, as the old Tenor API key would be considered as an invalid Klipy API key. Task-5491965 Upgrade: https://github.com/odoo/upgrade/pull/10516 Forward-Port-Of: odoo/odoo#272898 Forward-Port-Of: odoo/odoo#250113
This update fixes an issue where the quantity invoiced on a sale order wasn't correctly updated after a refund was processed from the PoS. The fix ensures that refund amounts are accurately reflected in the sale order's invoice quantity, resolving a previous inconsistency between PoS and backend refund processes. This improves the accuracy of order reporting and reconciliation.
Original PR description
When making a refund of a PoS order that was created from a sale order, the sale order qty_invoice was not updated correctly. Steps to reproduce: ------------------- * Create a sale order with any product and confirm it * Open a PoS and settle the order * At this point the qty_invoiced should be 1 on the sale order line * Refund the PoS order from the PoS > Observation: The qty_invoiced is still one. Why the fix: ------------ We now take refund lines into account when computing the qty_invoiced. Note: ------------ There was an inconsistency between a refund made from the PoS and a refund made from the backend. The former is not linking the sale order line to the refund line, while the latter does. This was causing issue when refunding from the backend as it would count the refund twice. To fix this we now remove the link to the sale order line when refunding from the backend. opw-4991405 Forward-Port-Of: odoo/odoo#273132 Forward-Port-Of: odoo/odoo#259653
This update ensures that only complete and accurate address data is sent to Fiskaly for POS certifications. Previously, placeholder values like 'N/A' were included, which is now corrected to only send available information, streamlining the process and improving data quality. This change avoids unnecessary data transmission and potential issues with Fiskaly.
Original PR description
In this commit: ------------------- - Buyer address fields are optional and should only be sent to Fiskaly when they are actually available. - Avoid sending placeholder values like "N/A". If the data is not present, the fields should simply be omitted from the request. task: 6113133 Forward-Port-Of: odoo/enterprise#122188 Forward-Port-Of: odoo/enterprise#113621
This update resolves a problem where completed documents in the sign module were displaying inconsistent access rights. The fix ensures that the permissions associated with finalized documents are accurate and reliable, improving the overall security and functionality of the document signing process. This change enhances the trust and reliability of digital signatures within Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#121576
This update fixes an issue where the cost of goods sold (COGS) for products manufactured using the MTO (Make-To-Order) production route wasn't accurately reflecting the FIFO (First-In, First-Out) inventory method. The fix ensures that the invoice COGS now correctly uses the actual lot cost, leading to more accurate financial reporting. This resolves a discrepancy between standard product prices and the true cost of materials.
Original PR description
### Steps to reproduce: - Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP - Create, confirm and validate an MO for 10 unit of P…
### Steps to reproduce: - Create a storable product P tracked by SN, fifo perpetual lot valuated using the MTO route and with a BOM: 1 x COMP - Create, confirm and validate an MO for 10 unit of P using COMP's at 10$ (by setting its standard price). - Create and confirm a Sales Order for 1 unit of P > This generate an MO - Validate this MO for a new serial say SN011 using a COMP at 20$. - Validate the Delivery Order using SN011 - Create and post the customer invoice #### > The invoice COGS uses Std Price rather than the 20$ lot's fifo value ### Cause of the issue: The cogs value are generated based on the moves returned by the `_get_stock_moves` call of the acount.move.line: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/account_move_line.py#L66-L68 Currently, if an account.move.line is linked to a sale.order.line, this methods returns the entire pull of stock moves linked to the sol: https://github.com/odoo/odoo/blob/79c9e7de6764e7f8e47709b827df6eee81e72637/addons/sale_stock/models/account_move.py#L155-L156 However, these moves include both, the delivery move and the `move_finished_ids` of the MTO prodcution. This is problematic since the delivery move is considered as positive cogs qty and the MO is considered as incoming cogs qty leading to a sum of 0 cogs qty which in turns make the cogs price unit fall back to the product standard price instead of the fifo cost of the produced lot.: https://github.com/odoo/odoo/blob/6a356cb0640ce20c71f20a8bd64ef99e76a82489/addons/stock_account/models/stock_move.py#L257-L271 opw-6292048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272815 Forward-Port-Of: odoo/odoo#271018
This update fixes an issue where payment states weren't correctly updated after changing an invoice's price, specifically for group payments. The change ensures that all payments transition to 'In Process' when a statement reconciliation fails, preventing reconciliation errors and improving payment processing reliability.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273090 Forward-Port-Of: odoo/odoo#269510
This update fixes an issue where group payments weren't correctly updated when a statement line was unreconciled. The change ensures that all payments, including group payments, transition to 'In Process' state when a payment reconciliation fails, allowing for accurate accounting and reporting. This resolves a discrepancy in payment status during reconciliation.
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A *…
**Steps to reproduce:** - Install Accounting - Create an invoice: * Customer: Partner A * Total: 30.00 - Confirm the invoice - Create a second invoice for the same customer: * Customer: Partner A * Total; 10.00 - Confirm the invoice - From the invoice list, select both invoice - Create payment: * Journal: Bank * Group Payments: [checked] * Group Payments: [checked] * Amount: 40.00 - Create a third invoice for another customer: * Customer: Partner B * Total: 25.00 - Confirm the invoice - Register payment from the invoice - Create a fourth invoice for another customer: * Customer: Partner C * Total; 40.00 - Confirm the invoice - Register payment from the invoice - From the payment list, select all 3 payments and create batch payment - Validate the batch payment - From Accounting dashboard, open Bank journal - Create a new bank statement line of 105.00 - Match it with the batch payment At that point, the statement line is reconciled with the 4 invoices and the 3 payments are marked as paid. - Go to the fourth invoice - Reset it to draft - Change the price - Save When the amount of the invoice is changed, the statement line is unreconciled and all the payments should change state from "Paid" to "In Process". **Issue:** All the single payments have their state correctly changed to "In Process", except for the group payment for the 2 first invoices, which leads to undesired values when trying to reconcile the statement line with the batch payment again. **Cause:** When the statement is unreconciled, all the partial reconcile records are deleted and the state of the linked payments are updated to "In Process". The payments are retrieved by checking if there are linked to an account move present in the partial reconcile record and if the amount of the payment matches the amount of the partial reconcile record. In case of a group payment, there are 2 partial reconcile records for each invoice linked to the payment. Therefore, in that case, the amount doesn't match the amount of the payment because it matches the amount of one of the invoice. opw-6141089 Forward-Port-Of: odoo/enterprise#122280 Forward-Port-Of: odoo/enterprise#120210
This update fixes a payrun error that occurred when employees had multiple versions recorded within the same month. The issue stemmed from a calculation error when processing worked hours, leading to a system crash. This change ensures accurate payrun processing for employees with multiple versions.
Original PR description
Currently, there is an error while running payrun step with employee who has multiple version in 1 month. ``` number_of_hours = (work100_wds - worked_day).number_of_hours ValueError: Expected singleton: hr.payslip.worked_days(233, 234) ``` Step to reproduce: 1. Create Employee with multiple version in 1 month 2. Create New PayRun during that month 3. Run the PayRun until Payslip step 4. Expected error on payslip steps reason: substraction of work100_wds and worked_day generate more than 1 value, if we have multiple version in 1 month task-6296276
This update fixes an issue where thread messages were not displaying properly due to a technical problem with how the system tracked loading states. The change ensures that thread messages are reliably rendered, improving the user experience when viewing conversations. This was a bug related to how the system monitored loading status and triggered updates.
Original PR description
The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces…
The Thread component mirrors `thread.isLoaded` into `state.mountedAndLoaded` with a `useEffect` whose body only re-runs when the component re-renders (in `onPatched`). `reset()` forces `mountedAndLoaded` false and bumps `resetCount`, a dependency of that effect, so the mirror is meant to re-sync after a reset. But `resetCount` was a plain instance field. The effect's dependency function reads it, and OWL only re-renders (hence re-runs the effect) when a value the render observed changes; a plain field is not reactive, so reading it observes nothing. Bumping it therefore never scheduled a render, and the mirror only re-ran when some other reactive write happened to schedule one. When a `reset()` lands while `mountedAndLoaded` is already false (a no-op write) with `isLoaded` true, and no such write follows, no render is scheduled: the mirror never re-runs and `mountedAndLoaded` strands at false, so the empty phantom list renders no message. This happens on an out-of-render-cycle `applyScroll` (a late `onImageLoaded` or `ResizeObserver`), and when `showLoadOlder` short-circuits on `loadOlder` false and leaves the render unsubscribed from `isLoaded`. Move `resetCount` into `this.state`. Reading it in the effect's dependency array now subscribes the render to it (OWL subscribes the `useState` proxy's render callback on every read, wherever it happens), so a `reset()` bump re-renders and re-runs the mirror to re-sync `mountedAndLoaded` with `isLoaded`. Bump it only when `isLoaded`: `applyScroll` resets on every patch while `!isLoaded`, so an unconditional bump would spin the render loop during loading; the guard re-arms only in the case that heals. https://runbot.odoo.com/odoo/error/940032 Forward-Port-Of: odoo/odoo#273651
A recent change in Cloudflare impacted the way turnstile callbacks functioned, causing a disruption. To ensure turnstile functionality continues to work correctly, the team reverted to the previous implementation which avoids reliance on external widget details. This resolves a technical issue impacting website performance.
Original PR description
Callbacks were changed to use a single shared callback instead of a bunch of callbacks that captured a specific container. Cloudlfare since introduced a change that breaks this change by not making "this" available inside callbacks. We thus go back to the previous implementation that did not rely on implementation details of the external widget. related: 5aa5cf62a9d3f2b0c862b0aab337b22367843fa6 Forward-Port-Of: odoo/odoo#273538 Forward-Port-Of: odoo/odoo#273336
This update fixes a discrepancy in how the system counts expenses linked to sales orders. Previously, only expenses tied to specific order lines were counted, leading to inaccurate numbers displayed on the sales order form. Now, all expenses associated with a sales order are correctly counted, ensuring the smart button displays the accurate total expense count.
Original PR description
**Before this commit** Only expenses that generated a sale order line on an SO would be counted in that SO's count of expenses, introducing confusing behavior with the smart button on the SO form view that would take the user to a list of all expenses that have anything to do with the current SO. **After this commit** We return to the behavior that was present in Odoo 18.1 where all expenses that are associated with a SO show up in that SO's "expense_count", making the number in the smart button consistent with the number of expenses that will be fetched when clicking on it. opw-6309575 Forward-Port-Of: odoo/odoo#272287
This update resolves a technical problem that could have caused errors in the processing of French tax reporting (F10) for certain Odoo users. The fix prevents a faulty SQL query from being generated when a specific date calculation resulted in no data, ensuring accurate tax reporting functionality.
Original PR description
Fixes _force_update_l10n_fr_f10_moves(). It would create a SQL query that compares a date to a bool when _pdp_get_flow_10_start_date() returned None. Forward-Port-Of: odoo/odoo#273006