Monday, February 17, 2025
19 changes · 18.0
Enhancements to existing features
This change makes guided testing steps reusable across Odoo's web tour and Point of Sale test flows. It improves maintainability and consistency for automated checks, helping teams update tests more efficiently with minimal direct business impact.
Salary offer forms now default to selecting a new company car when the number of available cars is below the allowed unused-car limit. This helps HR teams align offers with fleet availability rules and reduces manual adjustments during contract salary proposals.
Original PR description
- make `new_car` True by default if the `available_cars_amount` is less than the `max_unused_cars` Task: 4378810
Resolved issues and error corrections
The Import Serials/Lots dialog in inventory receipts now displays its fields in the intended two-column layout instead of stacking them incorrectly. This improves usability when entering or importing lot and serial information, especially during purchase receipt processing.
Original PR description
Issue: The grid elements on the import Lots dialog are placed in one column instead of two, which misses up the layout. Reproduction steps: 1. install "purchase_stock" 2. create a product tracked by…
Issue:
The grid elements on the import Lots dialog are placed in one column instead of two, which misses up the layout.
Reproduction steps:
1. install "purchase_stock"
2. create a product tracked by lots
3. make an RFQ for that product and confirm it
4. click on the generated receipt smart button
5. in "Operations" tab, click fa-list icon to open the dialog
6. in the dialog, click "Import Serials/Lots
Reason:
The bug was introduced in [239e75b1385fa023e97396baa0c8d46c50997dda](https://github.com/odoo/odoo/commit/239e75b1385fa023e97396baa0c8d46c50997dda#diff-1377579fdb76de80cd31ca67d798b752a90600ab4c82a3c8799786a130b7a46fR431-R433), where the following style was added
```css
.o_cell:first-child:last-child {
grid-column: span 2;
}
```
which applies for the children of the first and the third grid elements; However, since the first and the third grid elements have `display: contents`, the `grid-column: span 2` of their children messes up the grid layout, and makes it 4x1 instead of 2x2.
The fix:
Remove `display: contents` on the first and third grid elements, as it seems to not be useful. Have tested on web and mobile layouts.
opw-4505725Miscellaneous 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
Restaurant kitchen preparation receipts now show the time the order was sent from the point of sale, using the cashier device's current time. This prevents missing times for unsynced orders and avoids showing UTC instead of the local business time.
Original PR description
When printing a preparation receipt the correct time was not shown (It was always UTC time). Also when the order was not sent to the server the time was not shown at all. Steps to reproduce: ------------------- * Setup a kitchen printer for a PoS * Open PoS go on a table and add some products * Click on the Order button > Observation: The time is not shown in the receipt * Leave the table and come back to it to make sure order is sent to the server * Add another product and send the order to the kitchen > Observation: The time is in UTC Why the fix: ------------ Instead of relying on the write date of the order we now rely on the current time of the client to show the time in the receipt. This time will always correspond to the time the order was sent to the kitchen. opw-4454102
Users now see the correct access-related error when trying to split a PDF in a Documents folder they no longer have permission to use. This avoids a confusing unrelated message and helps users understand that the action is blocked by folder permissions.
Original PR description
## Issue: When we upload a pdf document to a folder and remove access to that folder, if we attempt to split the document it shows an unralted error. ## Steps to reproduce: - install…
## Issue: When we upload a pdf document to a folder and remove access to that folder, if we attempt to split the document it shows an unralted error. ## Steps to reproduce: - install documents_project - Open documents app - Select "Projects" folder - Upload a pdf document - Edits "Projects" folder sharing settins to remove Mitchell Admin and restrict Internal users to None - Select the pdf document and click on "Split" button - Try to split the document - Not possible due to folder access error but the error message is not related to the issue ## Solution: - In the `PdfManager` component, we noticed that inside the `_sendChanges` method, we don't verify whether the response from the `pdf_split` controller is JSON before calling `.json()`. As a result, when we attempt splitting, an access error is raised in the controller, and Werkzeug returns an HTML error response by default. This leads to an error when `.json()` is called, which is eventually caught in `_applyChanges` and displayed in the notification instead of the intended access error. - this fix handles the error response from the `pdf_split` controller better by checking if the reponse is ok before calling `.json()`, and handling the error response accordingly. OPW-4453150
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
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`
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
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
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
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190529
Original PR description
This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190529
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#189697
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79301 Forward-Port-Of: odoo/enterprise#77398
Original PR description
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79301 Forward-Port-Of: odoo/enterprise#77398
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
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#79362
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#79362
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 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