Monday, February 17, 2025
33 changes · saas-18.1
Enhancements to existing features
The mail help command now shows the updated double-colon format for canned response shortcuts, matching the current way users trigger them. It also adds guidance for inserting emojis, making chat commands clearer and easier to use.
Original PR description
**Current behavior before PR:** Previously, the shortcut was triggered using `:shortcut`, which has now been updated to `::shortcut` on /help command. **Desired behavior after PR is merged:** to align with the new trigger format for canned responses it is changed to `::shortcut`. Additionally, a message has been added: 'Type :emoji: to insert an emoji in your message' to help users. task-4531300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The automation trigger selection field now uses the same placeholder text styling as other selection fields. This fixes an inconsistent visual appearance and makes the interface clearer for users configuring automated actions.
Original PR description
Since [1] the placeholder of SelectionField has seen its visual style adapted. This adapts the custom base_automation_trigger_selection field too. [1]: https://github.com/odoo/odoo/commit/b6598d9a2f524f37eb1a98f211d6adf027777b47 Description of the issue/feature this PR addresses: 
Miscellaneous changes
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197793 Forward-Port-Of: odoo/odoo#197007
Original PR description
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197793 Forward-Port-Of: odoo/odoo#197007
The ribbon label on appointment type cards now appears in the correct position on the right side. This improves visual consistency and makes appointment cards easier to read without changing business workflows.
Original PR description
Fix the position of the web ribbon which isn't correctly set to the right of the kanban card. related PR: odoo/enterprise#77884 Task-4582362
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behav
Original PR description
Refactor the `_run_manufacture` method in the `stock.rule` model to have a separate method to build the domain used to find an existing manufacturing order that can handle the procurement request. Having a separate method provides an easier way to extend the domain in other modules. A similar approach is already used in the `_run_buy` method. Description of the issue/feature this PR addresses: Patching the entire `_run_manufacture` method is required to change the MO domain. Current behavior before PR: The domain is built inside the `_run_manufacture` method Desired behavior after PR is merged: The domain is built in a dedicated method that can be easily overwritten in custom modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196396 Forward-Port-Of: odoo/odoo#196156
Before this commit, when an IoT device was connected, if you kept typing in the search box, the input would be reset to its previous state with each statusLoop execution. This fix cancels the debounce on re-render, ensuring that the search word is preserved. opw-4562152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197615
Original PR description
Before this commit, when an IoT device was connected, if you kept typing in the search box, the input would be reset to its previous state with each statusLoop execution. This fix cancels the debounce on re-render, ensuring that the search word is preserved. opw-4562152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197615
Steps to Reproduce: - Install the `l10n_in_hr_holidays` module. - Ensure there is only one company, and its country is set to India. - Sandwich leave feature is not available for common time-off types like Paid, Sick, etc. Cause: - Time off types for common categories (e.g., Paid, Sick) have `company_id` and `country_id` set to False. - In a single-company setup, users cannot change the country in these time-off types due to the lack of multi-company access. Fix: - Adjusted the visib
Original PR description
Steps to Reproduce: - Install the `l10n_in_hr_holidays` module. - Ensure there is only one company, and its country is set to India. - Sandwich leave feature is not available for common time-off types like Paid, Sick, etc. Cause: - Time off types for common categories (e.g., Paid, Sick) have `company_id` and `country_id` set to False. - In a single-company setup, users cannot change the country in these time-off types due to the lack of multi-company access. Fix: - Adjusted the visibility condition for the sandwich leave feature. If the `country_id` for the time-off type is False or India then the sandwich leave feature will now be available. task-4430006 Forward-Port-Of: odoo/odoo#194868
Commit c63d14a introduced new nicer urls to get to Odoo. Commit e44d13dfa9f301d7120cdb8441dfc6ca03d3d5d5 adapted the /mail/view controller for it, allowing people to copy a link to a mail.message and be redirected to it and its corresponding record. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is n
Original PR description
Commit c63d14a introduced new nicer urls to get to Odoo. Commit e44d13dfa9f301d7120cdb8441dfc6ca03d3d5d5 adapted the /mail/view controller for it, allowing people to copy a link to a mail.message and be redirected to it and its corresponding record. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is no crash, and the record is opened correctly with a nice url. see router.js: heuristics to discrimate a model name from an action path is the presence of dots, or the prefix m- for models opw-4564257 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#197883
Before this commit: ---------------------------------- - Components set as 'highlight consumption' in the BOM of serial-number tracked products were being automatically consumed when serial numbers were generated or via the mass produce option, causing unintended stock reductions. After this commit: ---------------------------------- - Fixed the issue where 'highlight consumption' components were incorrectly consumed during serial number generation. Components are now only consumed when e
Original PR description
Before this commit: ---------------------------------- - Components set as 'highlight consumption' in the BOM of serial-number tracked products were being automatically consumed when serial numbers were generated or via the mass produce option, causing unintended stock reductions. After this commit: ---------------------------------- - Fixed the issue where 'highlight consumption' components were incorrectly consumed during serial number generation. Components are now only consumed when explicitly required by the production process. Task-id: 4373005 Forward-Port-Of: odoo/odoo#197784 Forward-Port-Of: odoo/odoo#189697
When creating multiple preparation printers for different pos categories you could have a case where an empty receipt is printed. Steps to reproduce: ------------------- * Create 2 PoS categories CAT 1 and CAT 2 * Create a first preparation printer for CAT 2 * Create a second preparation printer for CAT 1 * Create a product P1 for CAT 1 * Assign the two printers to a PoS * Open PoS and add the P1 to your order * Send the order in preparation > Observation: Two receipts are printed an
Original PR description
When creating multiple preparation printers for different pos categories you could have a case where an empty receipt is printed. Steps to reproduce: ------------------- * Create 2 PoS categories CAT 1 and CAT 2 * Create a first preparation printer for CAT 2 * Create a second preparation printer for CAT 1 * Create a product P1 for CAT 1 * Assign the two printers to a PoS * Open PoS and add the P1 to your order * Send the order in preparation > Observation: Two receipts are printed and one of them is empty Why the fix: ------------ When going over each printer to print the relevant changes, if the first printer in the list has no changes it would always print an empty receipt because `last_preparation_change` would always be empty. To fix this we rely on `changes` to check if there are any changes to print on this printer opw-4462586 Forward-Port-Of: odoo/odoo#196808
Commit db12319e8b3b662a1498ee9a519fbced457174cc introduced a wrong behaviour for the discounts applied to an order when they are fixed or depending on the number of points. With this commit, the taxes applied would the ones set on the reward product if at least one line in the sale order had these taxes. Disregarding any other taxes applied, or not setting taxes at all. This was done to facilitate the reading of a sale order. Accounting wise, this is wrong. A product is paid less, so less tax
Original PR description
Commit db12319e8b3b662a1498ee9a519fbced457174cc introduced a wrong behaviour for the discounts applied to an order when they are fixed or depending on the number of points. With this commit, the taxes applied would the ones set on the reward product if at least one line in the sale order had these taxes. Disregarding any other taxes applied, or not setting taxes at all. This was done to facilitate the reading of a sale order. Accounting wise, this is wrong. A product is paid less, so less taxes needs to be recorded. It's not optimization, it's regulation. Reverting part of db12319e8b3b662a1498ee9a519fbced457174cc to evaluate how to ease the user life without having them getting on the warpath of their accountant. opw-4486030 TODO in master: take off taxes fields. Forward-Port-Of: odoo/odoo#196252
Before this commit: ========== - When the user returns to the payment screen from the floor screen and updates the payment line, the changes are not reflected in the backend. After this commit: ========== - Payment line changes will reflect in the backend after returning to the payment screen. task- 4512036 Forward-Port-Of: odoo/odoo#195194
Original PR description
Before this commit: ========== - When the user returns to the payment screen from the floor screen and updates the payment line, the changes are not reflected in the backend. After this commit: ========== - Payment line changes will reflect in the backend after returning to the payment screen. task- 4512036 Forward-Port-Of: odoo/odoo#195194
Purpose: -------- Replace the usage of the savepoints introduced in [this commit](https://github.com/odoo/odoo/commit/e7271331ee52596e307f402b76ff61b58ec59429) which might lead to poor performances. See https://github.com/odoo/odoo/pull/167236 for more details. Since commit and rollback are forbidden in tests, the part in the `test_scheduled_message_posting` test checking that the failed scheduled message was not posted has been removed. Task-4575344 Forward-Port-Of: odoo/odoo#197614
Original PR description
Purpose: -------- Replace the usage of the savepoints introduced in [this commit](https://github.com/odoo/odoo/commit/e7271331ee52596e307f402b76ff61b58ec59429) which might lead to poor performances. See https://github.com/odoo/odoo/pull/167236 for more details. Since commit and rollback are forbidden in tests, the part in the `test_scheduled_message_posting` test checking that the failed scheduled message was not posted has been removed. Task-4575344 Forward-Port-Of: odoo/odoo#197614
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk') Steps to reproduce: ------------------- * Create 2 products * Product 1: name: "Blue DESK" * Product 2: name: "Work table", reference: 'DESK_01' * Open pos shop * Search "desk" > Observation: "Blue DESK" product is found, not "Work table" * Search "DESK" > Observation: "Work table" product is found, not "Blue DESK" Why t
Original PR description
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk') Steps to reproduce: -------------------…
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk')
Steps to reproduce:
-------------------
* Create 2 products
* Product 1: name: "Blue DESK"
* Product 2: name: "Work table", reference: 'DESK_01'
* Open pos shop
* Search "desk"
> Observation: "Blue DESK" product is found, not "Work table"
* Search "DESK"
> Observation: "Work table" product is found, not "Blue DESK"
Why the fix:
------------
The behavior originates from https://github.com/odoo/odoo/commit/e9a27425a0c0b9da982aeaaec2accfa968ed1816
When doing a search, it looks for exact matches with the fields `barcode` and `default_code` and returns them, without looking for the matches in name. This is what happens when we search for "DESK" (simple example, the searchword should be greater than 5).
When we search for 'desk', no exact match is found as the function `exactMatches` is case sensitive. We then find the product thanks to `fuzzyLookup`.
This fix includes the name of the product in the exact match search and does not make it upper/lower case sensitive.
opw-4532712
Forward-Port-Of: odoo/odoo#197480
Forward-Port-Of: odoo/odoo#197183This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`
Original PR description
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install…
This error occurs when a user does not enter a Webhook Secret. As a result, when processing the payment, the missing secret causes the verification to fail, leading to a payment failure. - Install the `eCommerce` module without demo data and with Indian localization. - Install `Razorpay payment provider` and activate `developer mode`. - Add `Key ID` and `Key Secret` in Razorpay payment `provider`. - Set up webhook in Razorpay dashboard with a random `Webhook Secret`. - Go to the `website`, add the product to the cart, and proceed to payment using `UPI`.` `Error: 'bool' object has no attribute 'encode'` This issue occurs because the Webhook Secret is missing, returning False and causing payment verification to fail. This commit solves the error by handling missing `Webhook Secret` values by logging a warning and skipping the signature check instead of returning a False. Sentry: 6208134651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197136 Forward-Port-Of: odoo/odoo#196125
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n
Original PR description
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina -…
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n_ar_withholding_post_init`, for each company, we will compare a previously created dict to the existing accounts. If an account already exists, the data is removed from the dict, and since it is created before we start looping through the Companies to make the comparison, any removed data is removed for the companies that follow as well. ### Fix reasoning: We will copy the original dict to keep a safe version of the data and only modify the copy during the comparison process. opw-4446501 Forward-Port-Of: odoo/odoo#195475 Forward-Port-Of: odoo/odoo#194329
The issue is introduced in this PR: odoo/odoo#197115 Reason: When the test tour website_hr_recruitment_tour_edit_form is launched without demo data, the test failed because mitchell admin doesn't exist. Without demo data, the name of the administrator is administrator; so it's why instead of looking to mitchell admin this check will look to admin. task-4571866 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
The issue is introduced in this PR: odoo/odoo#197115 Reason: When the test tour website_hr_recruitment_tour_edit_form is launched without demo data, the test failed because mitchell admin doesn't exist. Without demo data, the name of the administrator is administrator; so it's why instead of looking to mitchell admin this check will look to admin. task-4571866 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#197503
Before delivery row was not displayed when dm was not set. It was confusing to not show delivery row when a product required delivery, and it caused a traceback on the checkout page when no delivery method was preselected and a user selected one. After this commit when delivery is not set yet, we will show explicitly that delivery is required but the price will be updated after its selection. task-4422630 opw-4397672 Forward-Port-Of: odoo/odoo#194986
Original PR description
Before delivery row was not displayed when dm was not set. It was confusing to not show delivery row when a product required delivery, and it caused a traceback on the checkout page when no delivery method was preselected and a user selected one. After this commit when delivery is not set yet, we will show explicitly that delivery is required but the price will be updated after its selection. task-4422630 opw-4397672 Forward-Port-Of: odoo/odoo#194986
Before this commit the taxes were calculated based only on delivery address even if a pickup location's country was different from delivery's one. After this commit, the correct fiscal position is set on selecting pickup point. opw-4485282 Forward-Port-Of: odoo/odoo#197371
Original PR description
Before this commit the taxes were calculated based only on delivery address even if a pickup location's country was different from delivery's one. After this commit, the correct fiscal position is set on selecting pickup point. opw-4485282 Forward-Port-Of: odoo/odoo#197371
The current behavior gives annoying results and we don't remember why we did it exactly at the first place. This reverts commit 1fd90ac27fadb1639dc15d645792ec7a71859808. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197527
Original PR description
The current behavior gives annoying results and we don't remember why we did it exactly at the first place. This reverts commit 1fd90ac27fadb1639dc15d645792ec7a71859808. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197527
When doing an export, a lot of information are computed depending on the partner, the company and the transaction. This commit will modify the field Invoice Type Transaction which is defined in a structure of 7-digit code: Standard Invoice must have 01 as the first 2 digits and 02 for simplified tax invoice. Other 5 digits depend on nature of the transaction. Before this commit we used to send for Individual contacts, 0200000 for all invoices, where the country of the Customer is not Sa
Original PR description
When doing an export, a lot of information are computed depending on the partner, the company and the transaction. This commit will modify the field Invoice Type Transaction which is defined in a structure of 7-digit code: Standard Invoice must have 01 as the first 2 digits and 02 for simplified tax invoice. Other 5 digits depend on nature of the transaction. Before this commit we used to send for Individual contacts, 0200000 for all invoices, where the country of the Customer is not Saudi Arabia. But it's actually wrong and we should send 0100100 which is a simple export invoice. To fix that issues we added a condition for an invoice to be simplified that the partner need to be an individual from Saudi Arabia. task-4504987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197627 Forward-Port-Of: odoo/odoo#195216
If the user is already registered on another SMP, we know we can only register him as a sender. If not, we have to register him as a receiver. A user can't be only a sender on Peppol. task-4394408 Forward-Port-Of: odoo/odoo#197139
Original PR description
If the user is already registered on another SMP, we know we can only register him as a sender. If not, we have to register him as a receiver. A user can't be only a sender on Peppol. task-4394408 Forward-Port-Of: odoo/odoo#197139
**Issue 1:** All taxes of the Malta localization don't have a tag for the base repartition line for the invoice type, but have one for the refund type. **Issue 2:** The tags for the refund type are all positive. They should be negative. opw-4557777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197789 Forward-Port-Of: odoo/odoo#197736
Original PR description
**Issue 1:** All taxes of the Malta localization don't have a tag for the base repartition line for the invoice type, but have one for the refund type. **Issue 2:** The tags for the refund type are all positive. They should be negative. opw-4557777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197789 Forward-Port-Of: odoo/odoo#197736
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197712 Forward-Port-Of: odoo/odoo#197373
Original PR description
This pull request includes an update to the `doc/cla/corporate/labiso.md` file. The change adds a new corporate contributor license agreement for LABISO GmbH, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197712 Forward-Port-Of: odoo/odoo#197373
The use of the parameters date_start and date_end in the url is not always correct in the planning gantt model. For instance, if date_start and date_end are given and are in the same week, the range selected has one day more than expected and does not start on the first day of the week. Here we fix/improve the usage of those parameters by removing the extra day (if any) and localizing appropriately the ranges. Task ID: 4500939 Forward-Port-Of: odoo/enterprise#79412 Forward-Port-Of: odoo/ente
Original PR description
The use of the parameters date_start and date_end in the url is not always correct in the planning gantt model. For instance, if date_start and date_end are given and are in the same week, the range selected has one day more than expected and does not start on the first day of the week. Here we fix/improve the usage of those parameters by removing the extra day (if any) and localizing appropriately the ranges. Task ID: 4500939 Forward-Port-Of: odoo/enterprise#79412 Forward-Port-Of: odoo/enterprise#79362
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
Original PR description
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise
Original PR description
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights -…
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise/commit/4220723e0779287e5a8e301553e1a870cd3c4ca5 in task: 2040710 Reason: No group where set on the button 'Purchase Orders' which is used to access the RFQ from the approval this button needs a protected field to be able to be displaed properly in addition to that no default value was set if the user has no rights to read the 'purchase.order.line' model. Expected behavior: The button should not be displayed if the user has no access rights to the RFQ and thus grand access to the approval of the user FIX add a default value if the user has no read rights on the model 'purchase.order.line' ultimatly making everything related to it in the form view invisible Also add a group to it in the view to permit to remove the default value in master task-3561514 Forward-Port-Of: odoo/enterprise#79098 Forward-Port-Of: odoo/enterprise#78275
Before this commit, the _next_billing_details would not compute the amount in the currency of the order. Forward-Port-Of: odoo/enterprise#74162
Original PR description
Before this commit, the _next_billing_details would not compute the amount in the currency of the order. Forward-Port-Of: odoo/enterprise#74162
### Steps to reproduce: - Create a recurring product with only one recurring plan - Go to the product's page in the website - Notice the pricing table is shown with only one plan ### Cause: In the pricing view in the website we are showing the pricing table just after checking if we have pricings or not. ### Fix: We are now checking if the pricings we have is more than one we will show the table otherwise will not show it. opw-4559071 Forward-Port-Of: odoo/enterprise#79102
Original PR description
### Steps to reproduce: - Create a recurring product with only one recurring plan - Go to the product's page in the website - Notice the pricing table is shown with only one plan ### Cause: In the pricing view in the website we are showing the pricing table just after checking if we have pricings or not. ### Fix: We are now checking if the pricings we have is more than one we will show the table otherwise will not show it. opw-4559071 Forward-Port-Of: odoo/enterprise#79102
Before this commit, the under warranty field is always copied when the user duplicates a task which it does not make sense since the new task could not have exactly the same context and the intervention could be different. This commit avoid copying the under warranty field when the user duplicates a task to let the user decide if the new task should be also in warranty or not. opw-4571460 Forward-Port-Of: odoo/enterprise#79250
Original PR description
Before this commit, the under warranty field is always copied when the user duplicates a task which it does not make sense since the new task could not have exactly the same context and the intervention could be different. This commit avoid copying the under warranty field when the user duplicates a task to let the user decide if the new task should be also in warranty or not. opw-4571460 Forward-Port-Of: odoo/enterprise#79250
Bug === In some situation, it's possible that the `is_template` raises when it shouldn't. It's more consistent to check it after the creation (super call). Task-4571151 Forward-Port-Of: odoo/enterprise#79173
Original PR description
Bug === In some situation, it's possible that the `is_template` raises when it shouldn't. It's more consistent to check it after the creation (super call). Task-4571151 Forward-Port-Of: odoo/enterprise#79173
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from a
Original PR description
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from all the records and check the condition across them. Sentry-6055370689 Forward-Port-Of: odoo/enterprise#74698
Steps to reproduce ============= 1. Allow edit access to portal user. 2. Try to publish an article from the portal user. The portal user has no right to publish/unpublish articles. After this commit ============== This commit prevents access error when portal users try to publish an article. Task-4414401 Forward-Port-Of: odoo/enterprise#79258 Forward-Port-Of: odoo/enterprise#76350
Original PR description
Steps to reproduce ============= 1. Allow edit access to portal user. 2. Try to publish an article from the portal user. The portal user has no right to publish/unpublish articles. After this commit ============== This commit prevents access error when portal users try to publish an article. Task-4414401 Forward-Port-Of: odoo/enterprise#79258 Forward-Port-Of: odoo/enterprise#76350