Friday, August 29, 2025
42 changes
14 changes
Resolved issues and error corrections
This fixes a visual issue where elements meant to have rounded corners only on one side could also change corners that should have stayed unchanged. It helps notifications, card layouts, and similar website elements display with the intended shape again.
Original PR description
Commit [1] (which was patched by multiple other commits since then already) needs yet another patch: the `rounded-start`, `rounded-end`, `rounded-top`, `rounded-bottom` and all their size variants…
Commit [1] (which was patched by multiple other commits since then already) needs yet another patch: the `rounded-start`, `rounded-end`, `rounded-top`, `rounded-bottom` and all their size variants were not working anymore: the direction they were not supposed to control were forced to the default border-radius value. E.g. the class rounded-end-4 was forcing `border-radius: default big big default` instead of just forcing "big" on the top-right and bottom-right.
This could be fixed while keeping the improvement added by [1] (which is allowing the value to use CSS variable, allowing to auto-adapt children with the right border-radius when needed) but it is fact better/simpler to just revert the improvement just for those classes (while keeping it for the base `rounded` and `rounded-{SIZE}` classes). Indeed, this is not necessary at the moment. They can be used in layouts but we do not allow edition of their radius via the builder: when we do, we normally should always prefer to give the user full control over the 4 directions, by switching to the `rounded` or a `rounded-{SIZE}` class.
This bug could be visible in different standard ways:
- Notifications
- Cards Grid snippet
- ...
Note: this also actually revealed that [1] re-introduced the 4 and 5 sizes which were actually disabled by the /web/.../utilities_custom.scss file. This commit re-disable them for those partial classes... but they probably should be restored to respect Bootstrap's default. The 1-2-3 sizes are also not using CSS variable of Bootstrap. This commit adds a FIXME comment about this.
[1]: https://github.com/odoo/odoo/commit/d0daf3990079477ef7552d769b944b55d9be4366
Related to task-3358501This fixes an internal mistake in how user group names are searched. It helps ensure group lookup results are accurate and avoids confusion when administrators search for access groups.
Original PR description
Followup of #223210 .
The website link editing test has been updated to work with the new website builder layout and turned back on. This helps ensure link editing continues to work reliably, with links now defaulting to HTTPS when no protocol is entered.
Original PR description
The link_tools tour was previously broken due to DOM structure changes introduced by the new website builder and was consequently disabled. This commit updates the tour steps to align with the new DOM and re-enables the associated test. Note: Previously, HTTP was the default protocol. Now, HTTPS is used as the default if none is specified.
This fix makes an automated sales timesheet test wait until the needed kanban column is ready before continuing. It reduces random test failures, helping keep releases and updates more dependable without changing user-facing behavior.
Original PR description
In this commit, we fix the undeterministic behavior by adding a step to ensure kanban column is created before continue scenario. runbot-error-id~181916 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#224447
This fix prevents the Point of Sale from accidentally deleting two order lines when reducing an unsaved line with the barcode box flow. Cashiers can correct quantities more reliably without losing an extra item from the current order.
Original PR description
- Fix issue in `handleDecreaseUnsavedLine` which was leading to removing two orderlines instead of one in the current order. This issue appeared since this commit (8e964000474125ca2db4ee4e5883be8424d9fca1). Since we already set the line qty to 0 (or remove it) inside `updateSelectedOrderline` after calling `_showDecreaseQuantityPopup`, we don't need to call `removeOrderLine` inside `handleDecreaseUnsavedLine`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224230
This fix ensures the Turkish Nilvera e-dispatch integration sends the exact true or false values required by Nilvera instead of translated text. This prevents potential dispatch submission issues caused by localized wording in exported data.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
Fixed an issue that could block importing user groups whose names contain a slash when no privilege identifier is set. This prevents false “multiple matches” errors and makes group data imports more reliable.
Original PR description
If a group does not have privilege id and contains a /, the group search can return a list of group instead of the group itself. The import display an error message "Found multiple matches for..." opw-4885648
This fix prevents errors when SEO tools receive missing page descriptions or when Google suggestion requests fail. Website editors get a more reliable SEO preview experience instead of unexpected crashes or broken responses.
Original PR description
Ensure the Google suggest fallback always returns a JSON list, even on IOError, instead of raising a serialization traceback. JS (SEOPreview): guard against undefined/empty descriptions with optional chaining and default empty string to avoid runtime errors. opw-4963552 Forward-Port-Of: odoo/odoo#224637 Forward-Port-Of: odoo/odoo#224424
Changing a customer's VAT number on Indian invoices no longer causes the fiscal position to be recalculated unexpectedly. This keeps invoice tax settings stable and aligned with standard behavior, reducing the risk of unintended tax changes after partner details are updated.
Original PR description
The field fiscal_position_id in l10n_in was dependent on l10n_in_gst_treatment, which itself depended on partner.vat, partner.country_id, and partner.l10n_in_gst_treatment. As a result, any change to the partner’s VAT triggered a recomputation of fiscal_position_id. This contradicts the generic behavior, since VAT changes should not affect fiscal position. This fix removes the unnecessary dependency chain. reference - https://github.com/odoo/odoo/pull/224511 Forward-Port-Of: odoo/odoo#224639
Payroll advice reports in Indian payroll now use the selected payslips to determine the period instead of relying on the current date. This ensures reports for past payroll runs show the correct period and avoids missing or inaccurate payroll advice details.
Original PR description
Generating a payroll advice would use the current date in order to find other payslips that are for the current period and use this to fill in the period on the advice. However, if you do this for a past payslip, it will either not find any or get the incorrect period. Changed the behavior to use the actual payslips and get the period from those payslips to fill in the period on the report. opw-4582990 Forward-Port-Of: odoo/enterprise#92806 Forward-Port-Of: odoo/enterprise#81625
The VoIP CRM app now includes needed permission information when the user session starts. This avoids extra background requests during startup, helping the web client load more efficiently without changing user workflows.
Original PR description
Since the VoIP app use some groups at startup[1], it's made sense to adds it inside the session_info bundle to avoid RPCs at webclient startup. [1]: https://github.com/odoo/enterprise/commit/9d3a13e9adae3a6b1c44b70a52b2fd74ef9dcc1a#diff-e8144e1aa7d3b4933985de5693d78e8c392bce8f7150ad186a04b8c87c7cd32aR14-R16 Forward-Port-Of: odoo/enterprise#93419
This update preserves the intended visibility rules for the 'Return for Exchange' button in rental stock returns. It helps ensure users only see the action when it is appropriate, reducing confusion and avoiding incorrect return workflows.
Original PR description
Adapt the xpath to make sure the invisible condition on the 'Return for Exchange' button is not overriden. tasks 4748294 & 4778066 Forward-Port-Of: odoo/enterprise#93433 Forward-Port-Of: odoo/enterprise#89090
The Timesheet Leaderboard now opens reliably even when the current employee is excluded from the billing-rate ranking due to a very low billing rate. This prevents an error screen and keeps managers and employees able to view leaderboard information without interruption.
Original PR description
**Issue:** A traceback occurs when clicking the Timesheet Leaderboard widget. **Cause:** The template `timesheet_leaderboard_dialog.xml` assumes that `state.current_employee` is always defined. However, when the current user's employee has a billing rate ≤ 0.5%, they are filtered out from the leaderboard. As a result, `setCurrentEmployeeIndexFromLeaderboard` returns `undefined`, causing the widget to crash. https://github.com/odoo/enterprise/blob/70ed91ba1ebb94cb1919df49a4d95fad26935d03/sale_timesheet_enterprise/static/src/services/timesheet_leaderboard_service.js#L18-L31 **Steps to reproduce:** 1. Set up a company with 4+ employees having billing targets. 2. Ensure the current user's employee has a billing rate ≤ 0.5% (e.g., 0.3 hours logged / 100 hours target). 3. Switch the leaderboard to "Billing Rate" mode. 4. Click the Timesheet Leaderboard widget. opw-4875410 Forward-Port-Of: odoo/enterprise#93339
The Estonian XML tax report now combines both 22% tax report line balances into a single transaction entry during export. This prevents duplicate transaction22 lines and helps ensure submitted tax reports match the expected format.
Original PR description
Before this pr: - There are two transactions22 entries were introduced because we are having two report lines for 22% tax computation, one with '1' tag, which is valid till 31 June 2025, and another one with '1_2' tag, which is valid from 1 July 2025. After this pr: - The balance computation during export to XML is now adding the balance of both line '1' and '1_2' into line '1' only. - So now we do not need an extra transactions22 entry in the XML tax report. - We are keeping both report lines for now, but the XML report will have only one entry with the total sum of balances in both report lines Related PR: https://github.com/odoo/enterprise/pull/91364 Forward-Port-Of: odoo/enterprise#93197 Forward-Port-Of: odoo/enterprise#92662
8 changes
Resolved issues and error corrections
Odoo now requires an update path when configuring server actions that update records. This prevents incomplete action setup and helps avoid errors when those automated actions run.
Original PR description
[FIX] base: make update_path required for 'Update Record' server actions If a server action was previously created without an `update path`, the resulting error already fixes with this commit [1]. This commit ensures that the `update_path` field is marked as required when the action type is set to `Update Record`. [1]: https://github.com/odoo/odoo/pull/217723/commits/9d0144f97795d71474bf84bdfd7ed7025fd8a9a2 Forward-Port-Of: odoo/odoo#224797 Forward-Port-Of: odoo/odoo#207928
7 changes
Resolved issues and error corrections
Fixed an issue where previewing a sales order could fail after switching from a subscription quotation template to a regular one. The preview now only shows subscription-specific information when the order is actually a subscription, preventing an error and keeping the sales workflow uninterrupted.
Original PR description
Steps to reproduce: 1. Go to Sales > Configuration > Settings. 2. Set Subscription Template as default Quotation Template e.g.(Yearly Cleaning) 3. Create a new Sales Order 4. Switch the quotation…
13 changes
Resolved issues and error corrections
Opening a Discuss channel now correctly clears its unread status even if that browser missed an earlier notification. This keeps unread indicators consistent across multiple browser sessions and reduces confusion for users managing conversations.
Original PR description
Before this commit, if you opened an unread channel that the server already considered “read,” the channel would remain marked as unread in your browser. This typically happens when one browser instance misses the bus notification that cleared the unread status. Steps to reproduce: 1. Open Discuss as the same user on two browsers (A and B) 2. Send a message to said user 3. Stop bus notifications on browser A 4. Read the message on browser B 5. Re-enable bus notification on browser A 6. Open the channel on browser A -> not being marked as read This happens because the method `_set_last_seen_message` skips sending the notification when the message seen is older than the current `seen_message_id` (previously set by the other browser). This commit fixes the issue by setting the `allow_order` parameter in the rpc call. task-4863058 Forward-Port-Of: odoo/odoo#218623
This fix updates an internal test in the Discuss area to use the proper test model. It helps keep automated checks reliable and prevents unrelated module dependencies from affecting test results.
Original PR description
PR #223438 uses `mail.test.rating` model (which belongs to `test_mail_full` module) as the test model in `test_discuss_full` module. This PR changes the test model to the correct one. runbot-231321 Forward-Port-Of: odoo/odoo#224630
This fix ensures Turkish Nilvera e-Dispatch documents send the exact required true or false values instead of translated text. This helps avoid rejected or invalid submissions caused by language-specific translations changing required system values.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
The website SEO tools now avoid errors when Google suggestion data cannot be loaded or when a page has no description. This helps keep SEO previews and related website editing features stable for users.
Original PR description
Ensure the Google suggest fallback always returns a JSON list, even on IOError, instead of raising a serialization traceback. JS (SEOPreview): guard against undefined/empty descriptions with optional chaining and default empty string to avoid runtime errors. opw-4963552 Forward-Port-Of: odoo/odoo#224637 Forward-Port-Of: odoo/odoo#224424
Fixed an issue where changing the Peppol email address in the configuration wizard did not send the update to the connected service. This helps ensure companies' electronic invoicing contact details stay accurate without manual workarounds.
Original PR description
Due to the config wizard email address field being a related field, and the control flow triggering actual API update only on gets hit when the wizard's email is different from company's email, this control flow never triggered. The email field in peppol config wizard is a related field to companies peppol email, so the API update ran only if the wizard's email differed from the company's email. Since both were always the same by definition, the update never triggered. Depends on https://github.com/odoo/iap-apps/pull/1167 no-task Forward-Port-Of: odoo/odoo#224615
Receipts now show the correct tracking number when a point-of-sale setup uses a preparation display or preparation printer. This helps staff and customers match orders to receipts more reliably and reduces confusion during order preparation.
Original PR description
- Ensure the `tracking_number` is dipslayed on receipts for config which use a preparation dipslay or a preparation printer. task-id: 4922308 community PR: https://github.com/odoo/odoo/pull/222094 Forward-Port-Of: odoo/enterprise#91833
This fix prevents an unnecessary validation warning from appearing when a user changes a server action away from “update with AI.” It reduces confusion during configuration by only applying the AI-specific check when that action type is actually selected.
Original PR description
Bug === When setting a server action "update with AI", and switching to a different type of action, the validation error could be raised because we didn't check the `state`. Task-4989962
The VoIP CRM startup process now includes required user group information upfront. This avoids extra background checks when the web client opens, helping the VoIP app load more efficiently.
Original PR description
Since the VoIP app use some groups at startup[1], it's made sense to adds it inside the session_info bundle to avoid RPCs at webclient startup. [1]: https://github.com/odoo/enterprise/commit/9d3a13e9adae3a6b1c44b70a52b2fd74ef9dcc1a#diff-e8144e1aa7d3b4933985de5693d78e8c392bce8f7150ad186a04b8c87c7cd32aR14-R16
Steps to reproduce: 1. Go to Sales > Configuration > Settings. 2. Set Subscription Template as default Quotation Template e.g.(Yearly Cleaning) 3. Create a new Sales Order 4. Switch the quotation template from a Subscription one to a non-subscription template e.g.(Office Furnitures) 5. Click Preview on the Sales Order. Issue: A traceback is raised: `TypeError: unsupported operand type(s) for +: 'datetime.date' and 'bool'` Cause: In the portal template, the following expression is evaluated without checking if value is falsy or empty: https://github.com/odoo/enterprise/blob/36f419e4604a2adc946f3a6828e69fba7584d2df/sale_subscription/views/sale_subscription_portal_templates.xml#L66 The portal template contained expressions referencing subscription-specific fields (like plan_id.billing_period) without checking whether the sales order was actually a subscription. When the quotation template is non-subscription, these fields may be False, leading to the error. Solution: Guard all subscription-related blocks with condition: `<t t-if="sale_order.is_subscription">` opw-4980869 Forward-Port-Of: odoo/enterprise#92845
Fixed an issue where the Timesheet Leaderboard could crash when the current employee was not shown because their billing rate was very low. Users can now open the widget reliably, even when their own record is filtered out of the billing rate view.
Original PR description
**Issue:** A traceback occurs when clicking the Timesheet Leaderboard widget. **Cause:** The template `timesheet_leaderboard_dialog.xml` assumes that `state.current_employee` is always defined. However, when the current user's employee has a billing rate ≤ 0.5%, they are filtered out from the leaderboard. As a result, `setCurrentEmployeeIndexFromLeaderboard` returns `undefined`, causing the widget to crash. https://github.com/odoo/enterprise/blob/70ed91ba1ebb94cb1919df49a4d95fad26935d03/sale_timesheet_enterprise/static/src/services/timesheet_leaderboard_service.js#L18-L31 **Steps to reproduce:** 1. Set up a company with 4+ employees having billing targets. 2. Ensure the current user's employee has a billing rate ≤ 0.5% (e.g., 0.3 hours logged / 100 hours target). 3. Switch the leaderboard to "Billing Rate" mode. 4. Click the Timesheet Leaderboard widget. opw-4875410 Forward-Port-Of: odoo/enterprise#93339
This fix prevents duplicate records from being created when the stock fleet module is upgraded. It helps keep upgrades reliable and avoids unnecessary duplicate interface entries for inventory delivery operations.
Original PR description
Commit a7f2a2cf9c96 changed the window action to take a specific view xmlid by creating a new `view_ids` entry. As the action is `noupdate=0`, upgrading the module will try to create a new record with the same name. This commit adds the `noupdate` tag around those record to avoid creating new view at update. runbot-230819 Forward-Port-Of: odoo/enterprise#92611
Customers who reorder past sales orders will no longer have appointment-related calendar events added back into their cart. This prevents confusing cart contents and avoids inconsistent behavior when previous appointment orders are reordered.
Original PR description
Steps to reproduce: - Create an appointment that generates a sale order on confirmation. - Confirm the order. - Navigate to `/my/orders` and attempt to reorder the sale order. - Calendar events are added to the cart. Issue: - Calendar events shouldn't be added to the cart - Reordering such lines can lead to inconsistent behavior. Root Cause: - The base `_is_reorder_allowed()` method does not filter out sale order lines that originate from appointments. Solution: - Override `_is_reorder_allowed()` in the `website_sale_appointment` modules. - Filter out lines with `calendar_event_id` set. See also: https://github.com/odoo/odoo/pull/198070 https://github.com/odoo/upgrade/pull/7633 affected version-master task-4472286
A redundant internal marker was removed from the payroll payslip run screen definition. This does not change how the feature works, but makes the code clearer and easier to maintain.
Original PR description
This directive allows to declare a template, so using it inside a template is useless. It doesn't cause any issue, it simply has no effect. This commit removes it for the sake of clarity.
This fixes how Swiss payroll accounting handles negative payslip lines by reversing the accounts when needed. It helps ensure payroll entries are posted to the correct accounts, reducing accounting corrections and improving reliability for Swiss payroll processing.
Original PR description
…r 2050 Invert accounts for negative payslip line Forward-Port-Of: odoo/enterprise#93142 Forward-Port-Of: odoo/enterprise#93074
The VoIP CRM integration now includes needed user permission details when the web session starts. This avoids extra background calls during startup, helping the interface load more efficiently without changing user-facing features.
Original PR description
Since the VoIP app use some groups at startup[1], it's made sense to adds it inside the session_info bundle to avoid RPCs at webclient startup. [1]: https://github.com/odoo/enterprise/commit/9d3a13e9adae3a6b1c44b70a52b2fd74ef9dcc1a#diff-e8144e1aa7d3b4933985de5693d78e8c392bce8f7150ad186a04b8c87c7cd32aR14-R16 Forward-Port-Of: odoo/enterprise#93419
The Point of Sale tax control button now appears only when relevant settings are enabled, including restaurant takeout or delivery scenarios. The tax selection popup also now uses a clear, accurate title, reducing cashier confusion during checkout.
Original PR description
Before this commit: =================== - When only point_of_sale is installed, the tax control button is visible only if `Flexible Tax` is enabled. But with pos_restaurant installed, the button is always visible, even if Flexible Tax is disabled. - Also, the tax selection dialog had an incorrect title: `Please register the voucher number`. After this commit: ================== - In point of sale, the tax control button will be visible if `Flexible Tax` is enabled, and in restaurant mode, the button will be visible if the `Flexible Tax` or `Takeout/Delivery` is enabled. - The tax selection dialog title has been updated to: `Choose the tax you want to apply`. Task: 4937977
The Saudi localization now shows the “THIS IS NOT A LEGAL DOCUMENT” warning only on customer invoices, credit notes, and debit notes when the required QR code is missing. Vendor bills, vendor adjustments, purchase receipts, and sales receipts no longer display this misleading warning, reducing confusion for accounting users.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents required true/false values in Turkish Nilvera e-Dispatch documents from being translated. This helps ensure Nilvera receives the exact values it expects, reducing the risk of rejected or incorrect electronic dispatch submissions.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
This fixes an error that could occur when removing a bank account from a company contact. The change prevents empty duplicate-check results from being treated as real contacts, making contact bank account management more reliable.
Original PR description
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form -…
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form - remove the bank account via bin icon Problem: ========= ARRAY_AGG returns [NULL] when no duplicates found in query: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L73 This causes browse([None]) to create res_partner(None,) recordset: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L88 Which fails when accessing id_ field which will be None: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/web/models/models.py#L1173 Solution: ========= Add FILTER clause to ARRAY_AGG to exclude NULL partner_id values, preventing creation of null records in duplicate_bank_partner_ids. opw-4988134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now requires an update path when users configure a server action to update a record. This prevents incomplete action setups that could otherwise lead to errors when the action runs.
Original PR description
[FIX] base: make update_path required for 'Update Record' server actions If a server action was previously created without an `update path`, the resulting error already fixes with this commit [1]. This commit ensures that the `update_path` field is marked as required when the action type is set to `Update Record`. [1]: https://github.com/odoo/odoo/pull/217723/commits/9d0144f97795d71474bf84bdfd7ed7025fd8a9a2
Users can now enter an ampersand character in filter or domain search values without triggering an error. This prevents crashes when applying custom filters and keeps search behavior consistent for everyday use.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281 Forward-Port-Of: odoo/odoo#224567
This fix restores the ability to create and edit client-type menu actions in Studio without hitting a missing default view error. It removes obsolete special handling that conflicted with a broader default view generation fix, improving reliability for users configuring menus.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224634
This fixes a Point of Sale issue where applying a gift card could create an extra gift card line with a zero amount. Sales orders are now clearer for cashiers and customers, reducing confusion during checkout.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358
Purchase orders now consistently display both the vendor’s product name and the company’s internal product name across all pages. This prevents confusion when reviewing multi-page purchase orders and keeps product identification consistent.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The signing dialog now consistently opens with the automatic signature option selected, whether or not the user already has a saved signature. This avoids confusion and creates a more predictable signing experience for users.
Original PR description
Ensure the signature dialog consistently defaults to the "auto" option, regardless of whether a user has a pre-set signature or not. task-5012307 Forward-Port-Of: odoo/enterprise#92276
This fix removes country-based restrictions that could prevent certain localization reporting modules from installing automatically. It helps ensure that when a new localization is added, its related reporting features are enabled as expected for existing company setups.
Original PR description
Specifiying countries in the manifest will only auto-install the module if at least one company is in one of the countries. This is not wanted as, if someone already has a company with it's reports module, and we add a new localization. We want that new localization to auto-install it's reports module.
The French VAT reporting flow now uses the correct account when creating reimbursement entries. This helps ensure reimbursement accounting is posted accurately, reducing the risk of manual corrections or reporting inconsistencies.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427