Tuesday, February 25, 2025
48 changes · saas-18.2
Resolved issues and error corrections
This update prevents an error when the system prepares Indian electronic invoice data for a new invoice that does not yet have an invoice date. It helps keep automated checks stable and avoids interruptions in invoice-related processing.
Original PR description
traceback: ```py ERROR: Subtest TestEveryModel.test_computed_fields_without_dependencies [Compute method of account.move.l10n_in_edi_content should work on new record.] Traceback (most recent call…
traceback:
```py
ERROR: Subtest TestEveryModel.test_computed_fields_without_dependencies [Compute method of account.move.l10n_in_edi_content should work on new record.]
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_display_name.py", line 61, in test_computed_fields_without_dependencies
model.new()[field.name]
~~~~~~~~~~~^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 6321, in __getitem__
return self._fields[key].__get__(self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields.py", line 1424, in __get__
self.compute_value(recs)
File "/data/build/odoo/odoo/orm/fields_binary.py", line 137, in compute_value
super().compute_value(records)
File "/data/build/odoo/odoo/orm/fields.py", line 1590, in compute_value
records._compute_field_value(self)
File "/data/build/odoo/addons/mail/models/mail_thread.py", line 474, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/models.py", line 4542, in _compute_field_value
determine(field.compute, self)
File "/data/build/odoo/odoo/orm/fields.py", line 69, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/data/build/odoo/addons/l10n_in_edi/models/account_move.py", line 75, in _compute_l10n_in_edi_content
json.dumps(move._l10n_in_edi_generate_invoice_json()).encode()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/l10n_in_edi/models/account_move.py", line 513, in _l10n_in_edi_generate_invoice_json
"Dt": self.invoice_date.strftime("%d/%m/%Y")
^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'strftime'
```
In this commit we fix the above traceback
error related to runbot nightly build
https://runbot.odoo.com/odoo/runbot.build.error/134225
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prShort website or portal tours could fail if the portal chatter was still loading when the tour ended. This fix prevents that harmless loading interruption from being treated as a crash, improving reliability of automated checks without changing user-facing behavior.
Original PR description
Before this commit, short portal and website tours that open a page with portal chatter may crash with following error: ``` Error received after termination: AssetsLoadingError: The loading of http://127.0.0.1:8069/web/bundle/portal.assets_chatter_style?lang=en_US&website_id=1 failed ``` This happens because the tour is so short and doesn't assert loading of portal chatter that the tour ends while portal chatter hasn't been loaded. The tour termination forces abort of ongoing lazy-loading such as portal chatter, which results in the crash above. This commit fixes the issue by silently catching the error in this very specific case that lazy-loading has been aborted by browser page reload or closing, which is precisely the case with tour. The crash is not relevant in that case, in practice the crash is intended to detect programming errors. runbot-114302
This fix ensures session-related web code is only loaded where it is needed in the main web client. It also removes an unused attendance menu asset from the public attendance bundle, reducing unnecessary code loading and potential conflicts.
Original PR description
*: hr_attendance This commit moves the session_service to the backend folder instead of the core folder. We also remove the unused attendance menu item used by the systray registry from the `hr_attendance.assets_public_attendance` bundle. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales commission reports were updated to work with a newer internal filtering system. This prevents report errors after platform changes and keeps commission and margin achievement reporting reliable.
Original PR description
Since https://github.com/odoo/odoo/pull/191784 expression is depreciated in favor to Domain. This commit update the calls. Unfortunately, the new mechanism is not backward compatible and it does not work with aliases. As a result, we also have to remove all aliases to so and am.
Miscellaneous changes
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A
Original PR description
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the…
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1. 2. Create a Manufacturing Order (MO) from this BoM. 3. Confirm the MO and set it to In Progress. 4. In the MO interface: Change the by-product from Product A to Product B. 5. Complete the MO. https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d **Current Behavior** The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A. **Expected Behavior** The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components). It would be worth to add the same kind of readonly condition on the byproduct side as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198522 Forward-Port-Of: odoo/odoo#194972
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Internal, New - Add an operation - Change the location and destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move #### Error: the location and destination location of the stock move are still the initia
Original PR description
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable…
### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Internal, New - Add an operation - Change the location and destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move #### Error: the location and destination location of the stock move are still the initial ones. ### Cause of the issue: The onchange method `_onchange_locations` of the "stock.picking" model: https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/stock/models/stock_picking.py#L825-L836 has been removed in saas-17.2 byt the push pull refactror: 11e69870db1c49d9a6af79ffd263e4e162b34b6b However, it should not have been for the "location_id" since it was not replaced by any other mechanic and it has been replaced by a compute method for the "location_dest_id": https://github.com/odoo/odoo/blob/5a61e440232b119f712ff9545ec3e535210bbb94/addons/stock/models/stock_move.py#L200-L201 However, this compute method is not triggered in the above flow for the following reason: On the picking model, there are two fields that contain the stock moves: https://github.com/odoo/odoo/blob/17a63a6cda41a44e3d4ff8b5a9042e93ba956bc8/addons/stock/models/stock_picking.py#L612-L614 Where `move_ids_without_packages` is a subset of `move_ids` When editing the operations of a picking, we are actually dealing with the field `move_ids_without_packages`. So, when changing the locations of the picking, the webclient sends the SMs via the field `move_ids_without_packages`, i.e.: the web client does not provide any value for `move_ids`. Server side, when creating a `new` record based on the provided values, we will handle the inverse of `move_ids_without_packages`, i.e.: we will make sure that the stock moves have the field `picking_id` correctly defined: https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L6366-L6374 **But** we don't define any value for the siblings of the field. It means that we don't set any value for the field `move_ids`. This will lead to the bug: later on in the onchange, we flag all fields that will have to be recomputed: https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L983 And here we would hope that the field `location_dest_id` of the stock moves will be flagged, as mentioned in the dependencies: https://github.com/odoo/odoo/blob/68ae97bd27fbdc874922e03f52f8b0c7953df801/addons/stock/models/stock_move.py#L206-L207 But... In `_modified_triggers`, at some point, we are here https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L7200-L7203 Where `field` is `stock.move.picking_id`. So, we iterate on the inverse field of `field`, i.e.: `move_ids` and `move_ids_without_packages`. However, as explicitly mentioned in the comment, we "use an inverse of field without domain", i.e.: `move_ids`. We therefore read the value of this field on the picking which is, because of the bug explained in the previous paragraph, an empty record. As a result, the ORM considers that it does not have to recompute any `location_dest_id`. The ORM team is aware of the issue. They have tried to write a generic solution (cf PR [191318](https://github.com/odoo/odoo/pull/191318)) but it led to a lot of other errors. So, the issue has been considered as a limitation and added to a todo list on their side. In the meantime, it is possible to patch the issue with a stock-specific fix. Note: the issue will also happen when editing an existing picking. Suppose a picking with one move SM01. The user adds a second move SM02, does not save and edits the destination location of the picking: for the same reasons, the ORM will only see SM01 and, therefore, will call the compute method for SM01 only. Contains a backport of 22e17e513e9d0309a832e27ee10f89a96688d905 Co-authored-by: "Adrien Widart (awt)" <awt@odoo.com> opw-4491101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198617 Forward-Port-Of: odoo/odoo#198504
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
Original PR description
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content, considering the editor handles the delete operation and assumes the default behavior is prevented. The steps below illustrate one of the possible issues. Steps 1: a. Have the following html: ``` <h1><span style="font-size: 36px;">Welcome to the To-do app! </span></h1> <p> <span style="font-s
Original PR description
On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content,…
On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content, considering the editor handles the delete operation and assumes the default behavior is prevented.
The steps below illustrate one of the possible issues.
Steps 1:
a. Have the following html:
```
<h1><span style="font-size: 36px;">Welcome to the To-do app! </span></h1>
<p>
<span style="font-size: 14px;">
Use it to manage your work</span>
</p>
```
b. On Android Chrome, place the cursor at the beginning of the paragraph and press backspace on the device's virtual keyboard.
As a result, the paragraph is merged with the heading, but the characters "Use it to" disappear:
```
<h1>
<span style="font-size: 36px;">Welcome to the To-do app!</span>
<span style="font-size: 14px;"> manage your work</span>
</h1>
```
This example was taken from the "Welcome Mitchell Admin" task in the To-do app, so it's easily testable.
Steps 2:
a. On Android Chrome, have two paragraphs with some text, and place the cursor at the beginning of the second paragraph. E.g.:
```
<p>abc</p>
<p>[]def</p>
```
b. Press backspace on the device's virtual keyboard.
As a result, the paragraphs are merged (as expected), but the cursor is placed in the wrong position, e.g.: `<p>abcd[]ef</p>`, whilst `<p>abc[]def</p>` was expected.
Since the default behavior cannot be prevented, this commit makes sure that eventual DOM mutations and selection changes occurred after the beforeinput event are reverted, aiming to achieve the same effect as preventing default.
task-4243933
Forward-Port-Of: odoo/odoo#193821Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993 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#198609
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Original PR description
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Add "(copy)" to the name of the duplicated payment term. task-4227445 Forward-Port-Of: odoo/odoo#199071 Forward-Port-Of: odoo/odoo#197605
Original PR description
Add "(copy)" to the name of the duplicated payment term. task-4227445 Forward-Port-Of: odoo/odoo#199071 Forward-Port-Of: odoo/odoo#197605
The lack of borders in the modals of the front-end is problematic when there is some content overflowing the height of the modal. This PR restores the borders for a better visual hierarchy. Non-optimal design introduced in front-end redesign: https://github.com/odoo/odoo/pull/120302 task-4001380 | Before | After | |--------|--------| | <img width="979" alt="Screenshot 2024-06-20 at 11 41 54" src="https://github.com/odoo/odoo/assets/110090660/31e0d3c7-fcd9-43c9-9aae-7db3b4e49af2"> |
Original PR description
The lack of borders in the modals of the front-end is problematic when there is some content overflowing the height of the modal. This PR restores the borders for a better visual hierarchy. Non-optimal design introduced in front-end redesign: https://github.com/odoo/odoo/pull/120302 task-4001380 | Before | After | |--------|--------| | <img width="979" alt="Screenshot 2024-06-20 at 11 41 54" src="https://github.com/odoo/odoo/assets/110090660/31e0d3c7-fcd9-43c9-9aae-7db3b4e49af2"> | <img width="978" alt="Screenshot 2024-06-20 at 11 42 26" src="https://github.com/odoo/odoo/assets/110090660/09f12eb0-79e4-454f-9896-af238b26a7b3"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170105
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196725 Forward-Port-Of: odoo/odoo#174611
Before this commit, searching emoji required at least 2 chars. There is no reason to not allow 1 char, especially when searching some emoji that are best found with a single char, e.g. "9️⃣" with "9". Forward-Port-Of: odoo/odoo#199134 Forward-Port-Of: odoo/odoo#198759
Original PR description
Before this commit, searching emoji required at least 2 chars. There is no reason to not allow 1 char, especially when searching some emoji that are best found with a single char, e.g. "9️⃣" with "9". Forward-Port-Of: odoo/odoo#199134 Forward-Port-Of: odoo/odoo#198759
Before this PR, the `last_seen_message_should_send_notification_only_once` test was sometimes failing. This is due to the assertion of `im_status` being set to `offline` while the hr module overrides statuses with values such as `leave_offline`. This PR fixes the issue. runbot-112747 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.c
Original PR description
Before this PR, the `last_seen_message_should_send_notification_only_once` test was sometimes failing. This is due to the assertion of `im_status` being set to `offline` while the hr module overrides statuses with values such as `leave_offline`. This PR fixes the issue. runbot-112747 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#198964
The discuss side bar displays call participants in an avatar stack to avoid bloating the UI. However, this avatar stack is quite small while there is plenty of horizontal space. As a result, its difficult to know which users are currently in the call. It's possible to expand the avatar stack to have more information but the toggle is too small and its not as easy as it should be. This PR fixes both issues: - Avatar stack gives more space for each avatar, size is slightly increased and the st
Original PR description
The discuss side bar displays call participants in an avatar stack to avoid bloating the UI. However, this avatar stack is quite small while there is plenty of horizontal space. As a result, its…
The discuss side bar displays call participants in an avatar stack to avoid bloating the UI. However, this avatar stack is quite small while there is plenty of horizontal space. As a result, its difficult to know which users are currently in the call. It's possible to expand the avatar stack to have more information but the toggle is too small and its not as easy as it should be. This PR fixes both issues: - Avatar stack gives more space for each avatar, size is slightly increased and the stack displays more avatars. - Its now possible to click on the stack to expand it. Also fixes an issue where short status were shown when sidebar is in non-compact mode. | Before | After | | ------------- | ------------- | ||  | |  |  | Forward-Port-Of: odoo/odoo#198819
Before this PR, the `discuss_channel_as_guest_tour` would sometimes fail. Discuss is displayed once the thread is restored. However, one patch removes the `useState` from the store of the component, which leads to the `hasRestoredThread` flag not being observed. If `restoreDiscussThread` is too slow to execute, no render occur, no thread is displayed. This PR fixes the issue. runbot-106455 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavio
Original PR description
Before this PR, the `discuss_channel_as_guest_tour` would sometimes fail. Discuss is displayed once the thread is restored. However, one patch removes the `useState` from the store of the component, which leads to the `hasRestoredThread` flag not being observed. If `restoreDiscussThread` is too slow to execute, no render occur, no thread is displayed. This PR fixes the issue. runbot-106455 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#198979
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because
Original PR description
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that…
Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because we tried to sort records on a field that is unknown. 2) if it wasn't the first field of the order, e.g. `default_order="x,y"` but y wasn't in the view: the changes done in the dialog were lost, so it was no possible to edit records. Both issues had the same root cause. After the edition, we tried to sort the relation (as the order might have changed). We do that since [1], but it wasn't the main purpose of this commit. It has been done because it looked like a quick win at the time, and we thought it was a good idea. However, functionally speaking, sorting the records after the edition isn't wanted. If I just clicked on a record, edited it, I expect the record to remain where it was after closing the dialog. So as sorting isn't necessarily wanted, and it even produces issues in some cases, this commit reverts that "feature". [1] https://github.com/odoo/odoo/commit/17e198153ecfd9c5c32b3b22f43e2f1b8100a1c3 Closes #197867 opw-4499150 (case (2)) 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#199070 Forward-Port-Of: odoo/odoo#198757
- Fix for following runbot error (https://runbot.odoo.com/odoo/runbot.build.error/110971) that was causing a traceback when displaying the receipt screen. runbot error: 110971 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#198762
Original PR description
- Fix for following runbot error (https://runbot.odoo.com/odoo/runbot.build.error/110971) that was causing a traceback when displaying the receipt screen. runbot error: 110971 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#198762
Discuss test helpers provide an `asTab` parameter to mount two main clients, simulating odoo being opened in two different tabs and a dropdown is available to switch from one view to the other. However, height is not propagated to the parent div. As a result, discuss components are invisible, as height is not working properly. This PR ensures the parent div is properly configured, allowing to see discuss UI. Description of the issue/feature this PR addresses: Current behavior before
Original PR description
Discuss test helpers provide an `asTab` parameter to mount two main clients, simulating odoo being opened in two different tabs and a dropdown is available to switch from one view to the other. However, height is not propagated to the parent div. As a result, discuss components are invisible, as height is not working properly. This PR ensures the parent div is properly configured, allowing to see discuss UI. 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#198959
We forgot to parse a boolean which was stored as a string so it was always considered true (both the strings `'true'` and `'false'` evaluate to `true` in a boolean context. This change also fixes the `showQuantity` computation in the product and combo configurators (the computation assumed the user was on the product page, which isn't necessarily the case for "add to cart" snippets). Forward-Port-Of: odoo/odoo#196406
Original PR description
We forgot to parse a boolean which was stored as a string so it was always considered true (both the strings `'true'` and `'false'` evaluate to `true` in a boolean context. This change also fixes the `showQuantity` computation in the product and combo configurators (the computation assumed the user was on the product page, which isn't necessarily the case for "add to cart" snippets). Forward-Port-Of: odoo/odoo#196406
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an em
Original PR description
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have…
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an email message, has the MIME type `message/rfc822`. According to [RFC 2046 Section 5.2.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.2.1:~:text=No%20encoding%20other%20than%20%227bit%22%2C%20%228bit%22%2C%20or%20%22binary%22%20is%20permitted%20for%0A%20%20%20the%20body%20of%20a%20%22message/rfc822%22%20entity.), attachments of this MIME type must be encoded using `7bit`, `8bit`, or `binary`. However, the system currently encodes all attachments using Base64 by default, which is not compliant with the standard for `message/rfc822`. Although some email clients tolerate Base64 encoding for `message/rfc822`, others, such as Thunderbird, Roundcube, and Zimbra, strictly follow the RFC and reject Base64-encoded `message/rfc822` attachments. As a result, these attachments appear invalid and are downloaded as empty files. opw-4126522 Forward-Port-Of: odoo/odoo#198862 Forward-Port-Of: odoo/odoo#194988
The send button wasn't align with the overdue Invoices above, now he is. task-4582381 Linked:https://github.com/odoo/enterprise/pull/79446 Forward-Port-Of: odoo/odoo#198529
Original PR description
The send button wasn't align with the overdue Invoices above, now he is. task-4582381 Linked:https://github.com/odoo/enterprise/pull/79446 Forward-Port-Of: odoo/odoo#198529
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198447 Forward-Port-Of: odoo/odoo#196598
Original PR description
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198447 Forward-Port-Of: odoo/odoo#196598
Versions -------- - 18.0+ Steps ----- 1. Enable Prevent Sale of Zero Priced Product; 2. have a product with attributes; 3. set its list price to 0; 4. add a price extra to one of its attributes; 5. go to its eCommerce page; 6. select the price extra attribute. Issue ----- Both the "Add to cart" and "Contact Us" buttons are shown. Cause ----- - Commit 8f4c8ada7e9fe refactored the `website_sale.product` template, moving the "Contact Us" button outside of the `div.js_product`
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable Prevent Sale of Zero Priced Product; 2. have a product with attributes; 3. set its list price to 0; 4. add a price extra to one of its attributes; 5. go to its eCommerce page; 6. select the price extra attribute. Issue ----- Both the "Add to cart" and "Contact Us" buttons are shown. Cause ----- - Commit 8f4c8ada7e9fe refactored the `website_sale.product` template, moving the "Contact Us" button outside of the `div.js_product` element. - This element gets passed as `$parent` to the `_onChangeCombination` method, which ought to handle these changes. - Because the `#contact_us_wrapper` is no longer in `$parent`, it fails to find it and change its classes accordingly. Solution -------- Instead of querying for the `#contact_us_wrapper` element directly in `$parent`, look for the `#product_details` element first, then query it. opw-4423323 Forward-Port-Of: odoo/odoo#195776
**Problem**: In Safari, relying on the browser to add a space after automatic link creation causes the cursor to be incorrectly positioned. This issue arises due to DOM manipulations (adding and removing nodes) during the process. **Solution**: To ensure proper link insertion and cursor positioning, explicitly add the space after the link and set the selection programmatically. **Steps to Reproduce**: 1. Open the Editor on Safari. 2. Add the text "test.com". 3. Press the space key. 4
Original PR description
**Problem**: In Safari, relying on the browser to add a space after automatic link creation causes the cursor to be incorrectly positioned. This issue arises due to DOM manipulations (adding and removing nodes) during the process. **Solution**: To ensure proper link insertion and cursor positioning, explicitly add the space after the link and set the selection programmatically. **Steps to Reproduce**: 1. Open the Editor on Safari. 2. Add the text "test.com". 3. Press the space key. 4. Observe that the link is created, but the cursor moves to the start of the paragraph. opw-4441817 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194989
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it
Original PR description
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking. OPW-3919976 Forward-Port-Of: odoo/odoo#198752 Forward-Port-Of: odoo/odoo#196161
At some point, servers started to return `image/svg+xml; charset=utf-8` instead of `image/svg+xml` in the `content-type` header of SVG images. Because of this, dynamic SVGs were not properly handled anymore. This commit adapts the mimetype comparisons to cope for this extra `charset` info inside the mimetype. Steps to reproduce: - Drop an image block inside a website page. - Replace the image. - Search for e.g. "city". - Pick an undraw illustration. => The image was lost because its
Original PR description
At some point, servers started to return `image/svg+xml; charset=utf-8` instead of `image/svg+xml` in the `content-type` header of SVG images. Because of this, dynamic SVGs were not properly handled anymore. This commit adapts the mimetype comparisons to cope for this extra `charset` info inside the mimetype. Steps to reproduce: - Drop an image block inside a website page. - Replace the image. - Search for e.g. "city". - Pick an undraw illustration. => The image was lost because its `src` became `false`. Forward-Port-Of: odoo/odoo#198267
The first subtotal is always the untaxed amount of the document. All following subtotals are just the previous one plus the previous taxes. So the subtotal no longer depend of the taxes under it. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199056
Original PR description
The first subtotal is always the untaxed amount of the document. All following subtotals are just the previous one plus the previous taxes. So the subtotal no longer depend of the taxes under it. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199056
In this commit, The restaurant scenario loads in data instead of the demo. related PR: https://github.com/odoo/odoo/pull/194777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198748
Original PR description
In this commit, The restaurant scenario loads in data instead of the demo. related PR: https://github.com/odoo/odoo/pull/194777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198748
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron. **Reproduction/Rationale**: - Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it - The order might be to be signed but not marked to be paid for acceptanc
Original PR description
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the…
There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron. **Reproduction/Rationale**: - Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it - The order might be to be signed but not marked to be paid for acceptance - Therefore the signature will confirm the order and the subscription will be invoiced via cron later - The draft is, as stated, not a failure but the wanted behavior in this scenario and no payment exception is possible because there is no payment related and created on confirmation. As the approach is to automatically put the order into a payment exception it is very important to catch ALL the scenarios where it needs to be removed. (this approach should be reconsidered in master IMO as it is a trap and rabbit hole) Info: @wt-io-it Forward-Port-Of: odoo/enterprise#79391
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe cont
Original PR description
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe contener la versión impresa del comprobante fiscal? En la representación impresa se incluirán como mínimo los datos establecidos en la regla 2.7.1.7. de la RMF. Fundamento: Regla 2.7.1.7. de la RMF. " opw-4473180 Forward-Port-Of: odoo/enterprise#79979 Forward-Port-Of: odoo/enterprise#79527
This PR introduces two key features in Uruguayan electronic invoicing: Global Discounts: - Implemented the ability to apply global discounts across invoices. - Discounts are calculated and reflected in the final invoice total, ensuring compliance with DGI requirements. Down Payments: - Support for down payments was added to the invoicing process to ensure compliance with DGI requirements. ------------------------------- latam-task: 1284 adhoc-task-side: 45612 Forward-
Original PR description
This PR introduces two key features in Uruguayan electronic invoicing: Global Discounts: - Implemented the ability to apply global discounts across invoices. - Discounts are calculated and reflected in the final invoice total, ensuring compliance with DGI requirements. Down Payments: - Support for down payments was added to the invoicing process to ensure compliance with DGI requirements. ------------------------------- latam-task: 1284 adhoc-task-side: 45612 Forward-Port-Of: odoo/enterprise#75124
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
Users managing several branch companies may collect in a batch several payments from the branches. However this currently does not work as expected. Steps to reproduce: - Have a [main] company and a [branch] company - Create a payment in [branch] - Create a batch in [main] - Add the payment to the batch Issue: Error will raise ``` Incompatible companies on records: - “PAY00001” belongs to company “Your branch” and “Batch Payment” (batch_payment_id: 'BATCH/IN/2025/0001 (New)')
Original PR description
Users managing several branch companies may collect in a batch several payments from the branches. However this currently does not work as expected. Steps to reproduce: - Have a [main] company and a [branch] company - Create a payment in [branch] - Create a batch in [main] - Add the payment to the batch Issue: Error will raise ``` Incompatible companies on records: - “PAY00001” belongs to company “Your branch” and “Batch Payment” (batch_payment_id: 'BATCH/IN/2025/0001 (New)') belongs to another company ``` This occurs because now we check that batch and payment belong to the same company It is a change of behavior as in older versions this flows was permitted opw-4574188 Forward-Port-Of: odoo/enterprise#79719
See community PR Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993 Forward-Port-Of: odoo/enterprise#79950
Original PR description
See community PR Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993 Forward-Port-Of: odoo/enterprise#79950
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#79960
Original PR description
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#79960 Forward-Port-Of: odoo/enterprise#79044
This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#79996 Forward-Port-Of: odoo/enterprise#77578
Original PR description
This commit adds one flow test to `l10n_ec_edi` that mocks `zeep` when sending an invoice to the SRI. This complements the existing tests that check the generated XML. task-none Forward-Port-Of: odoo/enterprise#79996 Forward-Port-Of: odoo/enterprise#77578
Fix the position of the web ribbon which isn't correctly set to the right of the kanban card. related PR: odoo/enterprise#77884 Task-4582362 Forward-Port-Of: odoo/enterprise#79437
Original PR description
Fix the position of the web ribbon which isn't correctly set to the right of the kanban card. related PR: odoo/enterprise#77884 Task-4582362 Forward-Port-Of: odoo/enterprise#79437
The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
Original PR description
The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
The send button wasn't align with the overdue Invoices above, now he is. task-4582381 linked:https://github.com/odoo/odoo/pull/198529 Forward-Port-Of: odoo/enterprise#79446
Original PR description
The send button wasn't align with the overdue Invoices above, now he is. task-4582381 linked:https://github.com/odoo/odoo/pull/198529 Forward-Port-Of: odoo/enterprise#79446
Before this commit, the _next_billing_details would not compute the amount in the currency of the order. Forward-Port-Of: odoo/enterprise#79289 Forward-Port-Of: odoo/enterprise#74162
Original PR description
Before this commit, the _next_billing_details would not compute the amount in the currency of the order. Forward-Port-Of: odoo/enterprise#79289 Forward-Port-Of: odoo/enterprise#74162
By default, SEPA requires a 5 day notification period prior to collecting a payment, if no payment has ever been collected using the related mandate. However, it could be that the company used another software before and imported their existing mandates (that have no payments yet in Odoo). In this case, the 5 day period does not apply and can be relaxes to the default 2 day period for running mandates. Instead of blocking the user when their required payment date is not at least 5 days fro
Original PR description
By default, SEPA requires a 5 day notification period prior to collecting a payment, if no payment has ever been collected using the related mandate. However, it could be that the company used another software before and imported their existing mandates (that have no payments yet in Odoo). In this case, the 5 day period does not apply and can be relaxes to the default 2 day period for running mandates. Instead of blocking the user when their required payment date is not at least 5 days from today (on first-time mandates), we now only show a warning at the top of the form, with links to the related payments. Blocking the user will only happen if the required payment date is not at least 2 days from today. [task-4472278](https://www.odoo.com/odoo/project.task/4472278) Forward-Port-Of: odoo/enterprise#79921 Forward-Port-Of: odoo/enterprise#77134
Issue ----- Attachments are linked to `document.document` with a (`res_model`) and `res_field` By default, searching on `ir.attachment` filters out attachments tied to binary fields (ref.1), by adding `['res_field', '=', False]` to the domain preventing such documents from appearing in searches. Solution -------- This commit skips the filter on `res_field` Steps to Reproduce ------------------- 1. Install `documents` and `accountant` modules. 2. Enable Files Centralization for Ac
Original PR description
Issue ----- Attachments are linked to `document.document` with a (`res_model`) and `res_field` By default, searching on `ir.attachment` filters out attachments tied to binary fields (ref.1), by adding `['res_field', '=', False]` to the domain preventing such documents from appearing in searches. Solution -------- This commit skips the filter on `res_field` Steps to Reproduce ------------------- 1. Install `documents` and `accountant` modules. 2. Enable Files Centralization for Accounting and add Customer Invoices to its Journals. 3. Create an invoice → Confirm → Print → Download. 4. Click on the related document. Bug:The PDF cannot be searched by its indexed content. (ref. 1) ---- 1bb61c970ed63eabe3821d21f3ed6f99c4b16daa [ADD] fields: add option to store binary fields into attachments opw-4267371 Forward-Port-Of: odoo/enterprise#75051
**Steps to reproduce:** - Install "Point of Sale" - Go to "Settings" - Enter the API Key for "barcodelookup.com" - Open a POS session - Scan a QR code not linked to any product **Issue:** The following error is raised: The action "point_of_sale.product_product_action_add_pos" does not exist. **Cause:** The action has been renamed to "product_template_action_add_pos". opw-4584711 Forward-Port-Of: odoo/enterprise#80040
Original PR description
**Steps to reproduce:** - Install "Point of Sale" - Go to "Settings" - Enter the API Key for "barcodelookup.com" - Open a POS session - Scan a QR code not linked to any product **Issue:** The following error is raised: The action "point_of_sale.product_product_action_add_pos" does not exist. **Cause:** The action has been renamed to "product_template_action_add_pos". opw-4584711 Forward-Port-Of: odoo/enterprise#80040
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise
Original PR description
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights -…
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise/commit/4220723e0779287e5a8e301553e1a870cd3c4ca5 in task: 2040710 Reason: No group where set on the button 'Purchase Orders' which is used to access the RFQ from the approval this button needs a protected field to be able to be displaed properly in addition to that no default value was set if the user has no rights to read the 'purchase.order.line' model. Expected behavior: The button should not be displayed if the user has no access rights to the RFQ and thus grand access to the approval of the user FIX add a default value if the user has no read rights on the model 'purchase.order.line' ultimatly making everything related to it in the form view invisible Also add a group to it in the view to permit to remove the default value in master task-3561514 Forward-Port-Of: odoo/enterprise#79098 Forward-Port-Of: odoo/enterprise#78275
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#79811 Forward-Port-Of: odoo/enterprise#78013
Original PR description
This commit will fix two errors: - for the value of average creditors days (A11) in B11 we used B18 for the calculation but it should be b15 - Error in naming for B34 and D34 (invert the two) task-4518430 Forward-Port-Of: odoo/enterprise#79811 Forward-Port-Of: odoo/enterprise#78013
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524
Original PR description
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524