Wednesday, April 22, 2026
31 changes · saas-19.3
Enhancements to existing features
Discuss messages can now display and edit code blocks more naturally. This improves the experience for users sharing technical snippets by keeping formatting clear and showing code in a readable way when messages are viewed.
Original PR description
splitting the code block plugin from the font plugin, and make it available in mail composer. use the syntax highlighting embedded component to render code blocks in readonly mode in the message bodies. task-5262721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system now checks for missed notifications as soon as a user connects to the messaging socket, instead of relying on a separate page-watcher process. This simplifies the flow and makes the warning about lost updates more dependable when a connection is interrupted.
Original PR description
The outdated page watcher service tries to guess if the bus table was GCed during disconnect to warn the user about missed notifications. To do so, it has a complex logic, deeply coupled to the websocket lifecycle events and requires an RPC request to check if the server still knows about the last notification received. It would be much simpler to check this when first subscribing to the socket. This commit implement this solution. part of task-6144132
The 0% S tax for Belgium now uses the correct exemption code and exemption reason. This helps ensure invoices and tax reports reflect the right legal classification and reduces the risk of reporting errors.
Original PR description
The tax 0% S had a wrong tax exemption code and tax exemption reason. This commit corrects it. Task-6127195 Forward-Port-Of: odoo/odoo#259639
After synchronizing databases with Odoo.com, the system now tries to create a database-specific API key instead of relying on one global key. This reduces unnecessary validation calls and can speed up database access by around half a second in some cases.
Original PR description
Before this commit, databases fetched from Odoo's SaaS were contacted using the global API key, which is more costly than using a key local to each database. Avoiding the call from the server to Odoo to check the foreign API key can spare about 500ms on each database where this key is not in the LRU. With this commit, after the synchronization with Odoo.com, we try to generate an API key on each database that doesn't have one yet. To do so, it relies on the API introduced by odoo/odoo#246118. Forward-Port-Of: odoo/enterprise#114406 Forward-Port-Of: odoo/enterprise#106372
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 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 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 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
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 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
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 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 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 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