Tuesday, October 22, 2024
51 changes · saas-17.4
Resolved issues and error corrections
Tax descriptions now appear as readable plain text in field service reports instead of showing raw HTML tags. This prevents blank descriptions and formatted descriptions from creating confusing report output for customers and staff.
Original PR description
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions…
Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. - related enterprise fix: https://github.com/odoo/enterprise/pull/68454 opw-4104951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Field service reports now show tax descriptions as plain readable text instead of displaying raw HTML tags. This prevents confusing placeholders or formatting artifacts from appearing on printed customer reports.
Original PR description
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax…
## Issue: - Tax descriptions in the field service report contain HTML tags, leading to undesirable formatting. - Tax descriptions that are empty result in `<p><br></p>` being printed. - Tax descriptions with content result in `<p>[description]</p>` being printed. ## Steps To Reproduce: - Create a field service task and add products on it. - Add a Sales Order Item that has taxes. - Print the field service report. - Notice when the taxes has no description it print `<p><br><p>`. - Notice when the taxes has has something in the [description] field it print `<p>[description]><p>`. ## Solution: - In the `account.tax` model, the description field was changed to an HTML field with this commit: https://github.com/odoo/odoo/commit/112c68a07b817e5e9a6c01e34a0fe7238b2eaa07 - Added `_get_description_plaintext` method to convert HTML content to plaintext using `html2plaintext`. This will also ensure compatibility for future changes to the description field. related community fix: https://github.com/odoo/odoo/pull/184053 opw-4104951
Miscellaneous changes
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interac
Original PR description
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 ->…
To reproduce (17.0 and >): 1. Install PoS 2. Open a restaurant session = S1 3. Open the same restaurant session in another browser session (e.g: private navigation) = S2 4. Make an order from S2 -> The order sync on S1 (thanks to websockets) => OK! 5. On another tab of S1, go to Settings > Self-Ordering / Preview Web interface 6. Make an order from S2 -> The order DO NOT sync from S2 => Not Ok Note: in practice, it goes beyond than just order not syncing, any previous websockets interaction will fail which includes: - some payment method callback (Adyen, Vivawallet) - IoT printing requests - chatter messages ... Reasons of the issue: The issue happen as the websocket use a shared workers and certain operation (like here opening self-order), will interupt the current websocket to open a new one on which previously subscribed channel will be missing (explaining why the PoS session won't sync orders). The shared worker decided to interupt the previous websocket and create a new one as the "db" information was missing from the `session_info`, see: https://github.com/odoo/odoo/blob/dfdea9704a13c259cc1d49d6bd3a3fa4d93307b6/addons/bus/static/src/workers/websocket_worker.js#L257 After this commit: PoS orders continue to sync even if the kiosk view is opened on the same browser session opw-4233060 Forward-Port-Of: odoo/odoo#183527
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184152
Original PR description
This hook is used for fix in the corresponding enterprise commit. We do it this way instead of defining everything in enterprise for clarity and robustness. Forward-Port-Of: odoo/odoo#184152
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtua
Original PR description
**Current behavior:** Creating a new picking, adding some moves, then adding/changing the partner_id field all without saving will remove the added moves. **Expected behavior:** Changing the partner shouldn't affect the moves. **Steps to reproduce:** 1. Create a new picking, add some moves, then add a partner (all without saving) 2. Observe the moves disappear after adding the partner **Cause of the issue:** In the onchange handling partner_id changes, we overwrite the new virtual moves with values and mark them as modified. This causes them to eventually get invalidated and they aren't saved once the update (overwrite) resolves. **Fix:** Don't update virtual moves (records without an _origin). opw-4120108 Forward-Port-Of: odoo/odoo#182606
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and Start the repair - try to end the repair **Problem:** A traceback is triggered: “raise ValueError("Expected singleton: %s" % self) Value Error: Expected singleton: stock.location() “ When the "action_repair_end" is called, a move is created with the kit product, and
Original PR description
**Steps to reproduce the bug:** - Create a consumable product “Kit 1” with the following BoM: - component: X1 - Create a repair order to repair one unit of Kit 1: - Don’t add any part - confirm and…
**Steps to reproduce the bug:**
- Create a consumable product “Kit 1” with the following BoM:
- component: X1
- Create a repair order to repair one unit of Kit 1:
- Don’t add any part
- confirm and Start the repair
- try to end the repair
**Problem:**
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“
When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80
Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74
So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94
The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052
If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:
“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“
opw-[3942297](https://www.odoo.com/web#id=3942297&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#170352
Forward-Port-Of: odoo/odoo#168227Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
Original PR description
Issue --> The field `available_currency_ids` is an empty recordset since `authorize` supports all currencies. We're assuming that `authorize` supports all currencies because it uses the base `_get_supported_currencies` method which returns all currencies. Solution --> Return the company currency as validation currency if no currency is set on the payment provider. opw-4252974 Forward-Port-Of: odoo/odoo#184226
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#183993
Original PR description
**Steps to reproduce the bug:** - Enable the "Expiration Date" feature in inventory settings. - Create a non-tracked product "P1". - Create a receipt with one unit of P1. - Mark it as "To Do". - Go to the detailed operation. **Problem:** You are able to set an expiration date even though the product is not tracked. opw-4256125 Forward-Port-Of: odoo/odoo#183993
**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058
Original PR description
**Current behavior before PR:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action did not remove the `contentEditable=false` element. **Desired behavior after PR is merged:** When an elements next sibling is a whitespace node, followed by a `contentEditable=false` element, performing the deleteforward action will now remove both the whitespace and the entire `contentEditable=false` element. task:4058770 Forward-Port-Of: odoo/odoo#179639
Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. St
Original PR description
Problem: After [this commit](https://github.com/odoo/odoo/commit/59e252c715ba96af5ec66f9c543c2c6195082c7d), the editor fails to properly check the state of selections containing the character `\ufeff`. Since `\ufeff` has no style applied, any style check on a selection that includes this character returns `false`. While reverting the change would break support for styling elements containing only spaces, the fix involves checking if an element is a BOM character and assuming it is styled. Steps to reproduce: - Open any page with the web editor. - Add text with part of it formatted as a link. - Try toggling any style (e.g., bold, italic). - The style is applied but cannot be reverted, and the button state remains off. opw-4213717 Forward-Port-Of: odoo/odoo#181793
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
Original PR description
Issue: if 'sequence' in vals and self and self[-1].id == self._prefetch_ids[-1]: TypeError: 'PrefetchX2many' object is not subscriptable Cause of the issue: PrefetchX2many object does not have __getitem__ method, only __iter__ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183224
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Original PR description
Bootstrap adds an ugly white background to `table` tags when we add the `table` class. We now force it to be transparent. Forward-Port-Of: odoo/odoo#184515
Consider the Inter-Company transit location (which is a 'transit' location with no company set) as either a 'customer' or 'supplier' location for dropship purposes. Both 'supplier' and 'customer' need to be considered as the dropship could be either from Vendor -> Other Company or Other Company -> Customer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183190
Original PR description
Consider the Inter-Company transit location (which is a 'transit' location with no company set) as either a 'customer' or 'supplier' location for dropship purposes. Both 'supplier' and 'customer' need to be considered as the dropship could be either from Vendor -> Other Company or Other Company -> Customer. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183190
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e5
Original PR description
This Error occurs when a user tries to archive multiple journals. Steps to reproduce: - Install the ```account``` module - Go to Invoicing / Configuration / Accounting / Journals. - Select two or more journals and try to archive them. ```ValueError: Expected singleton: account.journal(15, 18)``` An error occurs at [1] because the system attempts to retrieve the id from 'self', which contains multiple records. link [1]:https://github.com/odoo/odoo/blob/1f7debc24bab4e0a7f2ef0d85e50d9381e1826cd/addons/account/models/account_journal.py#L801 To resolve this issue, Use an ```ids``` instead of an ```id``` to get a multiple records. Sentry-5917175119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182664 Forward-Port-Of: odoo/odoo#182043
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as i
Original PR description
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391).…
The **`btw_X0`** tax was updated [Here](https://github.com/odoo/odoo/commit/02ccb58401a45528adb77c768318c9f6dfdf05b6#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as it appeared in the production environment. To address this issue, I have added the XML ID of the tax to map the old tax. opw-[4091389](https://www.odoo.com/odoo/project/70/tasks/4091389) upg-[1874716](https://upgrade.odoo.com/web#id=1874716&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form) 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#182937
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: od
Original PR description
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 6d222885f41f5136c690dcd56953f1a9775204ae pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904 Forward-Port-Of: odoo/odoo#183180
When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
Original PR description
When starting a PoS session a useless sequence was created every time Steps to reproduce: ------------------- * Open a PoS session on different days > Observation: Go to the sequence list in the settings, there is one sequence for each days you opened a session Why the fix: ------------ The sequence was actually not used so we just remove it. opw-4166554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184503
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component 4 - Create a Mo for one unit of P1 - Confirm the MO - Update the BoM of P1: - Delete Component 2 - Go back to the MO - Refresh the page - Click "Update from BoM" Problem: Only the move for Component 1 is retained. The moves for Compon
Original PR description
Steps to reproduce the bug: - Create a storable product P1 with the following BoM: - Components: - Component 1 - Component 2 - Kit (which has its own BoM) - BoM of the kit: - Component 3 - Component…
Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
- Components:
- Component 1
- Component 2
- Kit (which has its own BoM)
- BoM of the kit:
- Component 3
- Component 4
- Create a Mo for one unit of P1
- Confirm the MO
- Update the BoM of P1:
- Delete Component 2
- Go back to the MO
- Refresh the page
- Click "Update from BoM"
Problem:
Only the move for Component 1 is retained. The moves for Components 2 (which were deleted) and for Components 3 and 4 (which belong to the kit) are removed, while the kit should be decomposed into its own components (3 and 4) and their moves retained.
The current logic did not handle kit products properly when updating the MO. It only compared the components at the top level of the BoM, ignoring the fact that kits contain their own components. As a result, the moves corresponding to the kit's components were not detected and were deleted when updating the MO.
opw-4247193
Forward-Port-Of: odoo/odoo#184329
Forward-Port-Of: odoo/odoo#183638Description of the issue/feature this PR addresses: It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Current behavior before PR: User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Desired behavior after PR is merged: User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund. Task Adhoc side: 40557 Tas
Original PR description
Description of the issue/feature this PR addresses:
It is necessary to be able to select document type "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Current behavior before PR:
User is not able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Desired behavior after PR is merged:
User is able to select document types "60 CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" in an invoice or refund.
Task Adhoc side: 40557
Task latam: 1254
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176858In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#184533 Forward-Port-Of: odoo/odoo#157362
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Enterprise PR: odoo/enterprise#58487 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/odoo#184533 Forward-Port-Of: odoo/odoo#157362
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Se
Original PR description
Problem: When editing images, the company context is not respected during operations such as `get_image_info` and `modify_image`. This occurs because we use `self._clean_context()` during creating of attachment which was introduced [here](https://github.com/odoo/odoo/commit/a137f22363ff538ab86f50d15851730af1b8ed76) , it strips the company from the context. This fix ensures that company information is skipped for these methods as well, similar to attachment creation. Steps to Reproduce: - Select a company other than the default one. - Create a quotation. - In the description, add an image and save. - Try to crop the image and save again. The operation fails due to the company context issue. opw-4173391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183112
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
Original PR description
Steps to reproduce the bug: - In website dit mode. - Click on the footer. - Enable the "Scroll Top Button" option for the footer. - Disable the "Copyright" option for the footer. - Bug: There is a white space below the footer. task-4208475 Forward-Port-Of: odoo/odoo#183514
… is not set" This reverts commit fd1da69f8331dbc55be2d164fad381fca1622a67. The l10n_it_document_type belongs to `l10n_it_edi_ndd` module. This module exists to add this stored field that was missing. When the error that this commit tried to fix happens, which is due to the fact that the compute doesn't find a correct matching document, we don't want to block the flow. The user can still set a document type himself through Odoo (if he has the aforementioned module installed) or direct
Original PR description
… is not set" This reverts commit fd1da69f8331dbc55be2d164fad381fca1622a67. The l10n_it_document_type belongs to `l10n_it_edi_ndd` module. This module exists to add this stored field that was missing. When the error that this commit tried to fix happens, which is due to the fact that the compute doesn't find a correct matching document, we don't want to block the flow. The user can still set a document type himself through Odoo (if he has the aforementioned module installed) or directly in the XML. Forward-Port-Of: odoo/odoo#184481
With this commit, the tour test_01_ui is fixed for differents tests triggers: community version and no demo data. 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#183578 Forward-Port-Of: odoo/odoo#183503
Original PR description
With this commit, the tour test_01_ui is fixed for differents tests triggers: community version and no demo data. 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#183578 Forward-Port-Of: odoo/odoo#183503
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
Original PR description
New image development was started in August but now being released in October, so bump version from 24.08 -> 24.10. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184318
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
Original PR description
Follow up of https://github.com/odoo/odoo/pull/171393 The method should forward all kwargs to the super call. Issue manifesting in particular in 18.0 when attempting to fix cloud storage at https://github.com/odoo/odoo/pull/184331 Forward-Port-Of: odoo/odoo#184506
Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatti
Original PR description
Issue: The `.o_default_snippet_text` class was not being removed when applying formatting (e.g., bold, italic, font-size) to a portion of the default text in an editable snippet. Steps to reproduce: 1. Insert a snippet with default placeholder text containing the `.o_default_snippet_text` class. E.g. A Banner. 2. Select part of the placeholder text (not the entire text). E.g. "Easily" in the "Banner" snippet 3. Apply a formatting command (bold, italic, font-size change). 4. The formatting is applied, but the `.o_default_snippet_text` class remains on the element. 5. Save and re-edit 6. Click on the title -> The text is entirely selected because it's still treated as a default text. This commit ensures the correct behaviour of this feature. task-4147162 Forward-Port-Of: odoo/odoo#183179
Before this commit: == - When there is no order line(s) in the order, a message saying 'Start adding products' along with a cart icon will be displayed on the receipt. After this commit: == - Added a check for the product image, which will be displayed when order line(s) exist. task - 4267700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184276
Original PR description
Before this commit: == - When there is no order line(s) in the order, a message saying 'Start adding products' along with a cart icon will be displayed on the receipt. After this commit: == - Added a check for the product image, which will be displayed when order line(s) exist. task - 4267700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184276
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#183814 Forward-Port-Of: odoo/odoo#183359
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#183814 Forward-Port-Of: odoo/odoo#183359
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to Invoicing > Configuration > Settings > Taxes > EU Intra-community Distance Selling > Click on Refresh tax mapping Traceback: ``` ValueError: Expected singleton: res.company(1, 2) File "odoo/http.py", line 2364, in __call__ response = request._serve_db() File "odoo/http.py",
Original PR description
When the user selects multiple companies and clicks on Refresh tax mapping, a traceback will appear. Steps to reproduce the error: - Install ``l10n_eu_oss`` module - Select multiple companies - Go to…
When the user selects multiple companies and clicks on Refresh tax mapping,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_eu_oss`` module
- Select multiple companies
- Go to Invoicing > Configuration > Settings > Taxes >
EU Intra-community Distance Selling > Click on Refresh tax mapping
Traceback:
```
ValueError: Expected singleton: res.company(1, 2)
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/l10n_eu_oss/models/res_config_settings.py", line 13, in refresh_eu_tax_mapping
self.env.companies._map_eu_taxes()
File "addons/l10n_eu_oss/models/res_company.py", line 34, in _map_eu_taxes
invoice_repartition_lines, refund_repartition_lines = company._get_repartition_lines_oss()
File "addons/l10n_eu_oss/models/res_company.py", line 105, in _get_repartition_lines_oss
self.ensure_one()
File "odoo/models.py", line 6213, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/bbcef64e3296efa2b985e8d08dfe0573dc62dbb4/addons/l10n_eu_oss/models/res_company.py#L32
Here, ``self`` is used instead of ``company``, When self has multiple companies,
It will lead to the above traceback.
sentry-6002997139
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#184491With this commit; the function previously called user_has_group is replaced by the method has_group and need to be called with res.users model not hr.employee model. task-4262917 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#183885
Original PR description
With this commit; the function previously called user_has_group is replaced by the method has_group and need to be called with res.users model not hr.employee model. task-4262917 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#183885
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#71860
Original PR description
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060 Forward-Port-Of: odoo/enterprise#71860
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position. Forward-Port-Of: odoo/enterprise#71857
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910 Forward-Port-Of: odoo/enterprise#69085
Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error We filter the subscriptions and handle them separately Forward-Port-Of: odoo/enterprise#72086
Original PR description
Right now, if all consolidated subscriptions are not invoicable or are free, the recurring invoice cron job fails due to a singleton error We filter the subscriptions and handle them separately Forward-Port-Of: odoo/enterprise#72086
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644 Forward-Port-Of: odoo/enterprise#72054
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71216
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71216
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Original PR description
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the controller route if the user goes to the portal list view of tasks via a specific project, that is, in the route `/my/projects/<id of the project selected>`. And so, some unexpected behavior could happen in `/my/tasks` since it will not be expected to have a project variable set in that route. This
Original PR description
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the…
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the controller route if the user goes to the portal list view of tasks via a specific project, that is, in the route `/my/projects/<id of the project selected>`. And so, some unexpected behavior could happen in `/my/tasks` since it will not be expected to have a project variable set in that route. This commit makes sure the variable created in `documents_project` will only be used inside that template and not beeing used in other override of that template in other modules (such as the one in `hr_timesheet`). Steps to reproduce the issue ============================ 1. Install `hr_timesheet` and `documents_project` modules 2. Go to `Project > Configuration > Projects` 3. Disable the timesheets feature on the first project. 4. Go to `/my/tasks` (portal list view of all tasks) Actual Behavior --------------- The cell containing the Time Spent of each task is hidden, causing a wrong alignment for the next cells in the same row. Moreover, the cell will be hidden even for the tasks with the timesheets feature enabled. Expected Behavior ----------------- The content of the cell containing the Time Spent of each task with the timesheets feature disabled should be hidden instead of the cell itself to avoid breaking the alignment of the next cells in the row. task-4259996 Forward-Port-Of: odoo/enterprise#72020
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#71688
Original PR description
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#71688
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be conside
Original PR description
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be considered by that line of the BS. Only affectation must also be considered from within the current fiscal year. Forward-Port-Of: odoo/enterprise#72021
When all the customers to print in the report share the same language, we need to print the report in that language. opw-4144771 Forward-Port-Of: odoo/enterprise#71435
Original PR description
When all the customers to print in the report share the same language, we need to print the report in that language. opw-4144771 Forward-Port-Of: odoo/enterprise#71435
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Original PR description
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#72391 Forward-Port-Of: odoo/enterprise#58487
Original PR description
In the Netherlands localization, the Balance Sheet and Profit&Loss reports are only currently built on account codes. We want to add another version of the accounting reports that uses account tags. Community PR: odoo/odoo#157362 Task link: https://www.odoo.com/web#model=project.task&id=3794536 task-3794536 Forward-Port-Of: odoo/enterprise#72391 Forward-Port-Of: odoo/enterprise#58487
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` wh
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393 Forward-Port-Of: odoo/enterprise#70800
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends t
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#72328 Forward-Port-Of: odoo/enterprise#70110
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72396
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72396
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only
Original PR description
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only. Fix --- Add condition to check if the field is non empty before casting. Forward-Port-Of: odoo/enterprise#71295
After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default. It should be set explicitly in the demo data. task-no Forward-Port-Of: odoo/enterprise#72122
Original PR description
After https://github.com/odoo/odoo/commit/ca5dc74def3760bbd08b81c2f723392c444dc677 the demo loading is not done by default. It should be set explicitly in the demo data. task-no Forward-Port-Of: odoo/enterprise#72122
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72358 Forward-Port-Of: odoo/enterprise#72343
Original PR description
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72358 Forward-Port-Of: odoo/enterprise#72343
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627