Friday, February 28, 2025
48 changes · saas-18.1
Enhancements to existing features
The Vendor Bills shortcut on partner records is now provided by the Accounting app instead of Purchase. This keeps the button available where accounting-related vendor bill information belongs, while avoiding duplicate buttons during module updates.
Original PR description
Move the Vendor Bills smart button from the `purchase` module to the `account` module. The views records in `purchase` module are kept as but made empty so that if the user updates the `account` module, it will also update the `purchase` module and hide the smart button from the `purchase` to only keep the new one from the `account` module. task-4584035
The time off attendance view was adjusted so the “Extra Hours Available” label no longer wraps onto multiple lines. This improves readability and keeps the employee time off screen cleaner and easier to scan.
Original PR description
With this commit, the line `Extra Hours Available` is no longer wrapped. task-4526451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents the chatbot from continuing automated steps once a human operator has joined the conversation. It avoids confusing or duplicate bot responses during live support, keeping the customer experience clearer after handoff.
Original PR description
Once an operator has been found, the chat bot should not do anything else. However, it can happen that a step trigger is requested by the client. While this should and will be prevented in another PR, the "/chatbot/trigger" route is perfectly aware of the state of the chat and should not do anything in this case. This PR fixes this issue. task-4607689 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
Miscellaneous changes
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
Original PR description
This commit e35b3b088584b45b0278174da355d09e7e47633b was a fix for wrong calculation of base_url but the old calculation still there This was not detected because the test was not imported in __init__ file now it is removed and the test is imported in `__init__.py` opw-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199268
This fixes a restaurant appointment screen issue where part of the calendar view could fail when users changed the system language. The update makes the view more reliable for multilingual teams without changing day-to-day workflows.
Original PR description
This commit fixes xpath based on text that doesn't work if the language is changed
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were deleted before duplication. ## Steps to reproduce: - disable Analytic Accounting. - Create a service product that create a test, keep project empty. - create a project. - create a sale order with the service product and the project. - confirm the sale order. - remove the task that was created by
Original PR description
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were…
## Issue: When duplicating a sale order with a service product that creates tasks, adding a timesheet entry to the task from the duplicate sale order fails if the original task and project were deleted before duplication. ## Steps to reproduce: - disable Analytic Accounting. - Create a service product that create a test, keep project empty. - create a project. - create a sale order with the service product and the project. - confirm the sale order. - remove the task that was created by the service product and delete the project. - duplicate the sale order. - confirm the duplicate sale order. - open the task created by the sale order. - try adding a timesheet to the task. - an error is raised saying that the analytic account doesn't exist. ## Root cause: - When we delete a project, it's linked analytic account is removed automatically by the `project_project` override of the `unlink` method, but it might be still referred in the analytic distribution of sale order line, so when we try fetching it in `_timesheet_preprocess_get_accounts` it gives the "Missing Record" error. ## Fix: - make sure the analytic account exists when browsing to them in `_timesheet_preprocess_get_accounts`. - fallback to super when there are no analytic accounts OPW-4474903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197061
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and w
Original PR description
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting…
Backport a part of 40da85aab905fd4accf8c01887e62b07537ccd2f. Make some of the ORM methods private for the sake of correctness and to prevent people from using incorrect RPC calls. We are targeting methods that return recordsets that are not returned in the correct format in RPC. This commit doesn't strictly follow our stable policy, but it's unlikely to break anything. Small change to the original version: we are not directly modifying odoo.api.call_kw(), as it is used by _eval_xml() and we don't want to change that in stable (or we need to backport part of https://github.com/odoo/odoo/pull/182709). #### Original commit message Explicitly prevent calling non-public ORM methods via RPC, without breaking the API The ORM contains a series of API methods found on Models and recordsets, next to the main CRUD methods. Those utility methods are very commonly used in server-side business logic code, and were historically named without the usual underscore prefix that should mark them as private (e.g. `_private_method()` vs `public_method()`). Examples: - the `browse()` method returns a recordset from a list of IDs, which is really just a proxy object prepared for other recordset operations ; - the `fetch()` and `search_fetch()` methods populate the transactional in-memory cache for a set of fields and record ; - and many more... The lack of prefix makes writing business logic code a bit simpler, but causes confusion because these methods look like they are public. Of course, calling such internal methods over RPC doesn't make sense, and may crash or cause unexpected results. This commit marks those internal methods and prevents calling them over RPC. This is preferred over renaming them with an underscore prefix, as that would break a lot of existing code without a good reason. All business logic code must still follow the best-practicce convention of prefixing non-public method with underscores, by default and by design, to avoid mixing different conventions. The `@api.private` decorator is reserved for exceptions for ORM methods. task-4505030 https://github.com/odoo/enterprise/pull/79382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199476 Forward-Port-Of: odoo/odoo#197783
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to th
Original PR description
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now…
Since https://github.com/odoo/enterprise/commit/a94227b6f305ffabbe18a5ea98335a3b17659d2d, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company. We received a lot of feedback from people wanting to avoir the 1 to 1 mapping, and needing to configure such customized groupby on the report. The add of a related fields is a bit too technical to be explained in any kind of functional documentation; therefore we make the choice to add them in the standard code. They are non-stored, and will have no impact on any other flow. Note that this groupby customization only works on standard engines at the moment. Custom engines still need to be adapted, but this will come in a future PR. Forward-Port-Of: odoo/odoo#199550
### Steps to reproduce: - Install l10_din5008 and select the DIN5008 layout in the settings - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have several styles missing: - Section lines have no background color - There are no line separations - Column titles are not bold ### Cause: The style that was applied to all reports was removed during a refactoring in 18.0. https://github.com/odoo/odoo/pull/169512 ### Solution: Change t
Original PR description
### Steps to reproduce:
- Install l10_din5008 and select the DIN5008 layout in the settings
- Go to Sale, create a quotation with section lines
- Confirm and send
- The generated PDF have several styles missing:
- Section lines have no background color
- There are no line separations
- Column titles are not bold
### Cause:
The style that was applied to all reports was removed during a refactoring in 18.0.
https://github.com/odoo/odoo/pull/169512
### Solution:
Change the CSS of the DIN5008 report to make it look like in 17.0.
In 17.0
In 18.0
After this commit
opw-4572732
Forward-Port-Of: odoo/odoo#199213When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
Original PR description
When registration form have extra form details where the field value doesn't match an attendee field format (2 or 3 values separated by a dash) we where crashing while trying to unpack the split value. This commit simply ignore the field if its value doesn't match the expected format of an attendee field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199543
If there are IAP accounts that share the same token, it would cause a crash when fetching the accounts information from the IAP server. It wasn't anticipated that two IAP account records could share the same token. This doesn't happen under normal circumstances, it can only happen if the accounts were manually duplicated (which should never be done). The error actually only happens for duplicated SMS accounts, as the function `_get_account_info` in which the crash occurs is compatible with
Original PR description
If there are IAP accounts that share the same token, it would cause a crash when fetching the accounts information from the IAP server. It wasn't anticipated that two IAP account records could share the same token. This doesn't happen under normal circumstances, it can only happen if the accounts were manually duplicated (which should never be done). The error actually only happens for duplicated SMS accounts, as the function `_get_account_info` in which the crash occurs is compatible with recordset containing > 1 record in the main definition, but not in the override of the SMS module. opw-4571624 Forward-Port-Of: odoo/odoo#199451
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Set the correct accounts for expense & income currency exchange accounts Description of the issue/feature this PR addresses: task: https://www.odoo.com/odoo/my-tasks/4179478 swap Exchange Difference Gain & Exchange Difference Loss Current behavior before PR: - The exchange difference accounts were wrongly assigned Desired behavior after PR is merged: - Fix issue by swapping them --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196950 Forward-Port-Of: odoo/odoo#190704
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199599
Original PR description
The sequence of events leads to slightly different results in Chrome 133 which results in the test failing. This commit changes the sequence of events so that the test passes in Chrome 133 as well as the prior versions. Forward-Port-Of: odoo/odoo#199599
Enterprise PR: https://github.com/odoo/enterprise/pull/79432 As part of adding the Tyro payment method, new functionality was required in order to not automatically send payments to the terminal upon adding a payment line. This gives a chance to input a different payment amount, for example when splitting the payment between multiple cards. By default the behaviour is the same as before, but if a payment method overrides `fast_payments` to false, then payments will not be sent auto
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/79432 As part of adding the Tyro payment method, new functionality was required in order to not automatically send payments to the terminal upon adding a payment line. This gives a chance to input a different payment amount, for example when splitting the payment between multiple cards. By default the behaviour is the same as before, but if a payment method overrides `fast_payments` to false, then payments will not be sent automatically (the same behaviour as pre v18). task-4086116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187536
This error occurs when a user sends a file without a message, and `Create Thread`. Step to Reproduce : - Install and open module `Discuss`. - Open Channel and send any file from `Attach files` without a message. - Hover over the sent file, click on `Expand`, and then click `Create Thread` AttributeError: 'str' object has no attribute 'striptags' This issue occurs when data is `str` instead of an HTML object. This commit fixes the error by ensuring .striptags() is only used when
Original PR description
This error occurs when a user sends a file without a message, and `Create Thread`. Step to Reproduce : - Install and open module `Discuss`. - Open Channel and send any file from `Attach files` without a message. - Hover over the sent file, click on `Expand`, and then click `Create Thread` AttributeError: 'str' object has no attribute 'striptags' This issue occurs when data is `str` instead of an HTML object. This commit fixes the error by ensuring .striptags() is only used when the data is in the correct format. sentry - 6304779383 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197896
To reproduce: 1. Create an Analytic Account 2. Use this Analytic Account in an account move and post it. 3. Return to the Analytic Account and delete it. The deletion goes through. 4. The move no longer has the Analytic Account. The issue: Currently, an Analytical Account can be deleted even if it has been used in an analytic item, be it a move or an analytic simulation. Hence, the move no longer has the analytic account that was added when the move was posted, without any warnings to th
Original PR description
To reproduce:
1. Create an Analytic Account
2. Use this Analytic Account in an account move and post it.
3. Return to the Analytic Account and delete it. The deletion goes through.
4. The move no longer has the Analytic Account.
The issue:
Currently, an Analytical Account can be deleted even if it has been used in an analytic item, be it a move or an analytic simulation. Hence, the move no longer has the analytic account that was added when the move was posted, without any warnings to the user.
Solution:
Make the fields "x_plan{id_}_id" on analytic lines ondelete='restrict'. An upgrade script is added to handle existing analytic accounts.
task-4567137
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#199305
Forward-Port-Of: odoo/odoo#197886Steps to reproduce: 1) Enable Click and Collect 2) Configure pick up in store and add a store in US with state set 3) Set the available country to US and available state as in the store's partner 4) Enable Pay on site 5) Go to /shop page and add a storable product 6) Proceed to payment and pay choosing pickup in store delivery method and pay on site payment method 7) Observe an error Reason: /shop/payment/validate checks for payment errors. When confirming a sales
Original PR description
Steps to reproduce:
1) Enable Click and Collect
2) Configure pick up in store and add a store in US with state set
3) Set the available country to US and available state as in the
store's partner
4) Enable Pay on site
5) Go to /shop page and add a storable product
6) Proceed to payment and pay choosing pickup in store delivery method
and pay on site payment method
7) Observe an error
Reason:
/shop/payment/validate checks for payment errors. When confirming a
sales order with pickup in-store dm the partner_shipping_id is set to
the created partner from the selected pickup point address.
However, the state was missing which resulted in creating a partner
with an empty state causing the `_get_delivery_methods` called by
`_get_shop_payment_errors` show an error.
Solution:
Save a state for pickup location data
opw-4592939
Forward-Port-Of: odoo/odoo#199601This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior a
Original PR description
This commit fixes an issue where the partner assigned to a booth could be incorrect based on the provided email. Indeed, we don't want to assign an existing partner when non-logged, as it could conflict when trying to checkout the order and providing another one. In addition, it just does not make much sense. Instead we now suggest to login before booking your booths. Task-4163951 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#199593 Forward-Port-Of: odoo/odoo#179083
Before, when invoices were created from a sales order and one of the lines is a combo product, it would create a regular invoice line for that with the combo product, but the price would be zero and no taxes. The problem with that when sending electronic invoicing documents, is that it will treat that as a zero line. (and some EDIs might e.g. complain there is no tax on there) So, that way when creating the invoice line, we define it as a subsection with the product name as description but
Original PR description
Before, when invoices were created from a sales order and one of the lines is a combo product, it would create a regular invoice line for that with the combo product, but the price would be zero and no taxes. The problem with that when sending electronic invoicing documents, is that it will treat that as a zero line. (and some EDIs might e.g. complain there is no tax on there) So, that way when creating the invoice line, we define it as a subsection with the product name as description but without product. opw-4410461 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#192568
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#181442 Forward-Port-Of: odoo/odoo#174750
Original PR description
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#181442 Forward-Port-Of: odoo/odoo#174750
Before this commit, in the lot kanban view, if a lot was expired, the alert icon and the overpass days were on different lines. This commit fixes that so the alert icon is just beside the date. Before / After:   Enterprise PR: odoo/enterprise#80338 For
Original PR description
Before this commit, in the lot kanban view, if a lot was expired, the alert icon and the overpass days were on different lines. This commit fixes that so the alert icon is just beside the date. Before / After:   Enterprise PR: odoo/enterprise#80338 Forward-Port-Of: odoo/odoo#199554
This commit enhances the display of the website name in the dropdown menu and the website systray item by utilizing the `text-truncate` class to manage long names more effectively. task-4069591 Forward-Port-Of: odoo/odoo#178206
Original PR description
This commit enhances the display of the website name in the dropdown menu and the website systray item by utilizing the `text-truncate` class to manage long names more effectively. task-4069591 Forward-Port-Of: odoo/odoo#178206
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the h
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate https://github.com/odoo/odoo/pull/199063 Forward-Port-Of: odoo/odoo#199296
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross com
Original PR description
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross compare opw-4481596 Forward-Port-Of: odoo/odoo#198480
This line would consistently crash with: `NameError: name '_' is not defined` Forward-Port-Of: odoo/odoo#199629
Original PR description
This line would consistently crash with: `NameError: name '_' is not defined` Forward-Port-Of: odoo/odoo#199629
This commit:https://github.com/odoo/odoo/commit/134324c5cf0e2e62f02d212ac27a9442e1f7a824 removed the auto-install for l10n_fr. Which has the consequence of not having l10n_fr_account installed when we have account and l10n_fr. This commit will reintroduce that but also removing the countries since it depends on l10n_fr that already has the country set up. task: 4296946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odo
Original PR description
This commit:https://github.com/odoo/odoo/commit/134324c5cf0e2e62f02d212ac27a9442e1f7a824 removed the auto-install for l10n_fr. Which has the consequence of not having l10n_fr_account installed when we have account and l10n_fr. This commit will reintroduce that but also removing the countries since it depends on l10n_fr that already has the country set up. task: 4296946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198884 Forward-Port-Of: odoo/odoo#197269
Current behavior before PR: - After this [fix](https://github.com/odoo/odoo/commit/56d5c9f4861b3509043660c97a702bfe0e636e3f) , any type searching is not possible for `placeholder_code` field. - For every filter applied, it just return `invalid domain error`. - this is because ` _search_placeholder_code` uses `=like` operator, but this makes it, unsearchable from frontend, as filters supports `ilike` and its related operators.  , any type searching is not possible for `placeholder_code` field. - For every filter applied, it just return `invalid domain error`. - this is because ` _search_placeholder_code` uses `=like` operator, but this makes it, unsearchable from frontend, as filters supports `ilike` and its related operators.  Desired behavior after PR is merged: - This PR fixes this issue, by changing the operator from `=like` -> `=ilike` - `placeholder_code` field can now be searched for filters like `starts with` and `ends with` .  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198284
- While calling `_generate_primary_snippet_templates`, `create_missing_views` fetches the existing snippet views. However, archived snippet is ignored, causing `create_missing_views` to attempt to create the snippet again, mistakenly considering it as a missing view. This leads to a traceback: ```py File "/data/build/odoo/odoo/sql_db.py", line 332, in execute res = self._obj.execute(query, params) psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_mod
Original PR description
- While calling `_generate_primary_snippet_templates`, `create_missing_views` fetches the existing snippet views. However, archived snippet is ignored, causing `create_missing_views` to attempt to create the snippet again, mistakenly considering it as a missing view. This leads to a traceback:
```py
File "/data/build/odoo/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "ir_model_data_module_name_uniq_index"
DETAIL: Key (module, name)=(website, new_page_template_services_0_s_website_form) already exists.
```
- To prevent such errors, it's better to fetch inactive views as well during creation.
opw-4510585
upg-2452055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197107Steps: - Install Ecom. - Go to shop page. - Add a product in cart goto address section in checkout. - Try to add new address. Issue: - Warning displaying for of same address for billing and delivery even though we are create new address Cause: - Missing condition to check if address is existing or new one. Fix: - Add condition on warning section to display it only for existing addresses. opw-4522138 Forward-Port-Of: odoo/odoo#199553
Original PR description
Steps: - Install Ecom. - Go to shop page. - Add a product in cart goto address section in checkout. - Try to add new address. Issue: - Warning displaying for of same address for billing and delivery even though we are create new address Cause: - Missing condition to check if address is existing or new one. Fix: - Add condition on warning section to display it only for existing addresses. opw-4522138 Forward-Port-Of: odoo/odoo#199553
In this commit: === - Updated tour test to verify the presence of both the unique code and portal URL instead of a QR code check. runbot: 111424 Forward-Port-Of: odoo/odoo#199231
Original PR description
In this commit: === - Updated tour test to verify the presence of both the unique code and portal URL instead of a QR code check. runbot: 111424 Forward-Port-Of: odoo/odoo#199231
**Before this PR:** - Users could not drag and drop the call participant card in the chat window due to incorrect position computations. - Participant card was positioned at bottom right, causing the "End Call" button to be hidden behind it. **This PR:** - Fixes the drag-and-drop issue by correcting the position calculations. - Adds 5vh bottom offset for card so it doesn't overlap "End Call" button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
**Before this PR:** - Users could not drag and drop the call participant card in the chat window due to incorrect position computations. - Participant card was positioned at bottom right, causing the "End Call" button to be hidden behind it. **This PR:** - Fixes the drag-and-drop issue by correcting the position calculations. - Adds 5vh bottom offset for card so it doesn't overlap "End Call" button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190309
We cannot properly handle the case where one line is shipped from multiple addresses. But we gave up too early: just because one sale line is linked to multiple stock moves doesn't necessarily mean that's the case. Here's an example that uses a single warehouse: 1/ create a sale order with one line with qty 2 2/ confirm the sale order 3/ validate the picking with qty 1 and create backorder for the other 4/ create the invoice from the sale order 5/ compute taxes No line-level address
Original PR description
We cannot properly handle the case where one line is shipped from multiple addresses. But we gave up too early: just because one sale line is linked to multiple stock moves doesn't necessarily mean that's the case. Here's an example that uses a single warehouse: 1/ create a sale order with one line with qty 2 2/ confirm the sale order 3/ validate the picking with qty 1 and create backorder for the other 4/ create the invoice from the sale order 5/ compute taxes No line-level address is sent because len(line.sale_line_ids.move_ids) is 2. This causes Avatax to calculate taxes based on the company address which could result in wrong taxes. After this commit, we only set None if a line was sent from warehouses with different addresses (partner_id). opw-4486746 Forward-Port-Of: odoo/enterprise#80103 Forward-Port-Of: odoo/enterprise#78556
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#80286 Forward-Port-Of: odoo/enterprise#79382
Original PR description
`odoo.models.check_method_name` is softly deprecated, replace usages by the new method. task-4505030 https://github.com/odoo/odoo/pull/197783 Forward-Port-Of: odoo/enterprise#80286 Forward-Port-Of: odoo/enterprise#79382
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state, `invoice_received`, in a validation that triggers the update of the SAT state for the current invoice. Steps to reproduce: <img width="1301" alt="Screenshot 2025-02-13 at 11 23 47 PM copy" src="https://github.com/user-attachments/assets/bad64936-bae1-4846-8cde-12f6d1748d46" /> <img width="1301" alt="Screenshot 2
Original PR description
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state,…
When confirming a vendor bill imported from an uploaded document and pressing the "Update SAT" button, the SAT state is not updated. This commit adds the missing EDI document state, `invoice_received`, in a validation that triggers the update of the SAT state for the current invoice. Steps to reproduce: <img width="1301" alt="Screenshot 2025-02-13 at 11 23 47 PM copy" src="https://github.com/user-attachments/assets/bad64936-bae1-4846-8cde-12f6d1748d46" /> <img width="1301" alt="Screenshot 2025-02-13 at 11 24 12 PM copy" src="https://github.com/user-attachments/assets/b4a839c2-a5ab-4638-b46d-3eb9ccf1b59d" /> <img width="1307" alt="Screenshot 2025-02-13 at 11 26 30 PM copy" src="https://github.com/user-attachments/assets/14645d48-5e90-405c-8a36-3ec7b0af50ef" /> <img width="1306" alt="Screenshot 2025-02-13 at 11 26 47 PM copy" src="https://github.com/user-attachments/assets/839349bf-be83-408a-bbd4-676d84a34493" /> <img width="1305" alt="Screenshot 2025-02-13 at 11 26 57 PM copy" src="https://github.com/user-attachments/assets/1e3773de-f3ab-47b4-9548-b5633c078943" /> Actual result: <img width="1306" alt="Screenshot 2025-02-13 at 11 27 08 PM copy" src="https://github.com/user-attachments/assets/a385847e-20cc-4410-8802-6d6b2c363633" /> Expected result: <img width="1307" alt="Screenshot 2025-02-13 at 11 27 49 PM copy" src="https://github.com/user-attachments/assets/8974cd49-13b6-40c0-8fa2-fd1fce45faf3" /> Forward-Port-Of: odoo/enterprise#79443 Forward-Port-Of: odoo/enterprise#79314
This commit will do a backport of: https://github.com/odoo/enterprise/commit/eaf8361f44208346c20e4c50c2d9914ab2d4f3f5 and also remove some margin to have a more compacted view and will put most of the information in one div. task:4542756 Forward-Port-Of: odoo/enterprise#79233
Original PR description
This commit will do a backport of: https://github.com/odoo/enterprise/commit/eaf8361f44208346c20e4c50c2d9914ab2d4f3f5 and also remove some margin to have a more compacted view and will put most of the information in one div. task:4542756 Forward-Port-Of: odoo/enterprise#79233
Steps to reproduce: 1. Add a embedded view in Knowledge, like a kanban view. 2. Add a new favorite filter. 3. The shared checkbox is shown. To address this issue, we need to use the `.context` since in owl the `._context` is giving inconsistent results, this due to how the rendering is being done, we sometimes will try to access the context before it is actually set, and we'll get a null value. With the `.context` we are sure that the context is set and we can access the `knowledgeEmb
Original PR description
Steps to reproduce: 1. Add a embedded view in Knowledge, like a kanban view. 2. Add a new favorite filter. 3. The shared checkbox is shown. To address this issue, we need to use the `.context` since in owl the `._context` is giving inconsistent results, this due to how the rendering is being done, we sometimes will try to access the context before it is actually set, and we'll get a null value. With the `.context` we are sure that the context is set and we can access the `knowledgeEmbeddedViewId` properly. opw Forward-Port-Of: odoo/enterprise#80287
Community PR: https://github.com/odoo/odoo/pull/187536 Add support for the Tyro payment terminal (AU/NZ). The integration uses their iClient JS library, and all communication is done via their API and not with the terminal locally. Some behaviour is modified when using the Tyro payment method in order to comply with their certification: - Orders cannot be cancelled if they are partially paid - You cannot navigate away from the payment screen while a Tyro payment is in progress - Spe
Original PR description
Community PR: https://github.com/odoo/odoo/pull/187536 Add support for the Tyro payment terminal (AU/NZ). The integration uses their iClient JS library, and all communication is done via their API and not with the terminal locally. Some behaviour is modified when using the Tyro payment method in order to comply with their certification: - Orders cannot be cancelled if they are partially paid - You cannot navigate away from the payment screen while a Tyro payment is in progress - Specific payment lines can be chosen when refunding an order task-4086116 Forward-Port-Of: odoo/enterprise#79432
Update the official numbers of the Luxembourg payroll rules for 2025. task-4577491 Forward-Port-Of: odoo/enterprise#79805
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. task-4577491 Forward-Port-Of: odoo/enterprise#79805
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be batched later, in each branch. 4. Selecting both branches and the parent company, create a batch payment with both payments. 5. The error "All payments in the batch must belong to the same company." is raised. **Desired behavior:** The payments in different companies that are branches of a commo
Original PR description
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be…
**To reproduce:** 1. Create two branches within a company. 2. Set a bank account linked to the journal defined in the parent company 3. Create one payment, such as a SEPA payment or check, to be batched later, in each branch. 4. Selecting both branches and the parent company, create a batch payment with both payments. 5. The error "All payments in the batch must belong to the same company." is raised. **Desired behavior:** The payments in different companies that are branches of a common head office should not trigger the error. They should be allowed to be batched. **Cause:** The function `_check_payments_constrains()` in account_batch_payments raises an error if more than one company_id is present in the payments being batched. **Solution:** Change the check in `_check_payments_constrains()` to raise an error only if more than one root_id for the companies in the payments is present. This way, payments from several companies, branches of the same head office, can be batched. Payments from companies that do not share the same root_id, however, still raise an error when attempting to batch them. task-4568317 Forward-Port-Of: odoo/enterprise#80285 Forward-Port-Of: odoo/enterprise#79359
Steps to reproduce: 1) Configure 2 rental products (product1 and product2) 2) Add at least 1 pricing period to product2 3) Set product2 as accessory product to product1 4) Go to /shop page and add product1 5) Go to the cart and observe the broken layout of suggested accessories opw-4463981 Forward-Port-Of: odoo/enterprise#80385
Original PR description
Steps to reproduce:
1) Configure 2 rental products (product1 and product2)
2) Add at least 1 pricing period to product2
3) Set product2 as accessory product to product1
4) Go to /shop page and add product1
5) Go to the cart and observe the broken layout of suggested
accessories
opw-4463981
Forward-Port-Of: odoo/enterprise#80385Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#80279 Forward-Port-Of: odoo/enterprise#78530
Original PR description
Add a default field for each analytic plans when exporting journal items from list view task-4378083 Forward-Port-Of: odoo/enterprise#80279 Forward-Port-Of: odoo/enterprise#78530
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80346 Forward-Port-Of: odoo/enterprise#80052
Original PR description
When your spouse has no income or low income, you can benefit from withholding taxes reduction. Before this commit, only the case where the spouse had no income was implemented. This PR includes the case where the spouse has low income to also benefit for the withholding taxe reduction. task-4582221 Forward-Port-Of: odoo/enterprise#80346 Forward-Port-Of: odoo/enterprise#80052
It's very difficult to find folders when they are returned in an arbitrary order. Furthermore, as we've removed the sequence field in 18.0, users have no way to change the ordering of these folders. With this change, users with many folders will at least be able to do something until re-ordering by sequence is made possible again in 18.2 Task-4512349 Forward-Port-Of: odoo/enterprise#80386
Original PR description
It's very difficult to find folders when they are returned in an arbitrary order. Furthermore, as we've removed the sequence field in 18.0, users have no way to change the ordering of these folders. With this change, users with many folders will at least be able to do something until re-ordering by sequence is made possible again in 18.2 Task-4512349 Forward-Port-Of: odoo/enterprise#80386
This PR fixes two small visual issues, both related to the redesign of the Barcode app: - The "Sign" button was not updated when the Barcode app was redesigned; Before / After:  ![dev localhost_8069_odoo_barcode_action-303_2_barcode-operations_6_action-307_debug=assets(iPhone SE) (1)](https://github.com/user-attachments/assets/c73d8519-2af2-4d53-b337-7392db
Original PR description
This PR fixes two small visual issues, both related to the redesign of the Barcode app: - The "Sign" button was not updated when the Barcode app was redesigned; Before / After:   - The `expiration_date` field design wasn't updated when the Barcode app design was, so it was off regarding the other fields. Before / After:   [OPW-4609284](https://www.odoo.com/odoo/project.task/4609284) Community PR: odoo/odoo#199554 Forward-Port-Of: odoo/enterprise#80338
### Issue: The test `test_add_component_from_shop_foor` fails the first step of the tour if run without demo data's since the user admin does not belong to the group `mrp.group_mrp_routing`. With demo data it is automatically added to the default via these lines: https://github.com/odoo/odoo/blob/42b43bad2978d6f809f9210753e2e4d06e00d436/addons/mrp/data/mrp_demo.xml#L9-L12 runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/116698 Forward-Port-Of: odoo/enterprise#80265
Original PR description
### Issue: The test `test_add_component_from_shop_foor` fails the first step of the tour if run without demo data's since the user admin does not belong to the group `mrp.group_mrp_routing`. With demo data it is automatically added to the default via these lines: https://github.com/odoo/odoo/blob/42b43bad2978d6f809f9210753e2e4d06e00d436/addons/mrp/data/mrp_demo.xml#L9-L12 runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/116698 Forward-Port-Of: odoo/enterprise#80265
Sometimes, when opening the documents folder, folders were not being completely loaded, which gave errors. This fix checks if the folders are properly loaded on the page and only then lets tours continue. Runbot build errors [1](https://runbot.odoo.com/odoo/action-573/109605), [2](https://runbot.odoo.com/odoo/action-573/109607), [3](https://runbot.odoo.com/odoo/action-573/113711), [4](https://runbot.odoo.com/odoo/action-573/113712) Forward-Port-Of: odoo/enterprise#79588
Original PR description
Sometimes, when opening the documents folder, folders were not being completely loaded, which gave errors. This fix checks if the folders are properly loaded on the page and only then lets tours continue. Runbot build errors [1](https://runbot.odoo.com/odoo/action-573/109605), [2](https://runbot.odoo.com/odoo/action-573/109607), [3](https://runbot.odoo.com/odoo/action-573/113711), [4](https://runbot.odoo.com/odoo/action-573/113712) Forward-Port-Of: odoo/enterprise#79588
Currently a `ParseError` arises when the user installs the `helpdesk` module after deleting `Your Odoo Periodic Digest` from the `Digest Emails` in Settings. Steps to reproduce: --- - Install `digest` module (without demo data) - Settings > Technical > Email > Digest Emails > Delete `Your Odoo Periodic Digest` - Now install `helpdesk` module Traceback: --- ``` Exception: Cannot update missing record 'digest.digest_digest_default' ParseError: while parsing /home/odoo/src/enterpris
Original PR description
Currently a `ParseError` arises when the user installs the `helpdesk` module after deleting `Your Odoo Periodic Digest` from the `Digest Emails` in Settings. Steps to reproduce: --- - Install…
Currently a `ParseError` arises when the user installs the `helpdesk` module after deleting `Your Odoo Periodic Digest` from the `Digest Emails` in Settings.
Steps to reproduce:
---
- Install `digest` module (without demo data)
- Settings > Technical > Email > Digest Emails > Delete `Your Odoo Periodic Digest`
- Now install `helpdesk` module
Traceback:
---
```
Exception: Cannot update missing record 'digest.digest_digest_default'
ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/helpdesk/data/digest_data.xml:4, somewhere inside <record id="digest.digest_digest_default" model="digest.digest">
<field name="kpi_helpdesk_tickets_closed">True</field>
</record>
```
The error occurs because the user deleted `Your Odoo Periodic Digest` and then installed the `helpdesk` module. which requires a particular record.
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366
sentry-5731062091
Forward-Port-Of: odoo/enterprise#79676After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv
Original PR description
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that…
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file. Meanwhile, the style management was refactored a bit to make it simpler. [opw-4501822](https://www.odoo.com/odoo/project.task/4501822) [opw-4458752](https://www.odoo.com/odoo/project.task/4458752) [indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497 Forward-Port-Of: odoo/enterprise#79855 Forward-Port-Of: odoo/enterprise#77510