Thursday, October 24, 2024
67 changes · master
Enhancements to existing features
This change improves Odoo's core grouping behavior so it can work with related fields written using dot-separated names. It helps internal features and customizations group records more reliably without extra workarounds.
Original PR description
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
A small unused setting was removed from the mail search message panel. This keeps the code simpler and easier to maintain without changing how users interact with the feature.
Original PR description
Purpose of this commit: This commit removes the unused `className` prop from the SearchMessagePanel, as it was never utilized in the component's template.
The Indian localization now shows the tax label as SGST/UTGST in tax groups and GST report headings. This improves compliance clarity for businesses operating in Indian states and union territories by using the more accurate tax terminology.
Original PR description
with this PR: Renamed SGST to SGST/UTGST in Tax Groups and GST Report Heading task - 4231745
Indian GST reports and tax group labels now use SGST/UTGST instead of SGST. This makes the wording more accurate for businesses operating in Union Territories and improves compliance-related reporting clarity.
Original PR description
with this PR: Renamed SGST to SGST/UTGST in Tax Groups and GST Report Heading task - 4231745
Public users now see a close button on the thank-you dialog after signing a document. This makes the signing flow easier to exit and keeps the experience consistent with portal users.
Original PR description
**Before this PR:** - Previously, when portal users signed documents, they received a "Thank You" dialog that included a close button for convenience. However, public users did not have this close button in their "Thank You" dialog, potentially leading to a less intuitive experience. **After this PR:** - To enhance the user experience for public users, a close button has now been added to the "Thank You" dialog. This adjustment aligns the experience of public users with that of portal users, providing a consistent and user-friendly interface. task-4069539 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Resolved issues and error corrections
Time off requests using the Extra Hours type no longer show the duration twice. This avoids confusion for administrators and helps ensure the requested time off amount is displayed correctly.
Original PR description
Steps to reproduce: 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
Odoo removed an obsolete internal field used to describe selection values on model fields. This cleanup reduces legacy complexity in the Base module and supports smoother upgrades with minimal expected business impact.
Original PR description
The title is self-explanatory task-3483966 https://github.com/odoo/upgrade/pull/5091 https://github.com/odoo/upgrade-util/pull/154 https://github.com/odoo/enterprise/pull/72352
Code cleanup and technical improvements
Core remote access endpoints have been separated from the base module into their own RPC module. This is an internal cleanup that makes the platform structure clearer and improves related test stability, with no expected direct change for everyday users.
Miscellaneous changes
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays
Original PR description
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays correctly. Related enterprise: [enterprise/ #72507](https://github.com/odoo/enterprise/pull/72507) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184552
This update makes tax exemption requirements easier to adapt for new electronic invoicing formats. It reduces the need for custom screen changes when additional tax category or exemption rules are introduced, helping future localization updates integrate more smoothly.
Original PR description
Add a computed field `ubl_cii_requires_exemption_reason`, such that its compute function can be modified/extended without having to touch the view. Indeed, new formats are expected to add new `ubl_cii_tax_category_code` and `ubl_cii_tax_exemption_reason_code` and thus to modify the condition on the `required` for the field `ubl_cii_tax_exemption_reason_code`. We want to avoid forcing these new formats to extend the view. In addition, it is hard to add multiple category codes coming from different modules by inheriting the view. no task
This update removes support for an older internal field option that was used when defining certain model fields. It keeps enterprise modules aligned with the main Odoo platform changes and helps prevent inconsistencies in Studio, field service reports, quality worksheets, and exports.
Original PR description
See the community PR. https://github.com/odoo/odoo/pull/133446 https://github.com/odoo/upgrade/pull/5091 https://github.com/odoo/upgrade-util/pull/154
Side panel section titles now use a clearer configuration method while preserving translation support. This is an internal cleanup that makes spreadsheet-related side panels easier to maintain without changing user workflows.
Original PR description
Currently, the title of a `Section` component is a title slot. We are using a slot to translate the title: a props like `title="'My title'"` wouldn't work since this props is javascript expression, while text content inside xml elements are extracted and translated. But since the introduction of the `.translate` modifier, we can use a props! It's much more natural (props vs slot) and explicit (`.translate`) Task: 4226704
A duplicate menu item in the spreadsheet edition area was removed because the same option is already provided by the core spreadsheet component. This keeps the menu configuration simpler and more consistent without changing the intended user experience.
Original PR description
This menu item is also defined in o-spreadsheet but overwritten here with the same thing (except the name, sequence and separator, which have been adapted in o-spreadsheet) Task: 4242125
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b
Original PR description
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However…
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode 1. Set a livechat channel on the website, make sure there is no chatbot on it 2. Enter the livechat channel with the admin 3. Open the website on an incognito window (the chat bubble should be there) 4. Leave the livechat channel with the admin 4. Refresh the incognito window The chat bubble is still there. Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before. opw-4233744 [1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100 [2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86 Forward-Port-Of: odoo/odoo#184644
This fixes issues that arose since 238a41e3 By moving the `_prepare_analytic_account_data` method from sale to sale_project, any call to this method in sale_expense would break as sale_expense doesn't depend on project. Because this method is crucial in the re-invoicing flows we need it in sale. Steps to reproduce: - Install sale_expense without project - Run the sale_expense tests or test the flow manually (create an expense with mileage as a product, add a sale order to reinvoice i
Original PR description
This fixes issues that arose since 238a41e3 By moving the `_prepare_analytic_account_data` method from sale to sale_project, any call to this method in sale_expense would break as sale_expense doesn't depend on project. Because this method is crucial in the re-invoicing flows we need it in sale. Steps to reproduce: - Install sale_expense without project - Run the sale_expense tests or test the flow manually (create an expense with mileage as a product, add a sale order to reinvoice it on and move forward to post the expense sheet) - _prepare_analytic_account_data is missing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184743
Steps to reproduce: - Create an invoice with early payment discount applicable - Register a payment on the invoice (must be without a journal entry associated, done by default) - Open the bank reconciliation widget - Create a statement line with the discounted amount (invoice total - epd amount) - The suggested reconciliation doesn't include a new line with the write-off of the early payment discount Cause of the issue: When registering a payment on the invoice, the invoice payme
Original PR description
Steps to reproduce: - Create an invoice with early payment discount applicable - Register a payment on the invoice (must be without a journal entry associated, done by default) - Open the bank reconciliation widget - Create a statement line with the discounted amount (invoice total - epd amount) - The suggested reconciliation doesn't include a new line with the write-off of the early payment discount Cause of the issue: When registering a payment on the invoice, the invoice payment state switch from 'not_paid' to 'in_payment', which makes this invoice not eligible anymore for early payment discount. task-4237657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182656
-Select order line only when I've just added a product to cart -Ensure that no order line is selected anymore when opening an order (from floorplan, table selector, ticket screen, payment screen) -Adapt tours tests to match this new behavior and limit the use of 'inLeftSide' to avoid going uselessly back and forth to the product list in mobile task-id: 4167563 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
-Select order line only when I've just added a product to cart -Ensure that no order line is selected anymore when opening an order (from floorplan, table selector, ticket screen, payment screen) -Adapt tours tests to match this new behavior and limit the use of 'inLeftSide' to avoid going uselessly back and forth to the product list in mobile task-id: 4167563 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#184087
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , java
Original PR description
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed…
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , javascript will create it at time 00:00 in the UTC timezone, so for users with negative timezone offset (GMT-x), `formatDate` will print the the date as one day behind. It’s the case for American users for instance. Now, we create the date using `DateTime.fromISO(yyyy-mm-dd)`, it will be created at 00:00 in the local time zone (not the UTC timezone anymore), and printing it with `formatDate` will therefore yield the correct value expected by the user. opw-4116982 Forward-Port-Of: odoo/odoo#184779 Forward-Port-Of: odoo/odoo#182933
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in
Original PR description
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes #94390 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184962 Forward-Port-Of: odoo/odoo#94395
Steps: Activate analytic accounting. Create a SO with a service that creates a project. Confirm. The project that has just been created is now set on the SO. Duplicate. Issue: The project is duplicated too. Yet is doesn't correspond to the the one that will be created upon confirmation. Solution: Simply not duplicated the project upon SO duplication. task-4207182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od
Original PR description
Steps: Activate analytic accounting. Create a SO with a service that creates a project. Confirm. The project that has just been created is now set on the SO. Duplicate. Issue: The project is duplicated too. Yet is doesn't correspond to the the one that will be created upon confirmation. Solution: Simply not duplicated the project upon SO duplication. task-4207182 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182978
Issue When loading a template of fields to export, the list of fields is ordered by their technical name and not by their actual position in the list when the template was saved. Cause issue since e3647790830f95de932cb10c39a8232dd97e4221 The `ir.exports.line` are in order of their position in the list at creation in `export_fields`, however `fields_info` sorts the fields by their technical name and may not preserve order https://github.com/odoo/odoo/blob/e3647790830f95de932cb10c39a8232dd9
Original PR description
Issue When loading a template of fields to export, the list of fields is ordered by their technical name and not by their actual position in the list when the template was saved. Cause issue since e3647790830f95de932cb10c39a8232dd97e4221 The `ir.exports.line` are in order of their position in the list at creation in `export_fields`, however `fields_info` sorts the fields by their technical name and may not preserve order https://github.com/odoo/odoo/blob/e3647790830f95de932cb10c39a8232dd97e4221/addons/web/controllers/export.py#L409 opw-4241915 Forward-Port-Of: odoo/odoo#184582
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when us
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be…
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Outlook, when the synchronization of user A starts or resumes, the event will be synchronized without any organizer in user A's Outlook calendar due to a limitation of Microsoft of not accepting creating events for other users (user B) directly. In the meanwhile, in Odoo, the event ownership will be transferred from user B to user A, which is also wrong. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Outlook, it will be correctly synchronized in Outlook as well. This approach will also reduce the possibility of duplicated events in Odoo side (and by transitivity, in Outlook side). task-4261237 Forward-Port-Of: odoo/odoo#184876 Forward-Port-Of: odoo/odoo#183926
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798 Forward-Port-Of: odoo/odoo#184569 Forward-Port-Of: odoo/odoo#184500
Original PR description
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798 Forward-Port-Of: odoo/odoo#184569 Forward-Port-Of: odoo/odoo#184500
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. opw-4247067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184679
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Original PR description
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
To reproduce: - Create new BOM - In the components tab, enable the column manual consumption Current behavior: 'Manual Consumption' Expected behavior: 'Highlight Consumption' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184285
Original PR description
To reproduce: - Create new BOM - In the components tab, enable the column manual consumption Current behavior: 'Manual Consumption' Expected behavior: 'Highlight Consumption' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184285
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184543 Forward-Port-Of: odoo/odoo#183566
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-Port-Of: odoo/odoo#184394 Forward-Port-Of: odoo/odoo#183968
This commit slightly changes the behavior of the m2m edit_tags option so that it will only be effective in form view (like tag color edition) and also so that it will override color edition when color_field is set. It also adds visual feedback with the pointer style when the edit_tags option is set. task-3961350 Forward-Port-Of: odoo/odoo#181799
Original PR description
This commit slightly changes the behavior of the m2m edit_tags option so that it will only be effective in form view (like tag color edition) and also so that it will override color edition when color_field is set. It also adds visual feedback with the pointer style when the edit_tags option is set. task-3961350 Forward-Port-Of: odoo/odoo#181799
…S/IT Add FatturaPA as the preferred EDI format set by default on Italian partners. Fix the preffered EDI format of Spanish partners to be correctly computed to Facturae. task-no Forward-Port-Of: odoo/odoo#184822
Original PR description
…S/IT Add FatturaPA as the preferred EDI format set by default on Italian partners. Fix the preffered EDI format of Spanish partners to be correctly computed to Facturae. task-no Forward-Port-Of: odoo/odoo#184822
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185008 Forward-Port-Of: odoo/
Original PR description
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185008 Forward-Port-Of: odoo/odoo#183726
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with
Original PR description
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with a selection field - rename or remove the model - upgrade the module This commit fixes #179392. It was inspired by #104624. opw-3024537 Forward-Port-Of: odoo/odoo#184764
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b
Original PR description
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase -…
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/website_sale/controllers/main.py#L1159-L1168 Since `show_vat` is False the VAT fields will not be shown. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/views/templates.xml#L1990 However for ecuadorian company for example `vat` and `l10n_latam_identification_type_id` is set as mandatory. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/l10n_ec_website_sale/controllers/main.py#L17-L18 This discrepancy causes a traceback later on as we are requiring a field which is not visible in the view. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/static/src/js/address.js#L127-L135 opw-4139919 Forward-Port-Of: odoo/odoo#184612 Forward-Port-Of: odoo/odoo#183705
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184810
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184800 Forward-Port-Of: odoo/odoo#184152
Original PR description
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184800 Forward-Port-Of: odoo/odoo#184152
**Current behavior:** Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger. **Expected behavior:** The targeted field is cleared. **Steps to reproduce:** *Concrete example: `-i stock,web_studio` 1. Go to the form view for lots/serial numbers 2. Activate studio, add a new Boolean field and a M2o field (on res.partner for sake of example) in the view 3. Create a new automation rule which runs on `stock.l
Original PR description
**Current behavior:** Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger. **Expected behavior:** The targeted field is…
**Current behavior:**
Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger.
**Expected behavior:**
The targeted field is cleared.
**Steps to reproduce:**
*Concrete example: `-i stock,web_studio`
1. Go to the form view for lots/serial numbers
2. Activate studio, add a new Boolean field and a M2o field (on res.partner for sake of example) in the view
3. Create a new automation rule which runs on `stock.lot` like:
* Trigger: `On save`
* Before Update Domain: `Match all records`
* Apply on: `[('x_studio_new_boolean_field', '=', False)]`
4. Add an action to the rule like:
* Type: `Update Record`
* Action Details: `Update x_studio_new_m2o_field to <blank>`
5. Open a lot record, set the new boolean field to True and enter a partner in the m2o field -> save
6. Set the boolean to False then save again -> web error
**Cause of the issue:**
Setting the field to False is actually evaluated as setting it to 0 -> we write `res.partner(0,)` instead of clearing it. At the conclusion of the automation rule being triggered, there is a `web_save()` which returns a `web_read()` on the (in this instance) `stock.lot` record being written on.
Here, once we see the `x_studio` m2o field in the specification, there is a dict comprehension:
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L116-L119 Which calls `cleanup()` on the result of a recursive`web_read()` on `res.partner(0,)` which here is returning {'id': 0}. In `cleanup()`: `vals['id'] == 0 == False` -> Try to access `vals['id'].origin` which, of course, raises an exception.
**Fix:**
For m2o fields, evaluate Falsey expr values in `_eval_value()` to explicit `False`.
opw-4252864
Forward-Port-Of: odoo/odoo#184669When the user clicks on the checkbox of ``Valuation by Lot/Serial number``, a traceback will appear. Steps to reproduce the error: - Install ``stock_account`` module - Create a product(type : Goods) > Track Inventory: ``By Unique Serial Number`` - Create one variant of that product - Now, Open the product in one tab and open the product variant in another tab - Click on the checkbox of ``Valuation by Lot/Serial number`` in both tabs Traceback: ``` UnboundLocalError: cannot access
Original PR description
When the user clicks on the checkbox of ``Valuation by Lot/Serial number``, a traceback will appear. Steps to reproduce the error: - Install ``stock_account`` module - Create a product(type : Goods)…
When the user clicks on the checkbox of ``Valuation by Lot/Serial number``,
a traceback will appear.
Steps to reproduce the error:
- Install ``stock_account`` module
- Create a product(type : Goods) > Track Inventory: ``By Unique Serial Number``
- Create one variant of that product
- Now, Open the product in one tab and open the product variant in another tab
- Click on the checkbox of ``Valuation by Lot/Serial number`` in both tabs
Traceback:
```
UnboundLocalError: cannot access local variable 'products' where it is not associated with a value
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/sale_project/models/product_template.py", line 137, in write
return super().write(vals)
File "addons/stock_account/models/product.py", line 82, in write
impacted_templates[tmpl] = (products, description, products_orig_quantity_svl)
```
https://github.com/odoo/odoo/blob/09fa1db600c31d2d04f0504f0412cbbc85ff7e3d/addons/stock_account/models/product.py#L77-L82
Here, the ``products`` variable is referenced before the assignment,
So, it will lead to the above traceback.
sentry-5991310335
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183762In standards dashboards, pivot titles are currently extracted from the json files to be translated. But those titles are not visible in dashboard mode (only in edit mode, in the side panels and menus). The cost of translating those titles is not worth it. .pot files will be re-exported later, when TIC is back. She already warned the translators to skip those translation anyway. Task 4239967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
In standards dashboards, pivot titles are currently extracted from the json files to be translated. But those titles are not visible in dashboard mode (only in edit mode, in the side panels and menus). The cost of translating those titles is not worth it. .pot files will be re-exported later, when TIC is back. She already warned the translators to skip those translation anyway. Task 4239967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182748
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that
Original PR description
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that the `short_url_host` value will be False and this leads to a traceback when the compute method of `short_url` triggers. Ref of the breaking commit:- https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5 sentry-5969318187 Forward-Port-Of: odoo/odoo#182898
Description of the issue/feature this PR addresses: It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Current behavior before PR: User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Desired behavior after PR is merged: User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Task Adhoc side: 40557 Tas
Original PR description
Description of the issue/feature this PR addresses:
It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Current behavior before PR:
User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Desired behavior after PR is merged:
User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Task Adhoc side: 40557
Task latam: 1254
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176858We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Previously, when a project was shared without adding collaborators, an incorrect notification was sent, potentially confusing for the user. this commit ensures no notification is triggered if the collaborator's O2M field is empty,thereby avoiding misleading messages. task-3956252 Forward-Port-Of: odoo/odoo#176884
Original PR description
Previously, when a project was shared without adding collaborators, an incorrect notification was sent, potentially confusing for the user. this commit ensures no notification is triggered if the collaborator's O2M field is empty,thereby avoiding misleading messages. task-3956252 Forward-Port-Of: odoo/odoo#176884
**Current behavior before PR:** Users were unable to create or view threads from message actions on mobile devices due to an incorrectly written condition. The condition checked `component.isOriginThread`, but in mobile, the component is `MessageActionMenuMobile` insead of `Message`, which does not have the isOriginThread method. **Desired behavior after PR is merged:** This PR fixes the issue, allowing the create or view thread actions to display properly on mobile. --- I confirm
Original PR description
**Current behavior before PR:** Users were unable to create or view threads from message actions on mobile devices due to an incorrectly written condition. The condition checked `component.isOriginThread`, but in mobile, the component is `MessageActionMenuMobile` insead of `Message`, which does not have the isOriginThread method. **Desired behavior after PR is merged:** This PR fixes the issue, allowing the create or view thread actions to display properly on mobile. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184847
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected.
Original PR description
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected. - While creating a PO, products from the branches appear in the product list. opw-4116680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184964 Forward-Port-Of: odoo/odoo#180623
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72685 Forward-Port-Of: odoo
Original PR description
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72685 Forward-Port-Of: odoo/enterprise#71347
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#72614 Forward-Port-Of: odoo/enterprise#71851
Forward-Port-Of: odoo/enterprise#72581 Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72581 Forward-Port-Of: odoo/enterprise#72260
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position. Forward-Port-Of: odoo/enterprise#72548 Forward-Port-Of: odoo/enterprise#71857
In the `test_serial_product_packaging` tour, we scan 4 different serial numbers without waiting which can cause race condition (in case a scanned SN is finished to be processed before the previous scanned SN.) To fix that, two solutions: - Update each trigger to wait the result of previous scan; - Scan all SN as one single barcode, which force them to be processed in the right order. Second option is used by this commit since it's simplier. runbuild error: 99539 Forward-Port-Of: odoo/en
Original PR description
In the `test_serial_product_packaging` tour, we scan 4 different serial numbers without waiting which can cause race condition (in case a scanned SN is finished to be processed before the previous scanned SN.) To fix that, two solutions: - Update each trigger to wait the result of previous scan; - Scan all SN as one single barcode, which force them to be processed in the right order. Second option is used by this commit since it's simplier. runbuild error: 99539 Forward-Port-Of: odoo/enterprise#72520
task_id: 4261885 Forward-Port-Of: odoo/enterprise#72567
Original PR description
task_id: 4261885 Forward-Port-Of: odoo/enterprise#72567
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
### Before this PR: - The task column data was visible even when timesheets were grouped by task_id or helpdesk_ticket_id. - This caused misalignment in the table when grouped by these fields. ### After this PR: - The task column is hidden when timesheets are grouped by task_id or helpdesk_ticket_id. - The table headers is now correctly aligned. task-4184455 Forward-Port-Of: odoo/enterprise#71180
Original PR description
### Before this PR: - The task column data was visible even when timesheets were grouped by task_id or helpdesk_ticket_id. - This caused misalignment in the table when grouped by these fields. ### After this PR: - The task column is hidden when timesheets are grouped by task_id or helpdesk_ticket_id. - The table headers is now correctly aligned. task-4184455 Forward-Port-Of: odoo/enterprise#71180
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Steps to Reproduce: - Open All Timesheets in Timesheets app. - Scroll down in the grid view - Change view using view switcher Issue: - You can see that grid view starts at the top. - It is not the case in other views. Fix: - Adding root reference in useSetupAction Reason: - When a root reference is added it scrolls down the page to its previous state. task-4010043 Forward-Port-Of: odoo/enterprise#70637
Original PR description
Steps to Reproduce: - Open All Timesheets in Timesheets app. - Scroll down in the grid view - Change view using view switcher Issue: - You can see that grid view starts at the top. - It is not the case in other views. Fix: - Adding root reference in useSetupAction Reason: - When a root reference is added it scrolls down the page to its previous state. task-4010043 Forward-Port-Of: odoo/enterprise#70637
**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the cre
Original PR description
**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the creation. task-4213637 Forward-Port-Of: odoo/enterprise#71335
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next…
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#72159 Forward-Port-Of: odoo/enterprise#70577
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#72530 Forward-Port-Of: odoo/enterprise#71216
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#72530 Forward-Port-Of: odoo/enterprise#71216
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72603 Forward-Port-Of: odoo/enterprise#72468
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
We we tried to open the report with a company without journal and that the report had journal filter set, it would crash. The goal is to set the label of the filter explicitely to "No Journal" and make the filter unclickable when this is the case. task-4267503 Forward-Port-Of: odoo/enterprise#72226
Original PR description
We we tried to open the report with a company without journal and that the report had journal filter set, it would crash. The goal is to set the label of the filter explicitely to "No Journal" and make the filter unclickable when this is the case. task-4267503 Forward-Port-Of: odoo/enterprise#72226
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onC
Original PR description
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onClick. task-4204936 Forward-Port-Of: odoo/enterprise#72540 Forward-Port-Of: odoo/enterprise#71314
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archIn
Original PR description
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archInfo.activeActions.edit === true` opw-4272416 Forward-Port-Of: odoo/enterprise#72616 Forward-Port-Of: odoo/enterprise#72516
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144 Forward-Port-Of: odoo/enterprise#72459
Original PR description
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144 Forward-Port-Of: odoo/enterprise#72459
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72455 Forward-Port-Of: odoo/enterprise#72396
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72455 Forward-Port-Of: odoo/enterprise#72396
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays
Original PR description
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays correctly. Related : [odoo/ #184552](https://github.com/odoo/odoo/pull/184552) Forward-Port-Of: odoo/enterprise#72507