Daily updates from Odoo
Wednesday, April 22, 2026
40 changes · saas-19.3
Resolved issues and error corrections
This update corrects how Premium Pay is calculated in Belgian payroll so payments stay within the proper limits. It helps prevent incorrect pay amounts and improves payroll accuracy for affected employees.
Original PR description
add premium pay caps Task: 6119891
This change restores the expected format for translated HTML content when it is exported. It prevents the export file from becoming invalid in cases where quoted text appears in HTML translations, helping ensure translations can be shared and imported correctly.
Original PR description
Refactor odoo/odoo#246357 made get_translation_dictionary return Markup-wrapped keys and values for translate=True HTML fields. When polib.POEntry is given Markup, double quotes in .po output are not escaped as expected, which can produce invalid PO files. Keep dict[str, dict[str, str]] for those entries so export stays correct without special-casing each writer path. for solving problem <img width="812" height="254" alt="image" src="https://github.com/user-attachments/assets/6901865a-4dd9-49a7-ba1c-f90dbb346976" /> 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 change restores the expected workflow when submitting the French tax filing package. It ensures the normal processing step still runs, preventing a test failure and keeping the report status updated correctly.
Original PR description
When merging the sending of the liasse fiscale, super() wasn't called anymore in action_submit and led to an assertError in test_state_progression() test
```
FAIL: Subtest TestAccountReturn.test_state_progression (return_type=account.return.type(186,))
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/tests/test_account_returns.py", line 2087, in test_state_progression
self.assertEqual(account_return.state, 'paid')
AssertionError: False != 'paid'
```
runbot-275061This update makes domain validation catch invalid data types more reliably, such as entering text where a number is expected. It helps prevent incorrect filters from passing validation and reduces errors later when the system builds database queries.
Original PR description
`Domain([('num_field', '=', 'dfd')]).validate(model)` should raise an exception because 'dfd' is not a valid number. Currently, the optimization does not check the data types for all operators, but these are checked during SQL generation. Let's generate the SQL to validate the domain.
task-6132976
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#260102This change fixes how translated HTML content is prepared for export, so translation files are generated in a valid format again. It prevents broken quotation handling in exported .po files, which helps avoid issues when translating and re-importing content.
Original PR description
Refactor odoo/odoo#246357 made ``get_translation_dictionary`` return Markup-wrapped keys and values for `field.translate is True` HTML fields. When polib.POEntry is given Markup, double quotes in .po output are not escaped as expected, which can produce invalid PO files. Keep ``dict[str, dict[str, str]]`` for those entries so export stays correct without special-casing each writer path. Also revert the support for ``field.get_trans_terms()`` when ``field.translate is True``. for solving problem <img width="812" height="254" alt="image" src="https://github.com/user-attachments/assets/6901865a-4dd9-49a7-ba1c-f90dbb346976" /> 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 corrects how certain related fields are initialized so they continue to work properly when a selection list is involved. It helps prevent configuration errors and keeps dependent features behaving as expected.
Original PR description
In PR https://github.com/odoo/odoo/pull/255091, the selection field has more strict validation when a field is defined with both `selection` and `related`. This commit fixes the manual related selection which uses `{'selection': '[]', 'related': 'xx.xx', ...}` to initialize the selection field object.
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-prThis change makes an age-based payroll warning test use a fixed point in time instead of the current date. It prevents random failures in nightly builds and keeps test results consistent over time.
Original PR description
The test was failing intermittently in nightly builds that run at a date in the next year (e.g.: 2027-04-20). The issue was that the student's age is calculated at runtime using : - When the student is age 19 (2026): min wage = 2057.87 < 2100 → PASS - When the student is age 20 (2027): min wage = 2136.84 > 2100 → FAIL task-6144986
This update corrects several internal query counters used by automated performance tests, especially in mail-related areas. It helps the test suite reflect the real system behavior more accurately, improving confidence in performance reporting and preventing misleading results.
Original PR description
Update various (main mail-related) counters according to runbot state. 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 brings several mail-related counters in line with the current system behavior, improving the accuracy of performance tracking. It also prevents an error when the system tries to render a field that does not exist, replacing an unexpected crash with a clearer handled error.
Original PR description
> > Update various (main mail-related) counters according to runbot state.
This change fixes unstable automated tests around the field service geolocation feature. It reduces unnecessary test work so the test suite runs more reliably without affecting day-to-day user behavior.
Original PR description
This commit fixes the undeterministic test failures for the geolocation service. We reduce the [workload](https://github.com/odoo/enterprise/blob/master/planning_field_service/static/src/services/field_service_geolocation_service.js#L26) of the `startWatch` method by mocking the `has_group` calls.
This change fixes an error that could appear when users create accrual entries from the Billed Not Received view after changing the date filter. The system now handles the date correctly, so users can complete the action without interruption.
Original PR description
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the…
**Steps to reproduce:** - Install the `accountant` and `purchase` modules. - Create and confirm a Purchase Order (with 1 quantity). - Create a vendor bill using `auto-complete` from the PO, set the quantity to 1, and `confirm` it. - Navigate to Accounting > Review > `Billed Not Received`. - Change the `date` from the top left. - Select a record and click `Create Accrual Entries`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.date' and 'str'` **Root cause:** At [1], the `accrual_entry_date` is set in the context as a `string`. Later, at [2], this value is retrieved from the context and used directly in a comparison with `ivl.date`, which is a `datetime.date`. **Fix:** This commit converts `accrual_entry_date` to a `datetime.date` object at [2], allowing users to create accrual entries without errors. [1]: https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76 [2]: https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188 opw-6110907 Forward-Port-Of: odoo/odoo#260526 Forward-Port-Of: odoo/odoo#259047
This update corrects the text color in message input areas so it remains readable when the field is selected. It fixes a display issue seen in Helpdesk, website tickets, and product reviews when a dark site theme is used.
Original PR description
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to reproduce - Install the Helpdesk app - Go to Website > Help - Submit a ticket (the ticket's information is not important) - Click the ticket link shown when the ticket is submitted - Start writing a message in the Communication History. # The problem As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable. Note : the same problem is present for product reviews in the eCommerce application. These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103 # Cause The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131 In our case, it sets `color` to #FFF (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101 But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149 The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6 Because `.o-discuss-text-body` is overriden by `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied. # Proposed solution Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused opw-6063961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258142
This change restores the previous way child contact names are shown, so customer and supplier contact information appears as expected again. It helps avoid confusion on invoices and partner records where a subordinate contact was displayed incorrectly.
Original PR description
This reverts commit 0ef4c1d06fdf999ad5cdad696069aec8f2f943c5. opw-5900567 Forward-Port-Of: odoo/odoo#260186 Forward-Port-Of: odoo/odoo#260065
The general ledger export now works correctly even when draft journal entries are included. This prevents an error that previously blocked users from generating the report in the Peruvian localization.
Original PR description
**Steps to reproduce:** - Install the `l10n_pe_reports_lib` module and switch to a `PE company`. - Create a draft invoice. - Navigate to Reporting > General Ledger. - Click the gear icon and select `Inventory and Balance`. **Error:** AttributeError: 'NoneType' object has no attribute 'replace' **Root Cause:** For draft entries, `move_name` is `None`, and calling `.replace()` on it causes an error at [1]. **Fix:** This commit prevents errors and ensures users can export the general ledger even when draft entries are included. [1]: https://github.com/odoo/enterprise/blob/5babcb5cb951e0e7beebdbef0781a20a7a19c319/l10n_pe_reports_lib/models/account_general_ledger.py#L168 opw-6104117 Forward-Port-Of: odoo/enterprise#114550 Forward-Port-Of: odoo/enterprise#113405
This change updates the Windows packaging setup so optional dependencies are included when needed. It helps avoid installation issues and makes Windows builds more reliable for users and deployers.
Original PR description
Forward-Port-Of: odoo/odoo#258320 Forward-Port-Of: odoo/odoo#258128
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114373 Forward-Port-Of: odoo/enterprise#106998
Original PR description
There were some translation overrides for `fr_BE` and `fr_CA` that were incorrect or unnecessary. We are deleting these files so they use the correct translations in `fr` instead. In the `nl_BE` translation, we are fixing a menu item so it is shorter, but still correct. task-5921458 Forward-Port-Of: odoo/enterprise#114373 Forward-Port-Of: odoo/enterprise#106998
This change updates an internal compatibility check for the lxml library so Odoo correctly recognizes when an older workaround is no longer needed. It helps keep the system aligned with the latest lxml release behavior, reducing the risk of unnecessary patches being applied.
Original PR description
Whitelisting of ARIA attributes is now part of the milestone for LXML 6.1. This commit updates monkey patch's obsolescence detection accordingly. Forward-Port-Of: odoo/odoo#258910
Imported XML files now stay properly attached to the related bill instead of being detached during import. This prevents access errors when users later open documents created from email or manual imports, including cases used by local e-invoicing flows.
Original PR description
When importing files (manually or from email alias), we unattach the xml files, it can lead to access error in some flows like with l10n_mx_edi Steps to reproduce the flow that triggered the bug: - Install l10n_mx_edi and select MX company - Create an email alias for purchase journal - Receive email with xml file - Create a user with 'group_user' role, 'Administrator' accounting access rights - Login with this user and open the created bill -> Access Error This is because we unattach xml attachmentss when importing them, by setting `res_id` to 0 and `res_model` to False. The mx edi flow adds the `l10n_mx_edi_cfdi_attachment_id` via `_get_mail_thread_data_attachments` which lead to an access error during the `fetch` method opw-5953578 Forward-Port-Of: odoo/odoo#260127 Forward-Port-Of: odoo/odoo#259095
This change preserves the visual link styling in shared frozen spreadsheets while preventing those links from being clickable. It helps dashboards keep their intended layout and appearance without exposing internal navigation behavior.
Original PR description
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that…
Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content. By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout. To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click). Task-6063301 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260250 Forward-Port-Of: odoo/odoo#256357
Images added to the document layout now remain visible in printed PDFs even when their width is set as a percentage. This fixes an issue where company details could lose the image in the final printout, improving the reliability of document branding.
Original PR description
Problem: When adding an image in the `company_details` field via **Settings > Configure your document layout** and resizing it to a percentage width (e.g. 50%), the image is not visible when printed. Cause: Since fa55c2d1, `wkhtmltopdf` fails to correctly calculate percentage-based image widths because none of the ancestor elements have an explicit width defined. Solution: Force the wrapping table to `width: 100%`, giving `wkhtmltopdf` a concrete width to resolve percentage values against. Steps to reproduce: - Go to **Settings > Configure your document layout** - In the address field, add an image via `/media` - Resize the image to 50% - Print the document - Image is missing in the PDF output opw-6102568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259077
This fix restores the cost of goods sold entry when a kit is delivered with some components removed. It also improves the accounting amount by charging only for the components that were actually delivered, which makes the invoice records more accurate.
Original PR description
Steps to reproduce: - Create a kit with 3 or more components - Create a sales order with the kit and confirm it - Remove at least one of the kit's components from the delivery and validate it - Create the invoice from the sales order and confirm the invoice - Check the journal entries included in the invoice form Current behavior: - There is no COGS entry Expected behavior: - There should be a COGS entry Context: In versions <19, you will get a COGS entry that amounts to the total cost of the kit despite deleting a component from the delivery. With our current code in versions 19+, we can actually improve upon this by only counting the remaining components' costs for the COGS entry's amount. opw-6082565 Forward-Port-Of: odoo/odoo#259875 Forward-Port-Of: odoo/odoo#258982
This change fixes an unreliable automated test in the HTML editor, making test results more consistent. It helps ensure future builds are less likely to fail randomly, improving confidence in the editor’s quality without changing the user experience.
Original PR description
My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones. runbot-242333 Forward-Port-Of: odoo/odoo#259978 Forward-Port-Of: odoo/odoo#259544
This change prevents a crash that could happen when a user tried to confirm a scrap operation after first dismissing the insufficient-quantity warning. It keeps the process stable and avoids interrupting inventory work with an error message.
Original PR description
**Version:** --------- - saas-19.2+ **Steps to reproduce:** ------------------------ * Install the *Inventory (stock)* module. * Create a *storable product* with tracking enabled. * Update the…
**Version:** --------- - saas-19.2+ **Steps to reproduce:** ------------------------ * Install the *Inventory (stock)* module. * Create a *storable product* with tracking enabled. * Update the on-hand quantity to *5 units*. * Navigate to *Inventory > Operations > Scrap* and create a new scrap record. * Select the created product and set a quantity *greater than the available on-hand quantity (e.g. 6)*. * Click on *Confirm*. * An *insufficient quantity* wizard opens. * Click on *Discard*. * Then click again on *Confirm* in the wizard. **Issue:** --------- * A traceback occurs with the following error: `ValueError: Expected singleton: stock.move()` **Cause:** ---------- * When clicking *Confirm*, button the insufficient quantity wizard is opened with a `scrap_move_id`. https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2747 https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2742 * Clicking *Discard* button triggers `action_cancel`, which unlinks the associated `scrap_move_id`. https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L48-L49 * However, the wizard remains open, and clicking *Confirm* again triggers `action_done`, which calls: https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L46 * At this point, `scrap_move_id` no longer exists, leading to the singleton error. - Before saas-19.2 This behavior was previously handled in: https://github.com/odoo/odoo/commit/c361c3778ef4755b4760039a4fd8f9ed88294b64 Later in this commit https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba the condition was removed during refactoring, causing the scrap move is to be unlinked in all flows. **Fix:** ------ * Add a context key to ensure that the scrap move is only unlinked during the `action_scrap` flow, preventing access to a deleted `scrap_move_id`. --- opw-6128188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260121
The call menu now includes the Picture-in-Picture option, making it faster to keep a call visible while moving to another conversation. The menu also fixes the appearance of Fullscreen and Picture-in-Picture so these options display normally instead of looking faded.
Original PR description
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of…
Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call. Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster. This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature. Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown. Before / After <img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" /> Forward-Port-Of: odoo/odoo#260512 Forward-Port-Of: odoo/odoo#259866
This change makes an automated test for the editor’s power buttons more reliable on slower systems. It avoids false failures caused by timing differences, so test results are more stable without changing the product behavior.
Original PR description
Waiting for a full animation frame is too dangerous. In the general case, an animation frame happens every 16ms, in which case the power buttons haven't been updated yet since they have a debouncing timeout of 30ms. However, when the runbot is slow, more than 30ms may very well have elapsed between two animation frames. When that is the case, the power buttons are displayed and the test fails. This commit changes the forced awaiting of an animation frame to a waiting pased on the time passed. In the general case, an animation frame will have happened in 20ms, so the test will still catch a regression. When the runbot is slow however, more time might have passed, but not necessarily an animation frame, so the power buttons should still be invisible, making this test more reliable. runbot-242466 Forward-Port-Of: odoo/odoo#259854 Forward-Port-Of: odoo/odoo#259654
When a subcontractor resupply picking is created through a stock-triggered route, it now correctly displays the originating purchase order. This makes it easier for users to trace the supply flow and understand which order the picking belongs to.
Original PR description
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route,…
### Steps to reproduce: - In the settings enable: Subcontracting, Multi-Step Routes - Inventory > Configuration > Warehouse Management > Routes - Edit the 'Resupply Subcontractor on Order' route, rules supply method to: Take from stock, if unavailable, trigger another rule (mtso) - Create a subcontracted bom For a product P with a component COMP - Create and confirm a PO for 1 unit of P with your subcontractor - Use the Resupply smart button to access the resupply picking #### > The resupply picking does not refer to the source PO ### Cause of the issue: The link is currently computed based on `move_dest_ids` which are only set for mto moves. However, moves created from mtso rules are `make_to_stock`. ### Fix: Since 19.0 2713876dbc70d3984e584a9037a2206dcda4e84a, we can rely on references to rebuild the link between the resupply picking and the source PO even in mtso. Note that this will also add the source PO link to each other picking of the reference. opw-6079680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256689
When a vendor bill is created using Auto-complete from a previous bill, the Intrastat transaction information is now preserved on the new bill lines. This prevents missing customs/trade reporting data and helps ensure the bill is completed correctly from the start.
Original PR description
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to…
Currently, Intrastat transaction values are not set when creating a vendor bill using the `Auto-complete` feature based on a previously created vendor bill for an `EU customer`. **Steps to reproduce:** - Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`. - Create a vendor bill for an `EU partner`, add a product, and set an `Intrastat` (enable from the optional column if needed). - `Confirm` the bill and note its number. - Create a new vendor bill for the `same partner`. - Use the `Auto-complete` feature by selecting the previous bill. - Check the invoice lines. **Observation:** The `Intrastat` is missing from the generated invoice lines. **Root Cause:** - On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] copies invoice lines using `copy_data()`. - However, in `account_intrastat`, `copy_data()` at [2] removes `intrastat_transaction_id`. **Fix:** This commit ensures that `Intrastat` is properly set when creating a vendor bill using the auto-complete feature based on a previously created vendor bill for an EU customer. [1]: https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820 [2]: https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83 opw-5936869 Forward-Port-Of: odoo/enterprise#114520 Forward-Port-Of: odoo/enterprise#112857
This change keeps the message text readable when a reply box is active in Discuss, Helpdesk, and product reviews. It prevents the text color from turning white on a white background when users click into the message field, improving usability in dark website themes.
Original PR description
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to…
# Setup Edit the theme of the website : in the Light & Dark section, set the first color to black. The main background color of the website should be black and the text should be in white. # How to reproduce - Install the Helpdesk app - Go to Website > Help - Submit a ticket (the ticket's information is not important) - Click the ticket link shown when the ticket is submitted - Start writing a message in the Communication History. # The problem As long as the text bubble is focused, the text is white even though the bubble is also white, making the text unreadable. Note : the same problem is present for product reviews in the eCommerce application. These text bubbles seems to be intended to stay white even in a dark main background color, so the text should be black : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/composer.scss#L103 # Cause The textarea (text bubble) has a the `.form-control` css class coming from bootstrap that applies `color: var(--bs-body-color)` : https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2115-L2131 In our case, it sets `color` to #FFF (I'm not 100% sure where this value is coming from since I did not find any instance where --bs-body-color or --body-color are ever set to that value). Anywyay, this value is overidden by `.o-discuss-text-body`: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/mail/static/src/core/common/core.scss#L99-L101 But the value is overriden again when the textarea is focused by the `form-control:focus` css class that sets back the color to #FFF: https://github.com/odoo/odoo/blob/6b21829159d3d16a0a0060e30814f9d969b44418/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L2143-L2149 The issue was caused by this commit that changed the class used to define the color for the discuss messages : https://github.com/odoo/odoo/commit/3557de4232ebc307c8861379f6573d7b36cd8db6 Because `.o-discuss-text-body` is overriden by `form-control:focus` while `.text-body` is not. This is most probably due to the order in which the stylesheets are applied. # Proposed solution Add `, .o-discuss-text-body:focus` to make sure the rule is also applied when the text bubble is focused opw-6063961
This fix ensures return documents show the correct year in their date range labels. It prevents cases where a January 2023 date was incorrectly displayed as January 2022, which could cause confusion when reviewing reports or records.
Original PR description
Steps to reproduce: - Create a return from Jan 2023 to April 2023 -> the dates displayed in the name will be Jan 2022 - Apr 2023 The display is incorrect because we used the wrong date format, and therefore switch from using YYYY to yyyy as the first one is the ISO standard year and the second the calendar year. They might differ on the result here because 01 Jan 2023 falls on a Sunday, but ISO week starts on Monday, so it took the previous year (2022) Forward-Port-Of: odoo/enterprise#114428
This fix ensures that when an IoT-connected printer is refreshed, its subtype is not overwritten if someone has already changed it in the database. As a result, business users keep their chosen device settings instead of seeing them reset after an IoT box restart.
Original PR description
Steps to reproduce: 1. Connect a printer to the IoT box and pair with a DB 2. Manually change the subtype of the printer in the DB 3. Restart the IoT box so it resends its devices. **Expected behaviour**: Subtype remains as the user-set value. **Actual behaviour**: Subtype is reset to the original value. To fix this issue, we simply remove any check for subtype in the device updating condition. Now, a device will only reset if its type changes. Forward-Port-Of: odoo/enterprise#114416
This fix ensures that calendar leave entries created without a specific resource are no longer ignored. Instead, they are applied to all resources as intended, helping avoid scheduling mistakes in renting plans.
Original PR description
Before this commit, any `Resource Calendar Leave` created with no `Resource` related to it was ignored, while it should have been applied to all `Resources`. This commit makes sure that any `Resource Calendar Leave` with no related `Resource` is applied to all `Resources` as intended. task-5798796 Forward-Port-Of: odoo/enterprise#114274 Forward-Port-Of: odoo/enterprise#112575
This update corrects how one payroll field is calculated in the Luxembourg payroll module. It helps ensure employee payslips are computed with the right logic, reducing the risk of incorrect payroll results.
Original PR description
Forward-Port-Of: odoo/enterprise#107635
When using Documents with a large selection, the Share action now correctly applies permission changes to every selected file, not just those on the current page. This prevents inconsistencies when working with more than one page of documents.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload more than 80+ files (max page size is 80) - Use the checkbox to select all files on the page - Click the 'Select All' button in the control panel to select allfiles - Use Share action button - Pop-up only takes the current page into account - Rights modifications will not be applied on remaining records **Issue:** `onShare()` only takes current records into account even if the full selection was applied. **Fix:** Fetch all document ids (if needed) before opening the dialog. opw-5957777 Forward-Port-Of: odoo/enterprise#110299
This change fixes an error that could block users from duplicating Helpdesk tickets when they do not have stock permissions. It makes ticket copying work smoothly for more users without requiring extra access rights, reducing interruptions in daily support work.
Original PR description
Steps to reproduce: - Install helpdesk_sale_timesheet. - Create a Helpdesk Ticket and set its sale_line_id. - Log in as a user without stock.group_stock_user access. - Try to duplicate the ticket. Issue: Duplicating a ticket raises an AccessError because the user lacks stock rights required when copying the product_id. Fix: Set `product_id` to False during duplication for non-stock users. Reference: https://github.com/odoo/enterprise/pull/9100 task-5356318 Forward-Port-Of: odoo/enterprise#114266 Forward-Port-Of: odoo/enterprise#101338
This update prevents an error that could occur when the Purchase app is installed after Accounting on an existing system. It makes the Purchase screen adapt safely to older versions of the Accounting view, improving upgrade and installation reliability.
Original PR description
c5ac4867fb708c56aa74e38508347660f1875dd3 added back the computed fields `invoice_vendor_bill_id` and `purchase_vendor_bill_id` on `account.move` in stable. The issue is that the view on purchase expects the view on account to have `invoice_vendor_bill_id` in it. But if a user already had `account` installed before the commit, then install `purchase` after, the purchase view will raise an exception as it expects `invoice_vendor_bill_id` in the view of account. The fix here is to not reference `invoice_vendor_bill_id` in the purchase view and compute its visibility with a non-stored computed field. Forward-Port-Of: odoo/odoo#260151
This fix ensures loyalty points are only rounded like money when the program is actually money-based. As a result, point-based rewards will no longer be reduced to zero in currencies with coarse rounding rules, so customers can claim their rewards as expected.
Original PR description
`_get_real_points_for_coupon` was unconditionally rounding points using `coupon.currency_id.round()`, which uses the currency's rounding factor as a precision unit. For point-based programs (e.g. 1 point per order), a currency with a large rounding factor (e.g. 10) would round 1 point down to 0, making all rewards unclaimable. Currency rounding is only semantically correct when points represent monetary amounts, which is the case when `reward_point_mode == 'money'` (gift_card, ewallet, and money-mode loyalty programs). For all other programs, points are dimensionless and should not be subject to currency precision rules. opw-6111622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259660
This update fixes a small wording mistake in website and mass mailing text snippets, changing “am” to “pm” where needed. It helps ensure opening hours and related customer-facing content are accurate and less confusing.
Original PR description
am to pm Forward-Port-Of: odoo/odoo#260577
This change filters out characters that are not allowed in Swiss QR bills before the QR code is generated. It helps prevent bank rejections caused by unsupported Unicode characters, improving payment reliability.
Original PR description
**Description of the issue/feature this PR addresses:** QR code is rejected by the bank, when it contains an invalid character `U+202F`. **Current behavior before PR:** Unauthorized Unicode characters are encoded in the QR-Bill, and it is rejected on the receiving part. **Desired behavior after PR is merged:** Any Unicode codepoint which is not in the subset of 324 allowed codepoints has to be filtered out. > spec of QR-bill allows only a subset of characters, a precise list of 324 Unicode codepoints (section 4.1.1, page 30 of the Swiss Implementation Guidelines for the QR-bill) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259279 Forward-Port-Of: odoo/odoo#254980
This update fixes a typo and improves the visual styling in the VoIP dashboard used with spreadsheets. It does not change how the feature works, but it helps make the interface clearer and more polished for users.
Original PR description
task-6132220 Forward-Port-Of: odoo/enterprise#114324
This update prevents a crash when users open the “Blocked by” tab and add a dependency from a mobile device in Project. It ensures the interface loads correctly, improving reliability for teams managing tasks on the go.
Original PR description
Steps to reproduce: - Install Project - Create a project and a task and enable task dependencies - In mobile view, go to the "Blocked by" tab and click "Add" Issue: A traceback occurs in the mobile view. Cause: In this pr https://github.com/odoo/odoo/pull/230738 parent_id was moved inside anchor element. Fix: Update the XPath to correctly replace the element containing parent_id. task-6009997 Forward-Port-Of: odoo/odoo#252804