Monday, March 31, 2025
45 changes · saas-18.2
Resolved issues and error corrections
Product rating information is now left out of SEO data when ratings are turned off for the online store. This prevents search engines from seeing or displaying rating details that are not enabled on the website, keeping public product information consistent with store settings.
Spreadsheet pivot tables now show the actual field name when a measure cannot use an aggregator. This replaces an unhelpful technical placeholder with a clearer message, making it easier for users to understand and correct the issue.
Original PR description
The error message displayed when the measure was on a field with no aggregator was generated was wrong. It was generated with a stringified object `[object Object]` instead of the field name. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when saving an attendance record that has no check-in time. It helps HR users complete or correct attendance entries without encountering a system traceback.
Original PR description
When user tries to create an attendance without check in, A traceback will appear. Steps to reproduce the error: - Go to Attendances > Create a new attendance - Remove Check In time > Save & Close…
When user tries to create an attendance without check in,
A traceback will appear.
Steps to reproduce the error:
- Go to Attendances > Create a new attendance
- Remove Check In time > Save & Close
Error:
```
File "/home/odoo/src/odoo/saas-18.2/addons/hr_attendance/models/hr_attendance.py", line 98, in _compute_overtime_hours
att: self._get_day_start_and_day(att.employee_id, att.check_in)
File "/home/odoo/src/odoo/saas-18.2/addons/hr_attendance/models/hr_attendance.py", line 268, in _get_day_start_and_day
if not dt.tzinfo:
AttributeError: 'bool' object has no attribute 'tzinfo'
```
When user creates attendance, ``_compute_overtime_hours`` method will be called. https://github.com/odoo/odoo/blob/74be92ad3b26c60ccb222492e5fb770174f95d11/addons/hr_attendance/models/hr_attendance.py#L95-L100
Here, ``_compute_overtime_hours`` method will call ``_get_day_start_and_day``
without checking ``check_in``.
So, It will lead to the above Traceback.
sentry-6452618270
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe expense search filter has been fixed after it stopped working following recent expense report changes. Users can once again find and filter expense records as expected, reducing friction in daily expense management.
Original PR description
The search filter was broken since the refactoring of expense reports. This was due to a wrong operator. task-4669889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a Gantt view test more stable by positioning the timeline item away from the screen edge before resizing it. This prevents unintended auto-scrolling during the test, reducing false failures without changing user-facing behavior.
Original PR description
Before this commit: The test consist in extending a pill using drag & drop mouse event. When the mouse drag too close from the side of the gantt view, it will automatically scroll the view to allow to extend to further invisible month = side scrolling This was the case here as the browser window in test mode is set to 1366 x 768 which was making the pill very close from the side of the window. When the mouse drop happen (after the drag) this could end up being on a another month that the expected one due to the automatic side-scroll.  After this commit: We initially scroll the gantt view so that the pill is centered to avoid side-scrolling to trigger rb-145661
This update removes a duplicate access rights entry in the Belgian POS certification module. It helps prevent database upgrade problems while keeping the same permissions in place.
Original PR description
Before this commit, two access rights records had the same id in the ir.model.access.csv file. This caused issues when trying to upgrade a db from previous versions. As the two records had the same rights, we remove the one linked to the manager group.
The document details panel now displays fields with proper alignment. This improves the visual consistency of the Documents app and makes the panel easier to read for users.
Original PR description
**Before this fix:** https://tinyurl.com/2y5zluop **Technical:** The 'name' field in the documents became translatable(from commit https://github.com/odoo/enterprise/commit/9efa58c442e1892fef3fa5ce3901d697de22beaa), causing the 'o_field_translate' to be applied to the name input, including the padding style on the right. **After this fix:** Fields in the document details panel will be properly aligned for an enhanced UI. Task-4636414
This fixes a mistaken internal reference used by the Payroll Expense feature when checking payroll user access. It helps ensure the feature relies on the correct payroll permissions and avoids errors caused by looking in the wrong place.
Original PR description
Fix incorrect reference to `group_hr_payroll_user`, as it is defined in `hr_payroll`, not `hr_contract`.
Miscellaneous changes
…user Checking out while logged in with a portal user would cause all messages to be created by said portal user. So, when the invoice email would normally be sent it would not include the portal user as a recipient. Accessing the transaction as the superuser instead of just using superuser when running _generate_and_send_invoices fixes this because the invoices were being grabbed with the env.user of portal user and that was being used later down the line as the user to create the message
Original PR description
…user Checking out while logged in with a portal user would cause all messages to be created by said portal user. So, when the invoice email would normally be sent it would not include the portal user as a recipient. Accessing the transaction as the superuser instead of just using superuser when running _generate_and_send_invoices fixes this because the invoices were being grabbed with the env.user of portal user and that was being used later down the line as the user to create the messages. opw-4566071 Forward-Port-Of: odoo/odoo#203187
Changing the template of marketing card will not mark the existing card "to update", leading to wrong template used. Steps: - Open marketing card - Open Employee Card - Ensure a template is selected (Center) - Click on Send - Click on "Update 128 cards" - Download a card (/cards/1/card.jpg) - Template is well "Center" - Change Sub-Header value - Click on Send - You can update 128 cards - Update them - Download a card (/cards/1/card.jpg) - Sub-Header is upd
Original PR description
Changing the template of marketing card will not mark the existing card "to update", leading to wrong template used. Steps: - Open marketing card - Open Employee Card - Ensure a template is selected…
Changing the template of marketing card will not mark the existing card "to update", leading to wrong template used.
Steps:
- Open marketing card
- Open Employee Card
- Ensure a template is selected (Center)
- Click on Send
- Click on "Update 128 cards"
- Download a card (/cards/1/card.jpg)
- Template is well "Center"
- Change Sub-Header value
- Click on Send
- You can update 128 cards
- Update them
- Download a card (/cards/1/card.jpg)
- Sub-Header is updated
- Template is still "Center"
- Change the template to "Drawing"
- Click on Send
Actual result:
- You can't update cards, require_sync field is false
- Download a card (/cards/1/card.jpg)
- Template is still "Center"
- Sending email will not update them
- https://github.com/odoo/odoo/blob/4970215142d11efedc5ddc1d82ef7d671e7f0eeb/addons/marketing_card/models/card_campaign.py##L180-L181
Expected result:
- You can update cards, require_sync field is true
- Card template should be considered as a render field
Forward-Port-Of: odoo/odoo#203049Changes in the ecommerce app broke this test starting 17.4. Minor changes for the most part, change of button appearance, flow redirection, etc. rb-102094 Forward-Port-Of: odoo/odoo#203494
Original PR description
Changes in the ecommerce app broke this test starting 17.4. Minor changes for the most part, change of button appearance, flow redirection, etc. rb-102094 Forward-Port-Of: odoo/odoo#203494
In Point of sale promotion program may be auto applied to the order whenever the conditions of the promotions are satisfied. However, a promo 'buy x get y' is auto applied inconsistently when comparing the output with the reward button (or applying the promotion on a sales order) Steps to reproduce: - Have a promo program like follows: - Program Type: Buy X Get Y - Condition: - Minimum quantity: 2 - Grant: 1 credit per order - Product: [PRODUCT] - Reward: - I
Original PR description
In Point of sale promotion program may be auto applied to the order whenever the conditions of the promotions are satisfied. However, a promo 'buy x get y' is auto applied inconsistently when…
In Point of sale promotion program may be auto applied to the order
whenever the conditions of the promotions are satisfied.
However, a promo 'buy x get y' is auto applied inconsistently when
comparing the output with the reward button (or applying the promotion on a sales
order)
Steps to reproduce:
- Have a promo program like follows:
- Program Type: Buy X Get Y
- Condition:
- Minimum quantity: 2
- Grant: 1 credit per order
- Product: [PRODUCT]
- Reward:
- In exchange of: 1 credit
- Product: [PRODUCT]
- Quantity rewarded: 1
- Open POS Session
- Add 2x [Product]
Issue:
- "Free" [PRODUCT] line is added to the order with negative price
So the customer will buy 1 [PRODUCT] and get 2 that is not what we want
with the promo program
If we delete the reward line, click on reward button and choose again
the same promo we get the correct behavior:
- Exisitng [PRODUCT] line quantity raised to 3
- "Free" [PRODUCT] line added to the order with negative price
opw-4563825
Forward-Port-Of: odoo/odoo#202499
Forward-Port-Of: odoo/odoo#199752By default, you cannot choose which third parties to block, you can just add to the default list. After this commit, you can use the 'magic key' `#ignore_default` to define your own list. Forward-Port-Of: odoo/odoo#201706
Original PR description
By default, you cannot choose which third parties to block, you can just add to the default list. After this commit, you can use the 'magic key' `#ignore_default` to define your own list. Forward-Port-Of: odoo/odoo#201706
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standa
Original PR description
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. opw-4167139 [Enterprise PR](https://github.com/odoo/enterprise/pull/73256) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191026 Forward-Port-Of: odoo/odoo#186079
Steps to reproduce: - Install manfacturing app - Activate the Unit of measure setting in the mrp settings - Go to create new manafcturing order and start zooming in with different screen resolutions Problem: The product_qty field starts disappearing on zooming in and this makes the user can't enter a value in it. This happens because the width:auto applied to the field of the uom beside it that takes as much space as possible so the product_qty field disappears. opw-4560205 Descr
Original PR description
Steps to reproduce: - Install manfacturing app - Activate the Unit of measure setting in the mrp settings - Go to create new manafcturing order and start zooming in with different screen resolutions…
Steps to reproduce: - Install manfacturing app - Activate the Unit of measure setting in the mrp settings - Go to create new manafcturing order and start zooming in with different screen resolutions Problem: The product_qty field starts disappearing on zooming in and this makes the user can't enter a value in it. This happens because the width:auto applied to the field of the uom beside it that takes as much space as possible so the product_qty field disappears. opw-4560205 Description of the issue/feature this PR addresses: Current behavior before PR: the product_qty field in the creating manufacturing order disappears while zooming in with different screen resolutions. Desired behavior after PR is merged: The product_qty field is appearing on all zoom levels from 100 to 400 and tested on all screen resolutions in the settings of display in Ubuntu **Before**:  **After**:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197734
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#203935
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203935
This update contains the following commits: [IMP] runtime/utils: export htmlEscape and add tests (https://github.com/odoo/owl/pull/1677) [FIX] utils: Correct validation of mount target in shadow DOM/iframe (https://github.com/odoo/owl/pull/1676) [IMP] runtime: add markup tag function (https://github.com/odoo/owl/pull/1670) Notes: https://github.com/odoo/owl/releases/tag/v2.7.0 Forward-Port-Of: odoo/odoo#203515
Original PR description
This update contains the following commits: [IMP] runtime/utils: export htmlEscape and add tests (https://github.com/odoo/owl/pull/1677) [FIX] utils: Correct validation of mount target in shadow DOM/iframe (https://github.com/odoo/owl/pull/1676) [IMP] runtime: add markup tag function (https://github.com/odoo/owl/pull/1670) Notes: https://github.com/odoo/owl/releases/tag/v2.7.0 Forward-Port-Of: odoo/odoo#203515
## Versions: 18.0 Reset feature from saas-17.4 ## Issue: In saas-17.4, the user could see the Purchase Order total amount in the selected company's currency if it differs from the PO's currency. This doesn't exist in 18 anymore. ## Steps to reproduce: Ensure there are at least 2 currencies available in the `Settings` app - Create a new purchase order; - Change the selected `Currency` for any other; - Look at the subtotal part that does not include the equivalent amount in the compan
Original PR description
## Versions: 18.0 Reset feature from saas-17.4 ## Issue: In saas-17.4, the user could see the Purchase Order total amount in the selected company's currency if it differs from the PO's currency. This doesn't exist in 18 anymore. ## Steps to reproduce: Ensure there are at least 2 currencies available in the `Settings` app - Create a new purchase order; - Change the selected `Currency` for any other; - Look at the subtotal part that does not include the equivalent amount in the company's currency. ## Cause: The saas-17.4 feature has not been forwarded entirely and an important part of it is missing. The company currency total amount is not updated correctly ## Fix: Forward-port the complete feature of https://github.com/odoo/odoo/commit/202af7c12a768005df3bd97f595ead0a4c4c02b9 Include the fix from https://github.com/odoo/odoo/pull/186464/commits/7467d68309c039c50e39b6ec0b8645ef7ff42ad4 opw-4416711 Forward-Port-Of: odoo/odoo#197618
Commit 0bdfda2af4d70a6c33773ecd4aaa717ef6a17d62 introduced a new behavior where delivery transfer to transit locations (inter companies transfer) could create a new Sale Order Line if necessary. However, we do not want this behavior if the transit location is just a step in the delivery to the Customer location. Hence, if there are any destination moves, we do not create a new sale order line. OPW-4643937 --- Test result without fix: ``` 2025-03-19 16:08:42,057 57047 ERROR oes_test
Original PR description
Commit 0bdfda2af4d70a6c33773ecd4aaa717ef6a17d62 introduced a new behavior where delivery transfer to transit locations (inter companies transfer) could create a new Sale Order Line if necessary.…
Commit 0bdfda2af4d70a6c33773ecd4aaa717ef6a17d62 introduced a new behavior where delivery transfer to transit locations (inter companies transfer) could create a new Sale Order Line if necessary. However, we do not want this behavior if the transit location is just a step in the delivery to the Customer location.
Hence, if there are any destination moves, we do not create a new sale order line.
OPW-4643937
---
Test result without fix:
```
2025-03-19 16:08:42,057 57047 ERROR oes_test_17.4 odoo.addons.sale_stock.tests.test_sale_stock: FAIL: TestSaleStock.test_custom_delivery_route_new_sale_line
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/saas-17.4/odoo/addons/sale_stock/tests/test_sale_stock.py", line 2197, in test_custom_delivery_route_new_sale_line
self.assertEqual(len(sale_order.order_line), 1)
AssertionError: 2 != 1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202880
Forward-Port-Of: odoo/odoo#202559Typically, the field commercial_partner_id on res.partner is not displayed on the Form view. However, adding it via Studio or other means will lead to an error if the following conditions are met. Issue We click New to start creating a new record (still in NewId phase) We trigger an onchange that will lead to invoice_edi_format being computed When clicking New the commercial_partner_id is computed initially. However, this value isn't present on the Form view yet which leaves the field empty
Original PR description
Typically, the field commercial_partner_id on res.partner is not displayed on the Form view. However, adding it via Studio or other means will lead to an error if the following conditions are met.…
Typically, the field commercial_partner_id on res.partner is not displayed on the Form view. However, adding it via Studio or other means will lead to an error if the following conditions are met. Issue We click New to start creating a new record (still in NewId phase) We trigger an onchange that will lead to invoice_edi_format being computed When clicking New the commercial_partner_id is computed initially. However, this value isn't present on the Form view yet which leaves the field empty until we actually save (and create) the record. Prior to this, if another onchange is called we'll pass commercial_partner_id as False in the onchange, eventually erroring out when we try to call a method on the value's record. Solution: After multiple fixes and refactor, it looks like dependencies on the compute are no longer relevant. Indeed, `_get_suggested_invoice_edi_format` only depends on the commercial partner's country code now. Also only compute the edi format if the commercial partner is set. opw-4630096 Forward-Port-Of: odoo/odoo#203944
In odoo/odoo/pull/175315, we added a new journal type: 'credit'. The `bank_statements_source` was meant to be required for credit journal the same way it is for bank journals. no-opw no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203677
Original PR description
In odoo/odoo/pull/175315, we added a new journal type: 'credit'. The `bank_statements_source` was meant to be required for credit journal the same way it is for bank journals. no-opw no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203677
The Error is reproducible in the runbot here is an attached video with the steps: https://drive.google.com/file/d/1W1ZJG7aYueFa8Y24LSZlsil0caZB9mE5/view?usp=sharing This happens because of : 1- cash rounding is enabled in the settings of accounting 2 - cash rounding by tax is chosen 3 - opening a vendor bill 4 - putting a decimal price and removing taxes 5- then choosing cash rounding by tax The Error : File "/home/odoo/odoo/odoo/addons/account/models/account_move.py", line 1570, in
Original PR description
The Error is reproducible in the runbot here is an attached video with the steps: https://drive.google.com/file/d/1W1ZJG7aYueFa8Y24LSZlsil0caZB9mE5/view?usp=sharing This happens because of : 1- cash rounding is enabled in the settings of accounting 2 - cash rounding by tax is chosen 3 - opening a vendor bill 4 - putting a decimal price and removing taxes 5- then choosing cash rounding by tax The Error : File "/home/odoo/odoo/odoo/addons/account/models/account_move.py", line 1570, in _compute_tax_totals move.tax_totals = self.env['account.tax']._get_tax_totals_summary( File "/home/odoo/odoo/odoo/addons/account/models/account_tax.py", line 2090, in _get_tax_totals_summary max_subtotal, max_tax_group = max( ValueError: max() arg is an empty sequence opw-4558251 (related to ticket) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Forward-Port-Of: odoo/odoo#203440
Forward-Port-Of: odoo/odoo#203874
Original PR description
Forward-Port-Of: odoo/odoo#203874
* follow markdown guidelines * add section for security reports --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203813 Forward-Port-Of: odoo/odoo#143761
Original PR description
* follow markdown guidelines * add section for security reports --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203813 Forward-Port-Of: odoo/odoo#143761
It's due to other module creating leaves on the 40h/week calendar. Since it's set on the workorder. During the productivity loss creation the duration could cost for 0 minutes if it's during the leave of a workcenter opw-moc 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#200545 Forward-Port
Original PR description
It's due to other module creating leaves on the 40h/week calendar. Since it's set on the workorder. During the productivity loss creation the duration could cost for 0 minutes if it's during the leave of a workcenter opw-moc 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#200545 Forward-Port-Of: odoo/odoo#197995
Steps to reproduce the bug: - Create two storable products, P1 and P2: - tracked by: lot - Valuated by: lot - Create a service product, S1: - is landed cost: True - value: $100 - Create a receipt: - unit of P1, unit price: $1 - unit of P2, unit price: $1 - Add the landed cost S1, split by quantity. Problem: The cost valuation of the products is then $51 each. The product form and valuation are displayed correctly. However, if we check the lot, th
Original PR description
Steps to reproduce the bug:
- Create two storable products, P1 and P2:
- tracked by: lot
- Valuated by: lot
- Create a service product, S1:
- is landed cost: True
- value: $100
- Create a receipt:
- unit of P1, unit price: $1
- unit of P2, unit price: $1
- Add the landed cost S1, split by quantity.
Problem:
The cost valuation of the products is then $51 each. The product form
and valuation are displayed correctly. However, if we check the lot,
the cost appears as $101.
This issue occurs because, when validating the landed cost, we have a
dictionary mapping lots to values. Then, we iterate over each product,
but we do not filter the lot dictionary for the current product.
Instead, we traverse the entire dictionary, leading to the lot values
being processed twice.
opw-[4509006](https://www.odoo.com/web#id=4509006&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#198777
Forward-Port-Of: odoo/odoo#197019In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing because of this multiple level snippet. (e.g: s_masonry_block > s_masonry_block_default_template > Block) Yet this middle level has no options on its own. so it was unnecessary to have an options section for the 'sub-snippets'. This commit just prevent to be able to select the 'sub-snippets'. Further
Original PR description
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing…
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing because of this multiple level snippet. (e.g: s_masonry_block > s_masonry_block_default_template > Block) Yet this middle level has no options on its own. so it was unnecessary to have an options section for the 'sub-snippets'. This commit just prevent to be able to select the 'sub-snippets'. Furthermore, due to those 'sub-snippets' being contained inside the s_masonry_block snippet, they would not get registered in the list of all the snippets, and then the website would failed to determine their version which raised the 'outdated_snippet' alert. Preventing the selection of those 'sub-snippet' thus also prevent the website checking their version. As of now none of these sub-snippets have different version than the basic s_masonry_block so I guess we can just ignore that since they are not designed to change from the basic s_masonry_block options. And if so should happen in the future they would probably become completely independant snippets. Steps to reproduce : - Enter edit mode - Drag and drop a s_masonry_block snippet - Select one of the blocks of the snippets - On the options panel an errored 'Block' option section appeared. - Click on 'access options anyway', the section is then empty. [1] : https://github.com/odoo/odoo/pull/183755 task-4508767 Forward-Port-Of: odoo/odoo#200690 Forward-Port-Of: odoo/odoo#195406
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first sy
Original PR description
Before this commit, customers were facing problems during the first synchronization related to the abundance of invitations sent through Outlook from previously created events in Odoo side. This should not happen because most of the time it is not useful synchronizing events that were already created before starting the synchronization with Outlook (from feedbacks discussed with customers and internally). After this commit, we no longer synchronize events that were created before the first synchronization of any user in a database if we don't find any token created in it (i.e. if no user synchronized its Odoo Calendar with Outlook before this improvement). In case of any user already have synchronized its calendar with Outlook, we won't change the synchronization behavior (since the biggest part of the invitations were already sent). task-4294884 Forward-Port-Of: odoo/odoo#203896 Forward-Port-Of: odoo/odoo#185911
Fix issue when trying to create new payment methods and no `account_journal_payment_debit_account_id` exist in the current chart template. Calling `_get_outstanding_account('inbound')` on an empty `account.payment` was failing because `self.env.company` was not properly set. This issue only occurred when the outstanding account was not found in the chart template, leading to an exception. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Fix issue when trying to create new payment methods and no `account_journal_payment_debit_account_id` exist in the current chart template.
Calling `_get_outstanding_account('inbound')` on an empty `account.payment` was failing because `self.env.company` was not properly set. This issue only occurred when the outstanding account was not found in the chart template, leading to an exception.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#203962Description 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#203567 Forward-Port-Of: odoo/odoo#203117
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203567 Forward-Port-Of: odoo/odoo#203117
Currently, An error occurs when creating a resource time off. Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Go to Time Off / Configuration / Time Off Types, And delete `Sick Time Off`. - Go to Settings / Technical / Resource / Resource Time Off, and create a new record. - Add a Time Off Request with the following conditions: The start date is before today's date, end date is after today's date, And state is set to Draft. - Try to save a Resource Time Off
Original PR description
Currently, An error occurs when creating a resource time off. Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Go to Time Off / Configuration / Time Off Types, And delete…
Currently, An error occurs when creating a resource time off. Step to produce: - Install the `hr_holidays` module. - Enable debug mode. - Go to Time Off / Configuration / Time Off Types, And delete `Sick Time Off`. - Go to Settings / Technical / Resource / Resource Time Off, and create a new record. - Add a Time Off Request with the following conditions: The start date is before today's date, end date is after today's date, And state is set to Draft. - Try to save a Resource Time Off record. `ValueError: External ID not found in the system: hr_holidays.holiday_status_sl` An error occurs when the system tries to retrieve an external ID of the 'Sick Time Off' at [1], but it is not available. Link [1]: https://github.com/odoo/odoo/blob/1303193386665d120ccb5d0045ee984337af0826/addons/hr_holidays/models/resource.py#L67 To handle this issue, add 'raise_if_not_found=False' in ref() argument if the external ID of the 'Sick Time Off' is not available. Sentry-6320807644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199236
An error occurs when updating the **Allocation** field in a time-off allocation record that does not have an assigned employee. **Steps to reproduce:** - Install the `hr_holidays` module. - Navigate to `Time Off > Management > Allocations` (form view). - Remove the employee and modify the **Allocation** field. - Observe the error. **Error:** KeyError - False The issue occurs because `_compute_number_of_hours_display` depends on `employee_id._get_hours_per_day(allocation.date_from)`
Original PR description
An error occurs when updating the **Allocation** field in a time-off allocation record that does not have an assigned employee. **Steps to reproduce:** - Install the `hr_holidays` module. - Navigate to `Time Off > Management > Allocations` (form view). - Remove the employee and modify the **Allocation** field. - Observe the error. **Error:** KeyError - False The issue occurs because `_compute_number_of_hours_display` depends on `employee_id._get_hours_per_day(allocation.date_from)`, when `employee_id` is empty, attempting to access `self.id` at [1] results in a key error. [1] - https://github.com/odoo/odoo/blob/51097d978a698fa94d021ca72bcd69c24d9c768b/addons/hr_holidays/models/hr_employee.py#L349 This commit ensures that the computation of `number_of_hours_display` checks if `employee_id` exists before proceeding. If no employee is assigned, it will be skipped. Sentry - 6423050142 Forward-Port-Of: odoo/odoo#202637
Currently, an error can occur in `_find_matching_po_and_inv_lines` when some invoice lines have a price_unit of 0. This happens because the matching logic sorts and matches lines by `(price_unit, qty)`, leading to "Journal Items" (`line_ids`) being incorrectly matched with purchase order lines. The issue arises because the `_find_matching_po_and_inv_lines` function checks all `line_ids`, instead of only `invoice_line_ids`. When a PO line has a price_unit of 0, it might match with a line that
Original PR description
Currently, an error can occur in `_find_matching_po_and_inv_lines` when some invoice lines have a price_unit of 0. This happens because the matching logic sorts and matches lines by `(price_unit,…
Currently, an error can occur in `_find_matching_po_and_inv_lines` when some invoice lines have a price_unit of 0. This happens because the matching logic sorts and matches lines by `(price_unit, qty)`, leading to "Journal Items" (`line_ids`) being incorrectly matched with purchase order lines. The issue arises because the `_find_matching_po_and_inv_lines` function checks all `line_ids`, instead of only `invoice_line_ids`. When a PO line has a price_unit of 0, it might match with a line that isn't an actual invoice line. As a result, `unmatched_lines` becomes incorrect, and it could remove a valid invoice line. Then, later, when calculating `inv_and_po_lines`, the process only considers `invoice_line_ids`. Since no matching line is found, an error occurs when attempting to delete the line (id is False). Steps to reproduce: 1. Create a purchase order with: - 1 product A with price_unit = 0 2. Confirm the purchase order. 3. Upload an EDI XML bill (e.g., IT localization) with: - A reference to the purchase order - 1 product B with price_unit = 100 Since all bill lines are processed, a tax line or a payment term line might incorrectly match with the PO line, causing the error. opw-4513869 Forward-Port-Of: odoo/odoo#204022 Forward-Port-Of: odoo/odoo#197637
Forward-Port-Of: odoo/enterprise#82441 Forward-Port-Of: odoo/enterprise#82412
Original PR description
Forward-Port-Of: odoo/enterprise#82441 Forward-Port-Of: odoo/enterprise#82412
Steps to reproduce ================== 1. Go to appointment 2. Pick an appointment having bookings > 1 3. Go to the list view of bookings. 4. Multi edit the capacity_reserved --> Traceback Issue ===== In the inverse function for capacity_reserved, we used self to access resource_total_capacity_reserved. Use event of self to access the attribute. Task- 4680286 Forward-Port-Of: odoo/enterprise#82405
Original PR description
Steps to reproduce ================== 1. Go to appointment 2. Pick an appointment having bookings > 1 3. Go to the list view of bookings. 4. Multi edit the capacity_reserved --> Traceback Issue ===== In the inverse function for capacity_reserved, we used self to access resource_total_capacity_reserved. Use event of self to access the attribute. Task- 4680286 Forward-Port-Of: odoo/enterprise#82405
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests) When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is
Original PR description
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests)
When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations.
This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. We also adapt some tests to the new behavior in enterprise.
opw-4167139
[community PR](https://github.com/odoo/odoo/pull/186079)
Forward-Port-Of: odoo/enterprise#75834
Forward-Port-Of: odoo/enterprise#73256…putation To allow people with low gross wages to take mobility budget, we allow iterative computation to reduce it until minimum gross wage is obtained task-4647060 Forward-Port-Of: odoo/enterprise#81336
Original PR description
…putation To allow people with low gross wages to take mobility budget, we allow iterative computation to reduce it until minimum gross wage is obtained task-4647060 Forward-Port-Of: odoo/enterprise#81336
When scanning a package, its content is added on the view, but we don't display the expiration date. To reproduce the issue: 1. In Settings, enable: - Packages - Expiration dates 2. Create a product - Tracked by lot - Expiration date 3. Update its quantity - Lot L - Package P - Quantity > 0 4. Set an expiration date on L 5. Open a new delivery through the barcode app 6. Scan P "Error": a line is added for the product, with its lot L, but we don't display
Original PR description
When scanning a package, its content is added on the view, but we don't display the expiration date. To reproduce the issue: 1. In Settings, enable: - Packages - Expiration dates 2. Create a product - Tracked by lot - Expiration date 3. Update its quantity - Lot L - Package P - Quantity > 0 4. Set an expiration date on L 5. Open a new delivery through the barcode app 6. Scan P "Error": a line is added for the product, with its lot L, but we don't display the expiration date. Once the line is saved (for instance, through the edit button), we will finally display it. This is because we don't provide any information about the expiration date when converting the package quant into relevant data. OPW-4516410 Forward-Port-Of: odoo/enterprise#81825
- Adding Libro Diario as a standalone report type. - Adding Libro de Inventario y Balance as a subtype of Balance Sheet report. task-4483080 Forward-Port-Of: odoo/enterprise#82322 Forward-Port-Of: odoo/enterprise#77857
Original PR description
- Adding Libro Diario as a standalone report type. - Adding Libro de Inventario y Balance as a subtype of Balance Sheet report. task-4483080 Forward-Port-Of: odoo/enterprise#82322 Forward-Port-Of: odoo/enterprise#77857
Forward-Port-Of: odoo/enterprise#82398
Original PR description
Forward-Port-Of: odoo/enterprise#82398
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN.
Original PR description
Certain reports were incorrectly referring to DIAN, even though the Industry and Commerce Tax (ICA) is administered at the district level. According to Colombian regulations (e.g., Decree 807 of 1993, Agreement 65 of 2002 for Bogotá), the collection and administration of ICA falls under the local Secretariat of Finance, not DIAN. This commit adds logic so that if the report is for ICA, it shows the correct reference to the Secretariat of Finance; otherwise, it preserves the reference to DIAN. Forward-Port-Of: odoo/enterprise#82218 Forward-Port-Of: odoo/enterprise#79630
This commit adds the possibility to access multiple attachment inside the salary rule while having the total amount of the recordset if amount is access directly task-4640076 Forward-Port-Of: odoo/enterprise#82226
Original PR description
This commit adds the possibility to access multiple attachment inside the salary rule while having the total amount of the recordset if amount is access directly task-4640076 Forward-Port-Of: odoo/enterprise#82226
Versions -------- - 18.0+ Steps ----- 1. Have purchase & sale_stock_renting installed; 2. create a 2nd company; 3. enable inter-company transactions for Sale/Purchase Orders for both; 4. enable Warehouse storage locations; 5. enable multi-step routes; 5. enable dropshipping; 6. enable rental transfers; 7. create a dropshipping route assigned to the 1st company; 8. create a purchasable, rental product, tracked by quantity; 9. add dropship route to its operations; 10. add 2nd comp
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have purchase & sale_stock_renting installed; 2. create a 2nd company; 3. enable inter-company transactions for Sale/Purchase Orders for both; 4. enable…
Versions -------- - 18.0+ Steps ----- 1. Have purchase & sale_stock_renting installed; 2. create a 2nd company; 3. enable inter-company transactions for Sale/Purchase Orders for both; 4. enable Warehouse storage locations; 5. enable multi-step routes; 5. enable dropshipping; 6. enable rental transfers; 7. create a dropshipping route assigned to the 1st company; 8. create a purchasable, rental product, tracked by quantity; 9. add dropship route to its operations; 10. add 2nd company as vendor; 11. create a rental order with the product; 12. confirm the rental order; 13. go to the generated purchase order via the smart button; 14. confirm the purchase order; 15. switch to the 2nd company; 16. try to open the generated sale order. Issue ----- > TypeError: '>' not supported between instances of 'datetime.datetime' and 'bool' Cause ----- On confirming the purchase order, the sale order it generates gets created as a rental order, due to the `in_rental_app` context value being set. When trying to open the rental order, it attempts to compute the quantity available for the tracked rental products during the rental period. The rental order was generated based on purchase order data, which lacks any kind of rental information, hence the rental order doesn't have a rental period set. The lack of rental dates is what causes the error when trying to partition the lines based on rental period. Solution -------- When creating a sale order via a purchase order, pass the `in_rental_app=False` context value to ensure it won't be created as a rental order. opw-4583210 Forward-Port-Of: odoo/enterprise#82220
Currently, a traceback occurs when the user tries to create a Export to Group S report. To reproduce this issue: 1) Install `l10n_be_hr_payroll_group_s` without demo data 2) Shift to the Belgium company 3) Create a running contract from payroll with stating date should be in past 4) Now create a Work Entry from payroll with the From date also be in the past 5) Now create a new `Export to Group S report` report from payroll/reporting 6) Make sure the date and moth are also in the pas
Original PR description
Currently, a traceback occurs when the user tries to create a Export to Group S report. To reproduce this issue: 1) Install `l10n_be_hr_payroll_group_s` without demo data 2) Shift to the Belgium…
Currently, a traceback occurs when the user tries to create a Export to Group S report. To reproduce this issue: 1) Install `l10n_be_hr_payroll_group_s` without demo data 2) Shift to the Belgium company 3) Create a running contract from payroll with stating date should be in past 4) Now create a Work Entry from payroll with the From date also be in the past 5) Now create a new `Export to Group S report` report from payroll/reporting 6) Make sure the date and moth are also in the past and click the `Populate` 7) Now click the `Generate Export File` Error:- ``` TypeError: can only concatenate str (not "bool") to str ``` The error is occurring because there is no `group_s_code` value by default in the company. The user has to give the value from the settings. If there is no `group_s_code` in the company, It leads to the above exception when concatenation is done between False and a string. Also, a userError was already raised from the very next life. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/l10n_be_hr_payroll_group_s/models/hr_payroll_export_group_s.py#L41-L43 So by making an extra check of the presence of the `group_s_code` in the company. We can resolve this issue and also make the code more robust. sentry-6289053708 Forward-Port-Of: odoo/enterprise#79334
When accountant is not installed, valid_payment_states includes both "paid" and "in payment" options, which means that amount_residual and amount_residual_currency have the same value as amount. original commit for the test: https://github.com/odoo/enterprise/commit/8faa7fccd296aab290f96b05832f1152cc2d4b1c [runbot-errors](https://runbot.odoo.com/odoo/error/161370) Forward-Port-Of: odoo/enterprise#82158
Original PR description
When accountant is not installed, valid_payment_states includes both "paid" and "in payment" options, which means that amount_residual and amount_residual_currency have the same value as amount. original commit for the test: https://github.com/odoo/enterprise/commit/8faa7fccd296aab290f96b05832f1152cc2d4b1c [runbot-errors](https://runbot.odoo.com/odoo/error/161370) Forward-Port-Of: odoo/enterprise#82158