Tuesday, May 6, 2025
52 changes · saas-18.3
New functionality added to Odoo
This update prepares the AI module backport by enabling code quality checks and adjusting related automated tests. It helps ensure the new AI-related changes integrate reliably with existing Discuss, HR Holidays, and Web functionality.
Original PR description
This PR is a follow-up on the implementation of the new AI features. It back-ports modifications to discuss that adds override points in three discuss objects `composer_actions`, `message_actions`, and `thread_actions`, fixes to tests, and addition of linting for the ai module. Enterprise PR: https://github.com/odoo/enterprise/pull/84610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Fleet users can now enter a vehicle's license plate and tags directly when creating a vehicle from the quick create view. This saves time and helps keep vehicle records better organized from the start.
Original PR description
This commit adds license plate and tags fields to the quick create view. task-4748528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Live Chat reporting label has been renamed from "Session Date" to "Date". This makes the field wording shorter and clearer for users without changing how the feature works.
Original PR description
task-4775658
Miscellaneous changes
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field
Original PR description
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given…
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions. #### speedup Test database with account_accountant and sale. Trying to create batches of account.moves | Batch size | Before PR | After PR | |:----------:|:---------:|:--------:| | 1 | 70ms | 58ms | | 50 | 150ms | 100ms | | 100 | 275ms | 188ms | | 250 | 660ms | 450ms | | 1000 | 2.43s | 1.75s | | 3000 | 7.55s | 5.33s | Average speedup: 68%. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197982 Forward-Port-Of: odoo/odoo#157887
The live chat sessions list no longer shows the channel and comment fields. This reduces visual clutter and helps users focus on the most relevant session information.
Original PR description
task-4775654
This update corrects spelling mistakes in help text for Live Chat reporting records. It improves clarity for users reading these descriptions without changing how the feature works.
Original PR description
task-4775729
This fixes the helper text shown when the live chat time-to-answer report has no data. It helps users better understand the empty report state and what the report is for.
Original PR description
Purpose of this commit: Update the empty record helper for im_livechat_report_channel_time_to_answer_action view.
This fixes an internal timing issue that could make a mail call test fail unpredictably. It stabilizes automated checks without changing the experience for users.
Original PR description
When posting the start call message, the last interest of the channel will be updated and it might be sent on the bus if the message is created at a different time than the channel. This is irrelevant for the test, so this commit will freeze time to ensure no change in last interest and no extra bus notification. runbot-161493
The live chat reporting view no longer shows the extra “(String)” text when grouping chatbot answer paths. This makes the report labels cleaner and easier for users to read without changing underlying data or behavior.
Original PR description
Purpose of this commit: Remove the '(String)' from the chatbot answer path groupby task-4775412
The live chat session report now lists the 'Day of Week' grouping option above 'Day' and uses consistent capitalization. This makes the reporting filters clearer and easier to scan for business users reviewing chat activity patterns.
Original PR description
Purpose of this commit: 1. Move 'Day of week' above 'Day' 2. Rename 'Day of week' to 'Day of Week' task-4775359
This fixes the live chat time-to-answer report so it uses an existing default date filter. Business users can open the report without running into a missing-filter issue, making the report behave as intended.
Original PR description
The `im_livechat_report_channel_time_to_answer_action` relies on a search default filter that does not exists. This commit creates the `filter_date_last_week` filter in order to use it on this action. task-4770492 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures manufacturing-related automated checks can run reliably even when demo data is not installed. It adds the needed setup data for tests, reducing false failures and improving confidence in release quality.
Original PR description
-test_order: Create a product to have at least one in the catalog and be able to select it in the tour -test_procurement: Create the category for the test -test_warehouse_mutlistep: Enable variant in setup to run the same way than with demo Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the Canadian localization tax configuration so certain taxes are no longer incorrectly included in Alberta's fiscal position. This helps ensure Alberta transactions use the appropriate tax rules and reduces the risk of incorrect tax reporting.
Original PR description
Based on fiscal positions prior to the code_upgrade in https://github.com/odoo/odoo/pull/205191 Certain taxes should not have been in the Alberta Fiscal Position Task-4752335
The Belgian fleet disallowed expenses feature now correctly installs the required Belgian expense categories before using them. This prevents setup errors and ensures vehicle-related expense account rules work as expected.
Original PR description
Commit https://github.com/odoo/enterprise/commit/66ec6f497d1adfdffae6840899d08c168f6ab63a links particular BE disallowed expense categories to accounts and makes a vehicle required when using those accounts. The dependencies of `l10n_be_account_disallowed_expenses_fleet` did not ensure the creation of the Belgian expense categories. Fix --- Add `l10n_be_disallowed_expenses` as a dependency of `l10n_be_account_disallowed_expenses_fleet` Solves Runbot-181948
This fixes a mobile issue in the VoIP keypad where tapping buttons could use the wrong action and fail. Taps and clicks now follow the same behavior, improving reliability and preventing unwanted zooming when users double-tap on mobile devices.
Original PR description
The touchend event must be preventDefault-ed to prevent zooming on double-tab on mobile. However, the touchend handler was incorrectly set to this.props.onClickKey, which doesn't exist. This commit updates the code to trigger a click event on touchend so that the same handler is used whether the button is tapped or clicked, preventing similar situations where the click handler is updated but not the touchend handler, leaving the latter broken.
When connecting the new image to v16 serial drivers get an error when trying to open a new serial connection with "access denied" This PR fixes this issue by adding odoo user to "dialout" group which grants it the required access (= control over serial interfaces) Forward-Port-Of: odoo/odoo#207762
Original PR description
When connecting the new image to v16 serial drivers get an error when trying to open a new serial connection with "access denied" This PR fixes this issue by adding odoo user to "dialout" group which grants it the required access (= control over serial interfaces) Forward-Port-Of: odoo/odoo#207762
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#206849
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 Forward-Port-Of: odoo/odoo#206849
### Steps to reproduce: - Install "l10n_it" and switch to an Italian company - Change the currency exchange rate so USD and EUR are not equal - Create a vendor bill or invoice in USD, with at least one product and a price higher than 0 - Confirm, send and inspect the XML generated for the SDI - The value of PrezzoTotale is different than PrezzoUnitario*Quantita ### Cause: "prezzo_unitario" is rounded during the currency conversion. ([see](https://github.com/odoo/odoo/blob/9a48804ed07779
Original PR description
### Steps to reproduce: - Install "l10n_it" and switch to an Italian company - Change the currency exchange rate so USD and EUR are not equal - Create a vendor bill or invoice in USD, with at least one product and a price higher than 0 - Confirm, send and inspect the XML generated for the SDI - The value of PrezzoTotale is different than PrezzoUnitario*Quantita ### Cause: "prezzo_unitario" is rounded during the currency conversion. ([see](https://github.com/odoo/odoo/blob/9a48804ed07779692da2952476d3906d1abfa302/addons/l10n_it_edi/models/account_move.py#L330)) But "prezzo_totale" is never rounded, it is taken directly from the tax details ### Solution: When converting "prezzo_unitario" avoid the rounding by adding `round=False`. opw-4720375 Forward-Port-Of: odoo/odoo#207084
**Steps to reproduce:** Create a new contact/company with more than 25 character **Issue:** The name field is partially shown as compared to version 16. **Cause:** The issue occurs after this change (odoo/odoo@a68cfbb) in version 17. The below CSS for the partner autocomplete field has been removed as the field has 'field_partner_autocomplete' widget. https://github.com/odoo/odoo/blob/05e60f226a0d15bfa3b71eaebe2786f4d687f23e/addons/partner_autocomplete/static/src/scss/partner_autocompl
Original PR description
**Steps to reproduce:** Create a new contact/company with more than 25 character **Issue:** The name field is partially shown as compared to version 16. **Cause:** The issue occurs after this change (odoo/odoo@a68cfbb) in version 17. The below CSS for the partner autocomplete field has been removed as the field has 'field_partner_autocomplete' widget. https://github.com/odoo/odoo/blob/05e60f226a0d15bfa3b71eaebe2786f4d687f23e/addons/partner_autocomplete/static/src/scss/partner_autocomplete.scss#L31-L34 **Solution:** Reintroduce partner autocomplete CSS fix (odoo/odoo@b9788544b7101e5a202cf87989bc3f5fc0495249) [opw-4686705](https://www.odoo.com/odoo/project/49/tasks/4686705) 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#205661
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 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#206925 Forward-Port-Of: odoo/odoo#201846
Original PR description
this commit makes the validation of stock moves assign next stock move of same procurement group first. This will makes the MTSO moves reservation acts like hard MTO. Task: 4374225 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#206925 Forward-Port-Of: odoo/odoo#201846
At the moment, whenever the partner is changed on an invoice, the l10n_latam_document_type_id field is recomputed and re-set to the default value corresponding to the partner and invoice type. We don't want this to happen if the existing l10n_latam_document_type_id is already compatible with the new partner. opw-4168385 Forward-Port-Of: odoo/odoo#208324 Forward-Port-Of: odoo/odoo#195581
Original PR description
At the moment, whenever the partner is changed on an invoice, the l10n_latam_document_type_id field is recomputed and re-set to the default value corresponding to the partner and invoice type. We don't want this to happen if the existing l10n_latam_document_type_id is already compatible with the new partner. opw-4168385 Forward-Port-Of: odoo/odoo#208324 Forward-Port-Of: odoo/odoo#195581
is_freelancer is not passed, but freelancer is as value to the XML opw-4634677 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#206127
Original PR description
is_freelancer is not passed, but freelancer is as value to the XML opw-4634677 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#206127
When working with trusted config loading an order from another config lead to an unknown session in the order. So no payment method can be used to pay the order. Now when loading an order from another config, the session is replaced by the current session. Forward-Port-Of: odoo/odoo#208313 Forward-Port-Of: odoo/odoo#208267
Original PR description
When working with trusted config loading an order from another config lead to an unknown session in the order. So no payment method can be used to pay the order. Now when loading an order from another config, the session is replaced by the current session. Forward-Port-Of: odoo/odoo#208313 Forward-Port-Of: odoo/odoo#208267
The data source of charts weren't reloaded on model update if the chart wasn't strictly an odoo_pie/line/bar. Task: [4759433](https://www.odoo.com/web#id=4759433&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#2
Original PR description
The data source of charts weren't reloaded on model update if the chart wasn't strictly an odoo_pie/line/bar. Task: [4759433](https://www.odoo.com/web#id=4759433&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#207899
When vat is unset in Company and user tries to send & print invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_hu_edi`` module > Switch to ``HU Company`` - Open ``HU Company`` > Unset vat field > Save - Go to Invoicing > Configuration > Settings > NAV Credentials > Mode: Demo > Save - Create a new invoice > Confirm > Send & Print > Send & Print Traceback: ``` QWebException: Error while render the template TypeError: argument of type 'bool' is not itera
Original PR description
When vat is unset in Company and user tries to send & print invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_hu_edi`` module > Switch to ``HU Company`` - Open ``HU…
When vat is unset in Company and user tries to send & print invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_hu_edi`` module > Switch to ``HU Company`` - Open ``HU Company`` > Unset vat field > Save - Go to Invoicing > Configuration > Settings > NAV Credentials > Mode: Demo > Save - Create a new invoice > Confirm > Send & Print > Send & Print Traceback: ``` QWebException: Error while render the template TypeError: argument of type 'bool' is not iterable Template: ir.ui.view(2872,) Path: /t/t[1]/base:taxpayerId Node: <ns0:taxpayerId xmlns:ns0="http://schemas.nav.gov.hu/OSA/3.0/base" t-out="vat[:8]"/> ``` https://github.com/odoo/odoo/blob/33b728c5917b06dd8ab46c48b160e3cf24ddc1ba/addons/l10n_hu_edi/models/res_company.py#L95-L96 For NAV Credentials(Mode: Demo), Credentials are not required. https://github.com/odoo/odoo/blob/33b728c5917b06dd8ab46c48b160e3cf24ddc1ba/addons/l10n_hu_edi/data/template_invoice.xml#L124-L131 When user unset the vat field , ``vat`` will be False. It will lead to the above traceback. sentry-6242690591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206233
In some case, the dest_address is not available when the picking type is dropship. In those cases, the final_location will be arbitrary fallback on default behavior and set to stock depsite we don't go through it. Instead we use the default location dest on the picking type as the final location since we can't guess where it goes. Also remove a location_final propagation through push rule if we already reach it. Description of the issue/feature this PR addresses: Current behavior before
Original PR description
In some case, the dest_address is not available when the picking type is dropship. In those cases, the final_location will be arbitrary fallback on default behavior and set to stock depsite we don't go through it. Instead we use the default location dest on the picking type as the final location since we can't guess where it goes. Also remove a location_final propagation through push rule if we already reach it. 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#207240
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice for the order; 5. via the delivery form, create & validate a return delivery; 6. create a new invoice for the order. Issue ----- The sales team on the initial invoice is the same one as on the order. The sales team on the second invoice is changed to a default value. Cause -----
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice…
Versions -------- - 17.0+ Steps ----- 1. Create a sales order with a deliverable product; 2. set sales team to a team you're not a member of; 3. validate the delivery; 4. create & confirm an invoice for the order; 5. via the delivery form, create & validate a return delivery; 6. create a new invoice for the order. Issue ----- The sales team on the initial invoice is the same one as on the order. The sales team on the second invoice is changed to a default value. Cause ----- The `team_id` gets recomputed on a `move_type` change. The reason the `move_type` changed after creation, is because the `_create_invoices` method first wants to have the final total of the invoice before deciding whether it should be an `out_invoice` or an `out_refund`: https://github.com/odoo/odoo/blob/d7af5c443b03c18e364a74571560b3583969c1d7/addons/sale/models/sale_order.py#L1401-L1407 Solution -------- Knowing that the `action_switch_move_type` method could recompute the `team_id`, protect the field when calling it in `_create_invoices`. opw-4563006 Forward-Port-Of: odoo/odoo#207973 Forward-Port-Of: odoo/odoo#205167
Following this commit : - getRenderedReceipt method is optimised to pass dynamic values. - o-employee-name class has been added for applying xpath. Enterprise PR: https://github.com/odoo/enterprise/pull/81559 task-4633156 Forward-Port-Of: odoo/odoo#208361 Forward-Port-Of: odoo/odoo#202003
Original PR description
Following this commit : - getRenderedReceipt method is optimised to pass dynamic values. - o-employee-name class has been added for applying xpath. Enterprise PR: https://github.com/odoo/enterprise/pull/81559 task-4633156 Forward-Port-Of: odoo/odoo#208361 Forward-Port-Of: odoo/odoo#202003
Fix an issue in the xml template where the custom import form reference is set at the wrong place, causing errors when it is in use at the same time as a customer reference. task-4761954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208048
Original PR description
Fix an issue in the xml template where the custom import form reference is set at the wrong place, causing errors when it is in use at the same time as a customer reference. task-4761954 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208048
…l10n_es_type Probably forgotten to update the agriculture changes when splitting the csv file for the Canary Islands CoA. Runbot error 161596 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#208122
Original PR description
…l10n_es_type Probably forgotten to update the agriculture changes when splitting the csv file for the Canary Islands CoA. Runbot error 161596 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#208122
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search. Soluti
Original PR description
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this…
Issue -->
When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.
Solution -->
Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.
Benchmarks -->
For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view.
| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s |
opw-4606704
Forward-Port-Of: odoo/odoo#203182If the user is fast (which happens in tours), it is possible to star a pending message, which leads to a crash on the server. This should simply not be possible. runbot-164180 Forward-Port-Of: odoo/odoo#207473
Original PR description
If the user is fast (which happens in tours), it is possible to star a pending message, which leads to a crash on the server. This should simply not be possible. runbot-164180 Forward-Port-Of: odoo/odoo#207473
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre
Original PR description
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + french translation added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206290 Forward-Port-Of: odoo/odoo#174511
…taxes are included in price 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#208021 Forward-Port-Of: odoo/odoo#205925
Original PR description
…taxes are included in price 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#208021 Forward-Port-Of: odoo/odoo#205925
Before this commit, pricelist rules defined on a parent category were not applied to products belonging to its child categories. opw-4685399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206906 Forward-Port-Of: odoo/odoo#204302
Original PR description
Before this commit, pricelist rules defined on a parent category were not applied to products belonging to its child categories. opw-4685399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206906 Forward-Port-Of: odoo/odoo#204302
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Add a "Mega Menu Item" to the menu. - Save the dialog. - Enter edit mode. - Click on the header. - Choose a dark background in the header options. - Click the "Mobile Preview" button to switch to mobile view. - Click the toggler button to open the menu. - Open the "Mega Menu". - Bug 1: The "close" and "back" icons are not visible. - C
Original PR description
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Add a "Mega Menu Item" to the menu. - Save the dialog. - Enter edit mode. - Click on the header. - Choose a dark background in the header options. - Click the "Mobile Preview" button to switch to mobile view. - Click the toggler button to open the menu. - Open the "Mega Menu". - Bug 1: The "close" and "back" icons are not visible. - Close the "Mega Menu". - Open the submenu. - Bug 2: The submenu is not visible because the background and text have the same light color, so nothing can be seen. The bug was introduced by commit [1], which made visual improvements to the menu. This commit fixes it by making sure the colors of the problematic elements adapt to the theme colors. [1]: https://github.com/odoo/odoo/commit/dc1a15539227c4c21837a7bce3fc4d81858d60b9 opw-4716573 Forward-Port-Of: odoo/odoo#208277
Steps: - install `pos_restaurant` - open pos restaurant - create new order - add two products - split the bill in two - 1 product per bill - pay for both of them - go to pos.order - the second bill does not have `pos_reference` When we split a bill in two, for example, we'll transform our order into two orders. This is done in `createSplittedOrder` via the method ` this.pos.createNewOrder()`. The `pos.order` is created in it and via `getNextOrderRefs` is called to set some values
Original PR description
Steps: - install `pos_restaurant` - open pos restaurant - create new order - add two products - split the bill in two - 1 product per bill - pay for both of them - go to pos.order - the second bill…
Steps: - install `pos_restaurant` - open pos restaurant - create new order - add two products - split the bill in two - 1 product per bill - pay for both of them - go to pos.order - the second bill does not have `pos_reference` When we split a bill in two, for example, we'll transform our order into two orders. This is done in `createSplittedOrder` via the method ` this.pos.createNewOrder()`. The `pos.order` is created in it and via `getNextOrderRefs` is called to set some values retrieved from the `get_next_order_refs` server, such as the `pos_reference`, `sequence_number` etc... Except that `getNextOrderRefs` is an asynchronous function, as it emits an rpc call. The problem is that in `createSplittedOrder` we never wait for this rpc call to finish before continuing, which causes our bug: the second order created contains no `pos_reference`. The solution provided by this commit is to use the asynchronism of `getNextOrderRefs` by using an optional callback passed to `getNextOrderRefs.then()` to make sure we've received the information from the server before continuing. With this method we don't change `createNewOrder` => it will still returns an order and not a `Promise` opw-4573422 Forward-Port-Of: odoo/odoo#203666 Forward-Port-Of: odoo/odoo#199371
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR
Original PR description
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. 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#207156 Forward-Port-Of: odoo/odoo#203432
Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207640
Original PR description
Description of the issue/feature this PR addresses: Wrong address/zip/city in Swiss QR bill template. Current behavior before PR: The template for Swiss QR bills uses the company address, zip code and city. Desired behavior after PR is merged: The template for Swiss QR bills uses the address/zip/city of the creditor's bank account, if available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207640
**Issue:** When User-defined Defaults are set for Unit of Measure (product.template or product.product) and sale_timesheet module is installed, the uom default is not respected. **Steps to reproduce:** - ensure sale_timesheet module is installed - settings > technical > user-defined Defaults - create a default for unit of measure (product.template) other than hour - create a new product of type service The issue occurs in both product.template and product.product opw-4604491 Forwa
Original PR description
**Issue:** When User-defined Defaults are set for Unit of Measure (product.template or product.product) and sale_timesheet module is installed, the uom default is not respected. **Steps to reproduce:** - ensure sale_timesheet module is installed - settings > technical > user-defined Defaults - create a default for unit of measure (product.template) other than hour - create a new product of type service The issue occurs in both product.template and product.product opw-4604491 Forward-Port-Of: odoo/odoo#207602 Forward-Port-Of: odoo/odoo#204423
Fix drag and drop in CRM tour because the tour bubble disappear if the record has not been dropped in the correct column. Now the tour bubble will stay visible until the opportunity is dropped in the correct stage. Still taking the last record of first column first, then last of second column, etc ... Task-4624497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207045
Original PR description
Fix drag and drop in CRM tour because the tour bubble disappear if the record has not been dropped in the correct column. Now the tour bubble will stay visible until the opportunity is dropped in the correct stage. Still taking the last record of first column first, then last of second column, etc ... Task-4624497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207045
Follow-up of https://github.com/odoo/odoo/pull/204922 PR above improved visual of (edited) label so that this is inline to the message content. Due to implementation details, it adds new test coverage when saving an edited message without changes, which may not have (edited) label with a simpler fix and this would be obviously a bug. The new steps to test may do `ctrl-ENTER` too soon, which would lead to not saving the message edition and instead the message is still being edited. As a res
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/204922 PR above improved visual of (edited) label so that this is inline to the message content. Due to implementation details, it adds new test coverage when saving an edited message without changes, which may not have (edited) label with a simpler fix and this would be obviously a bug. The new steps to test may do `ctrl-ENTER` too soon, which would lead to not saving the message edition and instead the message is still being edited. As a result, this assertion would fail: ``` Failed to find 1 of ".o-mail-Message-content" with text "edited again (edited)" (Timeout of 3 seconds). Found 0 instead. ``` This commit fixes the issue by awaiting that the message being edited shows the input with message content in textarea, ensuring the user can actually edit the message and thus the ctrl-ENTER shortcut works and saves the message edition. runbot-1629170 Forward-Port-Of: odoo/odoo#207079
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account. **Steps to reproduce:** - Make a Sale Order in the sales app - Go to POS and make a down payment for it. - Settle the order - See tha
Original PR description
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the…
**Problem:** When making a Sale Order, then trying to make a down payment for it in Point of Sale, the down payment won't be applied when settling the order. The only thing that will appear is the product with it's full price, even though we already payed a part of it in the down payment. The down payment won't be displayed and won't be taken into account. **Steps to reproduce:** - Make a Sale Order in the sales app - Go to POS and make a down payment for it. - Settle the order - See that the down payment has not been applied and only the product is present **Why the fix:** When reading the order we are trying to settle from the backend we also trigger the `missingRecursive` function as the lines corresponding to the downpayment line and the line sections were missing from the loaded records. `sale.order.line` records are thus read from the backend but are not linked back to the sale order leading to the missing lines on the pos order as well. opw-4718691 Forward-Port-Of: odoo/odoo#207295 Forward-Port-Of: odoo/odoo#206638
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
Original PR description
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the Vendor Bill. Adding the product straight from the vendor bill worked fine. **Steps to reproduce:** - Make a product with a landed cost. - Make a new vendor bill and go to the catalog from the Invoice Lines tab. - Search for your product and add it to the Vendor Bill. - Return to the Vendo
Original PR description
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the…
**Problem:** When adding a product that has the landed cost setting activated to a Vendor Bill, the landed cost checkbox was not checked, thus the product was not registered with a landed cost in the Vendor Bill. Adding the product straight from the vendor bill worked fine. **Steps to reproduce:** - Make a product with a landed cost. - Make a new vendor bill and go to the catalog from the Invoice Lines tab. - Search for your product and add it to the Vendor Bill. - Return to the Vendor Bill and see that the landed cost is not checked. **Cause of the issue:** The field is_landed_costs_line is set in an onchange function, thus when adding a product from the catalog the said function is not triggered and the is_landed_costs_line is not applied. https://github.com/odoo/odoo/blob/01058b94d860ab508bc2c013af5fe887e08247d9/addons/stock_landed_costs/models/account_move.py#L61-L66 **Fix:** An override of the create function was added to add the correct landed cost even when the onchange function is not called. With the onchange function and the create function, this ensures that the is_landed_costs_line will be set correctly regardless of where it is created from. opw-4521391 Forward-Port-Of: odoo/odoo#201622
Before this commit, the test "Message shows up even if channel data is incomplete" would sometimes fail. This happened because it waited for a bus subscription triggered by a call to the `_forceUpdateChannel` method of the bus service. However, this method is debounced, and as a result, the subscription sometimes occurred too late, causing the test to fail. This commit resolves the issue by using `runAllTimers`, which immediately executes the debounced method. fixes runbot-76011 Forward-P
Original PR description
Before this commit, the test "Message shows up even if channel data is incomplete" would sometimes fail. This happened because it waited for a bus subscription triggered by a call to the `_forceUpdateChannel` method of the bus service. However, this method is debounced, and as a result, the subscription sometimes occurred too late, causing the test to fail. This commit resolves the issue by using `runAllTimers`, which immediately executes the debounced method. fixes runbot-76011 Forward-Port-Of: odoo/odoo#208192 Forward-Port-Of: odoo/odoo#207914
Steps to Reproduce: 1. Install industry_fsm_sale module. 2. Create a SO with at least one SOL. 3. Save the record. 4. Delete the line, then click the Catalog button without saving. Issue: - An error occurs indicating a missing record. Cause: - The action_add_from_catalog method is accessing self.task_id, but self still includes the deleted SOL, which no longer exists. As a result, accessing its fields raises an error. Fix: - Move the action_add_from_catalog method to the
Original PR description
Steps to Reproduce: 1. Install industry_fsm_sale module. 2. Create a SO with at least one SOL. 3. Save the record. 4. Delete the line, then click the Catalog button without saving. Issue: - An error occurs indicating a missing record. Cause: - The action_add_from_catalog method is accessing self.task_id, but self still includes the deleted SOL, which no longer exists. As a result, accessing its fields raises an error. Fix: - Move the action_add_from_catalog method to the sale.order model, which is the appropriate place to handle this logic, ensuring the method doesn't depend on potentially stale or deleted lines. opw-4760487 Forward-Port-Of: odoo/enterprise#84414
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is g
Original PR description
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of…
Steps to reproduce: - Install payroll, payroll Mexican localisation - Switch to the Mexican company - Choose an employee from the Mexican company - Change the contract to be hourly waged instead of monthly - Set a value for the wage/hour - Create some work entries for that employee - Generate a payslip for the employee in the duration you are testing - Edit the work entries you have to have some unpaid leaves - Generate another payslip for the employee Current Behavior: Payslip is generated without taking into consideration the number of hours actually worked and the unpaid leaves taken by the employee. It also generates the payslip with the value of the wage/month regardless of the value of the wage/hour you added. Issue: In df8f53b0cad4738537f18890e628c286dedaa141, Mexican localisation was implemented but with computing the amount of the `payslip_worked_days` using the `contract.wage` which is the fixed amount of wage/month. https://github.com/odoo/enterprise/blob/25caeeab01abc0b47f6bd6b02658c3bbbe0aba96/l10n_mx_hr_payroll_localisation/models/hr_payslip_worked_days.py#L19-L20 opw-4604675 Forward-Port-Of: odoo/enterprise#83135
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84664 Forward-Port-Of: odoo/enterprise#84410
Original PR description
The SpreadsheetName component is designed to grow indefinitely with the length of its text content. However, this means that it'll end up breaking the page layout. This revisions revisits the component structurea and embedding to prevent it from growing larger than the visible viewport of the client. Task: 4760366 Forward-Port-Of: odoo/enterprise#84664 Forward-Port-Of: odoo/enterprise#84410
The compute method was removed in this commit, but is declared in the field. Traceback: --- AttributeError: 'product.product' object has no attribute '_compute_pricer_display_price' This commit resolves the above error by skipping the compute method when it is called. commit : https://github.com/odoo/enterprise/commit/70d96c44bb834ecbe89b5720ae18a93038301796#diff-2f3d348951d6293f7e805819d7053ac4ec65994bbacc829dac5dc68b00c932c> sentry-6547636163 Forward-Port-Of: odoo/enterprise#835
Original PR description
The compute method was removed in this commit, but is declared in the field. Traceback: --- AttributeError: 'product.product' object has no attribute '_compute_pricer_display_price' This commit resolves the above error by skipping the compute method when it is called. commit : https://github.com/odoo/enterprise/commit/70d96c44bb834ecbe89b5720ae18a93038301796#diff-2f3d348951d6293f7e805819d7053ac4ec65994bbacc829dac5dc68b00c932c> sentry-6547636163 Forward-Port-Of: odoo/enterprise#83599
Following this commit : - Aggregator name is displayed on KOT i.e Ubereats,Zomato etc. - Since it is an online order, instead of Dine In/ Take out , Delivery/Online should be displayed. - Preparation time is also displayed. Community PR: https://github.com/odoo/odoo/pull/202003 task-4633156 Forward-Port-Of: odoo/enterprise#84647 Forward-Port-Of: odoo/enterprise#81559
Original PR description
Following this commit : - Aggregator name is displayed on KOT i.e Ubereats,Zomato etc. - Since it is an online order, instead of Dine In/ Take out , Delivery/Online should be displayed. - Preparation time is also displayed. Community PR: https://github.com/odoo/odoo/pull/202003 task-4633156 Forward-Port-Of: odoo/enterprise#84647 Forward-Port-Of: odoo/enterprise#81559
In GSTR-2B, while doing the matching for previous bills, we want to avoid The bills that are already reconciled and marked as partially matched or fully matched. Sometimes, it's possible that there can be more than one bill with the same The reference number and if any of them has been already reconciled then We want to avoid it again being reconciled in next return periods. opw-4744438 Forward-Port-Of: odoo/enterprise#84497
Original PR description
In GSTR-2B, while doing the matching for previous bills, we want to avoid The bills that are already reconciled and marked as partially matched or fully matched. Sometimes, it's possible that there can be more than one bill with the same The reference number and if any of them has been already reconciled then We want to avoid it again being reconciled in next return periods. opw-4744438 Forward-Port-Of: odoo/enterprise#84497