Daily updates from Odoo
Thursday, February 6, 2025
85 changes
19 changes
Resolved issues and error corrections
This fixes an incorrect test step in the online shop cart flow that was causing automated checks to time out. The change helps keep quality checks stable so future website sales updates can be validated more reliably.
Original PR description
Correct trigger which was wrong, causing JS test to timeout runbot-task-98520
Miscellaneous changes
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#195482
Original PR description
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#195482
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#196417 Forward-Port-Of: odoo/odoo#195451
Original PR description
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#196417 Forward-Port-Of: odoo/odoo#195451
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#195742
Original PR description
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#195742
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#190196
Original PR description
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#190196
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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-p
Original PR description
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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#177364 Forward-Port-Of: odoo/odoo#165333
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173010
Original PR description
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173010
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196475 Forward-Port-Of: odoo/odoo#196447
Original PR description
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196475 Forward-Port-Of: odoo/odoo#196447
Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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#195457
Original PR description
Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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#195457
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194627
Original PR description
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194627
A recent commit [1] removed the Mail Failure .JPG in favor of an .SVG for transparency. This commit restores the .JPG file alongside the .SVG to prevent potential issues. [1]: odoo/odoo@08f1a78f154d3bf80123b91a1deb0980b95c1ca3 task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196784
Original PR description
A recent commit [1] removed the Mail Failure .JPG in favor of an .SVG for transparency. This commit restores the .JPG file alongside the .SVG to prevent potential issues. [1]: odoo/odoo@08f1a78f154d3bf80123b91a1deb0980b95c1ca3 task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196784
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still
Original PR description
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still match and it would be possible to go beyond 35 characters. In this commit, we fix this by using a full match instead of a match from the beginning. [opw-4357554](https://www.odoo.com/odoo/project.task/4357554) Forward-Port-Of: odoo/odoo#194583
28 changes
Enhancements to existing features
This update replaces deprecated internal checks with the newer supported approach in accounting reports and Studio areas. It helps keep the platform aligned with current Odoo standards and reduces future maintenance risk, without changing day-to-day user workflows.
Original PR description
`odoo.models.check_method_name` is deprecated, replace usages by the new method. task-4505030 odoo/odoo#195402
Resolved issues and error corrections
The customer portal ticket list now uses ticket ID as the default sorting option instead of creation date. This removes a redundant sorting choice and makes the list order better match how users expect to review tickets.
Original PR description
In the ticket list view of the portal, we can filter tickets by create date and by ID. This is a bit redundant, and sorting by id reflects more accurately what we want to see. Therefore, this PR removes the filter by create date to default to the filter by ID instead. Task-4438387
Features or functions removed from Odoo
Old sales commission screens that were no longer loaded by the system have been removed. This cleans up unused files without changing the day-to-day user experience.
Original PR description
Since odoo/enterprise#68424 a file holding team and team members views is not imported anymore. It seems fields have been removed anyway at least on member model, assuming it should have been removed. Anyway nobody complained.
Code cleanup and technical improvements
This change reorganizes some internal model-building code into a separate file to keep the system easier to maintain. It should not change day-to-day behavior for users, but it helps developers manage related features more safely across modules.
Original PR description
Companion of https://github.com/odoo/odoo/pull/193559.
Miscellaneous changes
…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832 Forward-Port-Of: odoo/enterprise#74770
Original PR description
…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832 Forward-Port-Of: odoo/enterprise#74770
Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the
Original PR description
Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the invoice. Solution: Invoice by origin_order_id should come from the result of the query + move_by_origin Forward-Port-Of: odoo/enterprise#78603
Before this commit, the column of ticket ref field displayed in the list view of `helpdesk.ticket` has a size set to 30px. That hardcoded size makes the visibility of the content inside that column harder when the reference contains more than 6 digits. This commit removes the hardcoded size to let the framework computes the column size as before. opw-4524749 Forward-Port-Of: odoo/enterprise#78504
Original PR description
Before this commit, the column of ticket ref field displayed in the list view of `helpdesk.ticket` has a size set to 30px. That hardcoded size makes the visibility of the content inside that column harder when the reference contains more than 6 digits. This commit removes the hardcoded size to let the framework computes the column size as before. opw-4524749 Forward-Port-Of: odoo/enterprise#78504
Translate this new module. Translations were provided by MADI. task-4298921 Forward-Port-Of: odoo/enterprise#78659
Original PR description
Translate this new module. Translations were provided by MADI. task-4298921 Forward-Port-Of: odoo/enterprise#78659
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: -----------
Original PR description
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: ------------------- 1. Create an employee with flexible hours ex. 42:30h per week (8:30h per day) 2. Create a shift for the same employee on planning. 3. In the gantt view, when setting the date range to a week, the expected working hours of the period is showing 42h instead of 42:30h task-id: 4506633 Forward-Port-Of: odoo/enterprise#77782
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435 Forward-Port-Of: odoo/enterprise#78618 Forward-Port-Of: odoo/enterprise#77959
Original PR description
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435 Forward-Port-Of: odoo/enterprise#78618 Forward-Port-Of: odoo/enterprise#77959
When attempting to click ``Closing Entry`` in Tax Return, an error occurs. Steps to reproduce: --- - Install the ``account_reports`` module - Create a branch in the Main Company - Accounting > Reporting > Tax Return - Click ``Closing Entry`` Traceback: --- ``AttributeError: 'account.report' object has no attribute 'show_error_branch_allowed'`` At [1], an error occurs because the attribute was used without calling the method. Because at [2], the method was added in version 18.0 bu
Original PR description
When attempting to click ``Closing Entry`` in Tax Return, an error occurs. Steps to reproduce: --- - Install the ``account_reports`` module - Create a branch in the Main Company - Accounting > Reporting > Tax Return - Click ``Closing Entry`` Traceback: --- ``AttributeError: 'account.report' object has no attribute 'show_error_branch_allowed'`` At [1], an error occurs because the attribute was used without calling the method. Because at [2], the method was added in version 18.0 but later removed in the master branch. [1]- https://github.com/odoo/enterprise/blob/2780da762cd430f45d97ea8fa230181ccc4e30f8/account_reports/models/account_report.py#L1971 [2]- https://github.com/odoo/enterprise/pull/73018/files#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ec sentry-6237112729 Forward-Port-Of: odoo/enterprise#78482
Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904 Forward-Port-Of: odoo/enterprise#78408 Forward-Port-Of: odoo/enterprise#76233
Original PR description
Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904 Forward-Port-Of: odoo/enterprise#78408 Forward-Port-Of: odoo/enterprise#76233
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705 Forward-Port-Of: odoo/enterprise#78579
Original PR description
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705 Forward-Port-Of: odoo/enterprise#78579
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544Main: Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on the Move Line. However, depending on the state of the Move Line, lot_id may not be set and the tracking number will rather be available in lot_name. Currently, we only rely on lot_id, which may lead to an empty tracking number list, which in turn raises an unhandled exception. - We should try gett
Original PR description
Main: Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on…
Main: Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on the Move Line. However, depending on the state of the Move Line, lot_id may not be set and the tracking number will rather be available in lot_name. Currently, we only rely on lot_id, which may lead to an empty tracking number list, which in turn raises an unhandled exception. - We should try getting the tracking number from lot_name when lot_id is not set; - We should handle the case where the tracking number list is empty. N.B. : Only an empty tracking number list is problematic, the case of a list populated with null value is already handled by the epc_encoder. Before: - We only get the tracking number from lot_id.name; - No verification is done on the tracking number list. After: - Default to lot_name when lot_id is not set. - When the tracking number list is empty, set an error warning as the electronic_product_code on the concerned move lines. Forward-Port-Of: odoo/enterprise#76702
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two
Original PR description
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and…
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two copied slots instead of just one. Fix: ------------------- Currently, the _merge_slots_values() method is called when we use copy previous week on a forecasted slot (> 24 hours), which is the case here. This method takes work intervals and unavailabilites in parameters, and returns merged slots by taking into account the unavailabilites. To fix the issue mentioned above, we removed a condition that only allows slots to be merged if their combination creates a forecasted slot (> 24 hours). But we argue that we should also be able to merge smaller slots (< 24 hours). task-4368919 version-18.0 Forward-Port-Of: odoo/enterprise#76714
If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137 Forward-Port-Of: odoo/enterprise#77787
Original PR description
If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137 Forward-Port-Of: odoo/enterprise#77787
Bug: When doing a departure holiday attest for an employee leaving in between years, the payslip of the current year are actually the ones from the previous year. Reason: We were computing the year based on the start of the notice period. Fix: The year is based on the end of the notice period when there is one. Task: 4547648 Forward-Port-Of: odoo/enterprise#78612
Original PR description
Bug: When doing a departure holiday attest for an employee leaving in between years, the payslip of the current year are actually the ones from the previous year. Reason: We were computing the year based on the start of the notice period. Fix: The year is based on the end of the notice period when there is one. Task: 4547648 Forward-Port-Of: odoo/enterprise#78612
After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. Wh
Original PR description
After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. While the method originally supported only recordsets, it's actually convenient to support `int`s here to avoid browse in the action (more readable and more accessible to end-users). opw-4453249 Forward-Port-Of: odoo/enterprise#76599
Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397 Forward-Port-Of: odoo/enterprise#78539
Original PR description
Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397 Forward-Port-Of: odoo/enterprise#78539
Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see
Original PR description
Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see https://github.com/odoo/enterprise/pull/70232 Fix: Subtract the starting qty from the indirect demand qty for the corresponding subproduct. This is to make sure that the real `subproduct_indirect_demand` is compared to the 'ratioed' `replenish_qty` of the subproduct when selecting the date to use. task 4381021 Forward-Port-Of: odoo/enterprise#75141
The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78548 Forward-Port-Of: odoo/enterprise#66033
Original PR description
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78548 Forward-Port-Of: odoo/enterprise#66033
Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'. Steps to produce: - Change the default company country to other than US. - Try to install `l10n_us_hr_payroll`. - Observe the error. ``` ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/ l10n_us_hr_payroll/data/hr_salary_rule_data.xml:39 Rule category and structure should belong to the same country View error context: '-no context
Original PR description
Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'. Steps to produce: - Change the default company country to…
Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'. Steps to produce: - Change the default company country to other than US. - Try to install `l10n_us_hr_payroll`. - Observe the error. ``` ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/ l10n_us_hr_payroll/data/hr_salary_rule_data.xml:39 Rule category and structure should belong to the same country View error context: '-no context-' ``` The error occurs due to the validation rule in `hr.salary.rule` - [1]. Here, `rule.category_id.country_id`and `rule.country_id` must be the same. However, In the data record [2], `l10n_us_hr_payroll.hr_payroll_gross_pay` does not define the `country_id` [3]. According to [4], when `country_id` is not set, it defaults to the user's company country. If the user's company is not based in the US, this leads to a validation failure in `hr.salary.rule`, resulting in a `ParseError` while loading `hr_salary_rule_data.xml`. This commit resolves the issue by setting `country_id=base.us` in the category definition [3]. It will prevent conflicts when the user's company has a different default country. [1] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule.py#L239-L240 [2] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L39-L47 [3] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_category_data.xml#L22-L26 [4] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule_category.py#L20 sentry-6250322704 Forward-Port-Of: odoo/enterprise#78283
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Sen
Original PR description
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- *…
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Send the request to terminal * Disconnect ethernet cable from the worldline terminal * Cancel the payment > Observation: After the timeout, two errors appear: 1: underfined:undefined (Bug) 2: Please check if your iot box is still connected. (Normal) Why the fix: ------------ This commit https://github.com/odoo/enterprise/commit/35a392c27e70ffb5f4a5d8ca32bf10c38d7f709c added one more error throwing other than `_onActionFail()` when sending requests. In our case since the error is due to a timeout, it will raise the `_onActionFail()` but also the `Promise.reject(e)`. We consider that the `_onActionFail()` is enough for all potential failure here. opw-4414175 Forward-Port-Of: odoo/enterprise#78348 Forward-Port-Of: odoo/enterprise#77555
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227 Forward-Port-Of: odoo/enterprise#78159
Original PR description
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227 Forward-Port-Of: odoo/enterprise#78159
Manual forward port in 18.1 (for faster cherry-pick by internal team) of: https://github.com/odoo/enterprise/pull/77738 https://github.com/odoo/enterprise/pull/78487 Forward-Port-Of: odoo/enterprise#78594
Original PR description
Manual forward port in 18.1 (for faster cherry-pick by internal team) of: https://github.com/odoo/enterprise/pull/77738 https://github.com/odoo/enterprise/pull/78487 Forward-Port-Of: odoo/enterprise#78594
38 changes
Enhancements to existing features
Translate this new module. Translations were provided by MADI. task-4298921
Original PR description
Translate this new module. Translations were provided by MADI. task-4298921
Resolved issues and error corrections
The French accounting upgrade now avoids assigning standard identifiers to bank records with unusual custom BIC codes. This prevents custom bank data from being mistaken for official module-provided records during migrations.
Original PR description
The upgrade script is supposed to create xmlids for french banks that were already created from csv, if it matches custom records that have unusual bic, it is better to skip the whole record. Standard BIC format is a capital alphanumeric only. Replacing the spaces or unsupported characters in the xmlid will result in custom records looking like they come from standard module. alternate fix for https://github.com/odoo/odoo/pull/191970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes a failing automated check related to the restaurant point-of-sale tip screen. It helps keep the restaurant POS workflow stable and prevents build failures from blocking future updates.
Original PR description
Error runbot: 111972
The GSTIN status button and update action now appear only when the user is working with Indian companies. This prevents incorrect GSTIN status checks in multi-company setups and helps ensure the right tax environment is used.
Original PR description
This commit fixes a few issues in multi-company context: - only show the GSTIN status/update button when user has at least one IN companies selected - only allow the update when user's active company is an IN company (to ensure we correctly determine the EDI test/production status) opw-4367302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from attaching files by URL when the external response did not include expected file type information. The change makes the editor handle that missing detail safely, improving reliability when adding linked attachments.
Original PR description
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``. Traceback: --- ``` KeyError: 'content-type' File "odoo/http.py", line 2366, in…
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``.
Traceback:
---
```
KeyError: 'content-type'
File "odoo/http.py", line 2366, in __call__
response = request._serve_db()
File "odoo/http.py", line 1894, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1957, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1924, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2171, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/html_editor/controllers/main.py", line 355, in add_url
attachment = self._attachment_create(url=url, res_id=res_id, res_model=res_model)
File "addons/html_editor/controllers/main.py", line 256, in _attachment_create
mime_type = response.headers['content-type']
File "requests/structures.py", line 52, in __getitem__
return self._store[key.lower()][1]
```
https://github.com/odoo/odoo/blob/2fe55ae592e5812c5ee5e39ed1e8332bde608cb2/addons/html_editor/controllers/main.py#L257
sentry-6015024235
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes Spanish localization tax data by restoring price-inclusion override settings that were removed by mistake. It helps ensure Spanish tax calculations keep the intended behavior for affected accounting setups.
Original PR description
On https://github.com/odoo/odoo/commit/06d3ef5853aa0a93ac2de1642fd11ea191a3bbd3 price_include_override were erroneously removed
This fixes an issue where users could not print checks when the payment account did not allow reconciliation and the payment was immediately marked as paid. Check printing is now allowed in this case, preserving prior behavior, while voiding or rejecting these paid checks remains blocked.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks"…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account - Create a vendor bill and confirm it - Pay the bill with "Checks" as payment method => The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow reconciliation - Go the the check payment **Issue:** It is not possible to print it. The same configuration allows to print the check in previous versions. **Cause:** As the check payment is using an account that doesn't allow reconciliation, the payment is set in "Paid" state directly, but the printing is disabled for checks in that state. **Solution:** As it should be harmless to allow to print the check even if it is already paid, we will allow to print it to keep a consistent behavior with previous versions. Only printing the check will be allowed. Voiding or rejecting will still be impossible. opw-4498446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the point of sale Self Order flow from trying to subscribe to a missing or undefined communication channel. It helps avoid avoidable errors and improves reliability for customers using self-ordering.
Original PR description
Prevent subscription to undefined channel name in Self Order.
This fix corrects a few mislabeled Peppol electronic address scheme names that were introduced in a prior update. It helps users select the right invoicing identifiers and reduces confusion when configuring electronic invoicing partners.
Original PR description
Previous commit ([1]) tried to simplify with less technical names the Peppol EAS but introduced small errors. [1]: https://github.com/odoo/odoo/commit/5c7eefed412e676c6ddf67f62bce514e5bade44c task-no
This fix ensures stock-related actions triggered by subscriptions, rentals, and field service sales pass quantity information consistently. It reduces the risk of order processing errors and also avoids an access issue for project users working with field service sales orders.
Original PR description
The override of `_action_launch_stock_rule` was passing its `previous_product_uom_qty` keyword argument as a positional parameter to the `super` call, preventing other overrides from passing it with its key name. This commit ensures that the argument is now passed correctly with its key name. It also makes the override kwargs-agnostic by packing and unpacking them with `**`, thus preventing future issues related to signature changes in the parent method. See also: - https://github.com/odoo/enterprise/pull/77839 - https://github.com/odoo/documentation/pull/11823
The Overdue Invoices button on a partner now shows only sales-related documents, rather than including unrelated miscellaneous accounting entries. This helps users focus on the invoices that actually need follow-up and avoids confusion in customer account reviews.
Original PR description
When opening the Invoice Overdue through the partner form: 1 - Create over due MISC entries (through deferred entries for example) 2 - Open a partner 3 - Go the the Accounting tab 4 - Click the Overdue Invoices button -> Some MISC entries show while we only want to view sale document. This commit fixes that by adding a filter on the domain to reduce the search scope to only sale documents. task-4523037
Confirmed subscription sales orders no longer trigger an error when the Start Date or Next Invoice Date is changed or removed. This helps sales teams update subscription timing without interruptions.
Original PR description
This error occurs when attempting to change the ``Start Date`` or ``Next Invoice Date`` after the Sales Order has been confirmed. Steps to reproduce: --- - Install ``sale_subscription_stock`` module - Create a ``New`` Sale Order and fill in the required fields and order line - Now add ``Recurring Plan`` and in ``Other Info`` add ``Start Date`` > Confirm - Remove ``Start Date`` Traceback: --- ``TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'`` At [1] this commit resolves the issue by verifying the presence of the ``Start Date`` and ``Next Invoice Date``. [1]- https://github.com/odoo/enterprise/blob/68fa2f5ea8c42ccb66823efb847d230fe3994527/sale_subscription_stock/models/sale_order.py#L21 sentry-6220852935
Miscellaneous changes
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
Original PR description
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196518 Forward-Port-Of: odoo/odoo#187405
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#
Original PR description
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#196395
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194858
Forward-Port-Of: odoo/odoo#170080Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
Original PR description
Running the “test_workcenter_with_resource_calendar_from_another_company” without demo data occurs an error because the resource calendar. Forward-Port-Of: odoo/odoo#196656
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#196140 Forward-Port-Of: odoo/odoo#193971
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Original PR description
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&
Original PR description
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#196452 Forward-Port-Of: odoo/odoo#195859
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s
Original PR description
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196506 Forward-Port-Of: odoo/odoo#195379
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196487 Forward-Port-Of: odoo/odoo#196333
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196564 Forward-Port-Of: odoo/odoo#196376
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196400
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. 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#190201 Forward-Port-Of: odoo/odoo#174611
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Original PR description
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78560 Forward-Port-Of: odoo/enterprise#73906
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
Original PR description
See commits task-4497852 Forward-Port-Of: odoo/enterprise#78627 Forward-Port-Of: odoo/enterprise#77738
The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can s
Original PR description
This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can still send the order to eTims from the pos_order view. Stock moves are also send at the same time thanks to the l10n_ke_edi_oscu_stock module. Backport of: https://github.com/odoo/enterprise/pull/76247 task-3876855 Forward-Port-Of: odoo/enterprise#78505 Forward-Port-Of: odoo/enterprise#69583