Tuesday, February 18, 2025
30 changes · saas-18.1
Enhancements to existing features
The connection dialog for the POSBox homepage now shows two simpler steps for connecting to a database. This makes setup easier to understand and reduces confusion for users during configuration.
Original PR description
Inside the dialog used to connect to a database, the instruction were confusing. They have been simplified to 2 basic instructions, easy to follow. Task: 4585446 
The live chat widget now marks the page when the chat button is visible to visitors. This small improvement makes it easier to adapt styling or behavior based on whether chat is available, without changing the visitor experience.
Original PR description
This PR introduces a class on the livechat-root element when livechat button is displayed to the visitor. task-4567743
WhatsApp conversations will no longer show an unnecessary system message when a chatbot leaves the chat. This keeps customer conversation histories clearer and reduces noise for agents reviewing or continuing the discussion.
Original PR description
task-4410808 community: https://github.com/odoo/odoo/pull/197583
Resolved issues and error corrections
This fixes an issue where website visitors could incorrectly see an offline banner in live chat. It improves the chat experience by showing the banner only when appropriate and simplifies the related interface logic to reduce flicker.
Original PR description
Before this PR, the visitor offline banner could be shown to the visitor. The condition used to determine whether the banner should be shown is incorrect (it compares channel member to persona). At the same time, this PR cleans the thread component patch: the component relies on the `useEffect` hook to update a state based on the persona im status. The only purpose of this method is to delay the update in the UI to avoid flicker during quick disconnects. However, a debounce is already in place in the persona model. Other places in the UI might be impacted by the same flickers, so we better increase de debounce delay directly in the model setter. It also remove the need for complex code in the component. 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
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#197030 Forward-Port-Of: odoo/odoo#190196
Original PR description
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#197030 Forward-Port-Of: odoo/odoo#190196
The collapsed call sidebar now displays participant status icons correctly aligned with avatars. This small visual fix makes the call participant list clearer and more polished for users.
Original PR description
Before this commit the short status icon shown in the collapsed sidebar call participants was misaligned to the avatar. This was due to the margin being applied only on the avatar. This commit fixes the issue by: - Applying the margin to the element containing both the avatar and the short status icon. - Removing margin on the icon. | Before | After | |--------|--------| |  |  |
Installing the appointment payment module no longer fails if the default Services product category was previously deleted. This helps businesses avoid setup interruptions when enabling appointment payments in customized invoicing environments.
Original PR description
Currently a `ParseError` arises when the user installs the `appointment_account_payment` module after deleting the `Service` category in `Invoicing`. Steps to reproduce: --- - Install `Invoicing`…
Currently a `ParseError` arises when the user installs the `appointment_account_payment` module after deleting the `Service` category in `Invoicing`.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data)
- Invoicing > Configuration > Categories > Delete `Services`
- Now install `appointment_account_payment` module
Traceback:
---
```
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/appointment_account_payment/data/product_data.xml:3, somewhere inside <record id="default_booking_product" model="product.product">
<field name="name">Booking Fees</field>
<field name="standard_price">0.00</field>
<field name="uom_id" ref="uom.product_uom_unit"/>
<field name="list_price">50.00</field>
<field name="type">service</field>
<field name="purchase_ok" eval="False"/>
<field name="categ_id" ref="product.product_category_services"/>
<field name="image_1920" type="base64" file="appointment_account_payment/static/src/img/booking_product.png"/>
</record>
```
The error occurs because the user deleted the category and then installed the `appointment_account_payment` module, which references the missing product category.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6298992760The lock date wizard now shows the hard lock date warning across the full width of the form instead of squeezing it into a narrow label area. This improves readability and helps users notice important accounting lock date information.
Original PR description
The items inside the wizard view are ordered as a 2 column grid of labels and contents. But recently, it is found that the hard lock date alert item is only displayed in the short label section of the grid. This commit spans the hard lock date `div`'s `colspan` to 2 to make sure it spans on the whole line. for more info:  task-4586675
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
Original PR description
This commit comes as an apology for the horrible code I wrote in PR #166043 in order for the installation of `l10n_hu_edi` to not fail if some of the default Hungarian taxes (defined in `l10n_hu`) had been deleted. Instead of rolling back the loading of the EDI-specific fields if some taxes don't exist, we can just load those fields on the taxes that do exist. Which is a lot cleaner and simpler. Sorry again! task-none Forward-Port-Of: odoo/odoo#196471
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197803
Original PR description
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197803
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
Original PR description
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
Fixed inconsistent rounding of quantities displayed on the order button and table diff counters in the floor plan. **Steps to reproduce the issue:** 1. Add an orderline by clicking on a product. 2. Set the quantity to "2". 3. Click "Order". 4. Click "." and then "2" to adjust the quantity. 5. We can observe really long quantity (not rounded like `0.20000000000000018` instead of `0.2`) **Changes:** - Added `roundQuantity` utility to ensure consistent rounding to 2 decimals. - Applied
Original PR description
Fixed inconsistent rounding of quantities displayed on the order button and table diff counters in the floor plan. **Steps to reproduce the issue:** 1. Add an orderline by clicking on a product. 2. Set the quantity to "2". 3. Click "Order". 4. Click "." and then "2" to adjust the quantity. 5. We can observe really long quantity (not rounded like `0.20000000000000018` instead of `0.2`) **Changes:** - Added `roundQuantity` utility to ensure consistent rounding to 2 decimals. - Applied `roundQuantity` to table diff counters (on floorplan) and order category counters (on the order button inside ProductScreen) . task-id: 4488523 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#197394 Forward-Port-Of: odoo/odoo#194422
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---17.0-esoriginlength-jco I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187439 Forward-Port-Of: odoo/odoo#187332
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---17.0-esoriginlength-jco I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187439 Forward-Port-Of: odoo/odoo#187332
Steps to Reproduce: - Assign a partner a default payment method (e.g., Cash). - In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then save. The Issue: After saving, the journal field chosen by the user is overridden by the partner's default payment method. Cause: In `account_payment`, the method `_inverse_partner_id` controls the logic to display the default payment method (`journal_id`) for a partner. It also had `@
Original PR description
Steps to Reproduce: - Assign a partner a default payment method (e.g., Cash). - In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then…
Steps to Reproduce:
- Assign a partner a default payment method (e.g., Cash).
- In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then save.
The Issue:
After saving, the journal field chosen by the user is overridden by the partner's default payment method.
Cause:
In `account_payment`, the method `_inverse_partner_id` controls the logic to display the default payment method (`journal_id`) for a partner. It also had `@api.onchange('partner_id')` to adjust the `journal_id` in case the user changes the partner ID in the view. However, the inverse method is triggered on a save because `partner_id` is in `vals_list` of `write`, which sets the default `journal_id` instead of the user input.
Solution:
The behavior of the inverse method can be handled instead by the compute of `journal_id` if it depends on `partner_id`.
opw-4478282
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194490When adding/using point in ewallet program, the loyalty history was not updated correctly. Steps to reproduce: ------------------- * Create a new ewallet program * Create an ewallet card for customer C * Add some points to the ewallet card * Open PoS and make an order that you pay with the ewallet card * Check the history of the ewallet card > Observation: The transaction made in the PoS does not appear Why the fix: ------------ The required data are already present in `couponData
Original PR description
When adding/using point in ewallet program, the loyalty history was not updated correctly. Steps to reproduce: ------------------- * Create a new ewallet program * Create an ewallet card for customer C * Add some points to the ewallet card * Open PoS and make an order that you pay with the ewallet card * Check the history of the ewallet card > Observation: The transaction made in the PoS does not appear Why the fix: ------------ The required data are already present in `couponData` so we should use it instead of computing it. Also the method `getLoyaltyPoints` is not returning the points for ewallet program so it should not be used in this case. opw-4546985 Forward-Port-Of: odoo/odoo#197765
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/o
Original PR description
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/odoo#197141
When an invoice is created, the system will automatically translate the strings into the customer language: - In the backend the user will see the original product name and the label composed by translated name and translated description. - In the printed pdf the customer will see just the translated label However if the user modify the label in the backend, it will be saved prepending the original product name Steps to reproduce: - Have a user using a language [LANG1] - Have a cust
Original PR description
When an invoice is created, the system will automatically translate the strings into the customer language: - In the backend the user will see the original product name and the label composed by translated name and translated description. - In the printed pdf the customer will see just the translated label However if the user modify the label in the backend, it will be saved prepending the original product name Steps to reproduce: - Have a user using a language [LANG1] - Have a customer using a language [LANG2] - Make an invoice to the customer, add a product with both name and description with translation available - Make a small change to the product label - Save - Print Issue: The name of the product is duplicated, it appears in user language and customer language opw-4444773 Forward-Port-Of: odoo/odoo#197788
Instead of directly notify the invoices link to the transaction in _log_message_on_linked_documents, the invoice return by _get_invoices_to_notify are notified. It allow other modules to exclude some invoice --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197393
Original PR description
Instead of directly notify the invoices link to the transaction in _log_message_on_linked_documents, the invoice return by _get_invoices_to_notify are notified. It allow other modules to exclude some invoice --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197393
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I
Original PR description
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197281
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package. ### Steps to reproduce (issue in barcode): - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable product - Update the on hand quantity: - 10 units in package PK in WH/STOCK - Inventory > Configuration > Warehouse Management > L
Original PR description
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive…
### Issue:
The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package.
### Steps to reproduce (issue in barcode):
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable product
- Update the on hand quantity:
- 10 units in package PK in WH/STOCK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans: i. Scan the internal transfer picking type ii. Scan WH/STOCK as a source location iii. Scan the package name (PK) iv. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Validate the picking
- Proceed an other picking via the barcode app to follow up: i. Scan the internal transfer picking type ii. Scan WH/LOC2 as a source location iii. Scan the package name (PK)
#### > the package is not found and added. You rather trigger a notification: no package You are expected to scan one or more products or a package available at the picking location
### Cause of the issue:
After the picking validation, the location_id of the package should havebeen updated to WH/LOC2 but it is still WH/Stock since you have a reserved quantity on that quant and it was not cleaned:
https://github.com/odoo/odoo/blob/081215d1220d6a362087aa33c304a452893b1dca/addons/stock/models/stock_quant.py#L1482-L1490
opw-4574169
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197824
Forward-Port-Of: odoo/odoo#197735This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#79401 Forward-Port-Of: odoo/enterprise#78014
Original PR description
This parameter should have been optional from the beginning. We changed it now because it causes problems when trying to use the TestEdi class with other Tests (Example: AR Website Sales) Forward-Port-Of: odoo/enterprise#79401 Forward-Port-Of: odoo/enterprise#78014
This commit allows the calendar_event_view_form_gantt_booking_inherit form view to display the answers to the questions linked to an appointment. https://github.com/odoo/odoo/pull/196426 Forward-Port-Of: odoo/enterprise#78536
Original PR description
This commit allows the calendar_event_view_form_gantt_booking_inherit form view to display the answers to the questions linked to an appointment. https://github.com/odoo/odoo/pull/196426 Forward-Port-Of: odoo/enterprise#78536
- make `new_car` True by default if the `available_cars_amount` is less than the `max_unused_cars` Task: 4378810 Forward-Port-Of: odoo/enterprise#75876
Original PR description
- make `new_car` True by default if the `available_cars_amount` is less than the `max_unused_cars` Task: 4378810 Forward-Port-Of: odoo/enterprise#75876
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
Original PR description
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
Original PR description
This commit fixes an issue with knowledge's members permission computation. If the additional fields given to the method weren't valid fields, the computation would crash and return an error. With this fix we filter the valid additional_fields provided so that we only use those for the computation. task-4562838 Forward-Port-Of: odoo/enterprise#79221
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
Original PR description
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
Original PR description
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79339 Forward-Port-Of: odoo/enterprise#77398
Original PR description
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79339 Forward-Port-Of: odoo/enterprise#77398
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won
Original PR description
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won't appear on the invoice in this flow, that's not a problem. Payment notification is also set on the sale order Forward-Port-Of: odoo/enterprise#79125
Forward-Port-Of: odoo/enterprise#79261
Original PR description
Forward-Port-Of: odoo/enterprise#79261