Daily updates from Odoo
Wednesday, November 6, 2024
59 changes · 18.0
Enhancements to existing features
The website editor now keeps image tooltips visible for as long as a visitor or editor keeps the cursor over the image. This makes image-related guidance easier to read and improves the editing experience without changing core business workflows.
Original PR description
This commit enhances tooltip behavior. Previously, the tooltip was displayed for only a brief period. Now, it remains visible as long as the cursor hovers over the image. task-4285601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Document workflow rules are being adjusted so they can be migrated more easily, especially when documents may be linked to different business records chosen at the time of use. Sign document template creation is also made more flexible, reducing migration friction for existing workflow configurations.
Original PR description
Workflow rule can be configured to link a document to any model (the user has to choose the model when executing the action). In order to migrate such workflow rule, we make the parameter model of the method action_link_to_record optional. Also to ease the conversion of workflow rule into server action, we make the folder_id optional on the method document_sign_create_sign_template_x of documents_sign. Task-4283330
This update prepares document workflow rules for migration by allowing some linking and signing setup details to be chosen later rather than required upfront. It helps existing document automation rules convert more reliably into the newer server action approach with minimal user-facing disruption.
Original PR description
Workflow rule can be configured to link a document to any model (the user has to choose the model when executing the action). In order to migrate such workflow rule, we make the parameter model of the method action_link_to_record optional. Also to ease the conversion of workflow rule into server action, we make the folder_id optional on the method document_sign_create_sign_template_x of documents_sign. Task-4283330
Resolved issues and error corrections
This fix prevents an error when users process a return for exchange from stock receipts without the Sales app installed. The exchange flow now works correctly in stock-only setups, avoiding an unexpected interruption for warehouse users.
Original PR description
Currently, a traceback occurs when the user tries to click return for exchange button. To reproduce this issue: 1) Install `stock` 2) Create a new receipt picking with stock moves and quantity 3) Click on the `validate` button and then the `return` button 4) Update the return quantity and click `return for exchange` Error:- ``` AttributeError: 'stock.move' object has no attribute 'sale_line_id' ``` The `sale_line_id` is defined in `stock.move` from `sale_stock` module. https://github.com/odoo/odoo/blob/2be7f413493a6ad43980eb031b8383deb3a706c0/addons/sale_stock/models/stock.py#L16-L17 If the sales module is not installed, then the move does not contain any sale_line_id. which leads to the traceback mentioned above. https://github.com/odoo/odoo/blob/2be7f413493a6ad43980eb031b8383deb3a706c0/addons/stock/wizard/stock_picking_return.py#L197 sentry-5993887458
This fix prevents Indonesian QRIS point-of-sale payments from crashing when the bank API key or merchant ID is configured incorrectly. Instead of a technical error, the system can handle the failed bank response more safely, helping cashiers continue troubleshooting payment setup issues.
Original PR description
This error occurs because the bank's QRIS API Key and Merchant ID were set up incorrectly. Steps to reproduce: --- - Install ``POS`` and ``l10n_id`` module - Change company to ``ID Company`` - Create…
This error occurs because the bank's QRIS API Key and Merchant ID were set up incorrectly. Steps to reproduce: --- - Install ``POS`` and ``l10n_id`` module - Change company to ``ID Company`` - Create a new ``Warehouse`` in Inventory - Now create a new journal(eg: Test) in invoicing with ``Type`` as ``Bank`` > go to the internal link of ``Account Number`` write any ``QRIS API Key`` and ``QRIS Merchant ID`` and Save - Now go to ``Payment Methods`` and create a new one in POS(eg: Demo) with ``Integration`` as ``qr_code`` and ``QR Code Format`` as ``QRIS`` > Select ``Journal`` as ``Test`` and Save - Go to ``Clothes`` > Open Session > Add product > Payment > select payment method as ``Demo`` > Click ``retry`` Traceback: --- ``AttributeError: 'str' object has no attribute 'get'`` At [1], we are facing an error because ``data`` contains the failed message in it, and the status of the response is ``failed``. [1]- https://github.com/odoo/odoo/blob/dd71d998796cf426527972a3feac6fdd040f3fe3/addons/l10n_id/models/res_bank.py#L101 sentry-6029900658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adds helpful descriptions to several project top bar actions linked to manufacturing, stock, and purchasing. Users can better understand actions such as Bills of Materials, warehouse transfers, stock moves, and purchase orders before opening them.
Original PR description
Add helpers for the following actions: - Bills of Materials - To WH - From WH - Stock Moves - Purchase Orders task-4210573 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sales team warning now appears only when a person is actually already assigned to another team in single-team mode. This prevents confusing or incorrect alerts when adding unsaved members and makes the warning text clearer for users.
Original PR description
Purpose ======= Fix the team member warning which was indicating the wrong members. Specification ============= The warning only needs to appear when you add a member which is already in another team (only in mono-membership mode). When you add a new member without saving, the team 'id' field is of type NewID, not simply an id of type integer. This was messing up the search domain as the crm_team_id was for example 1 and the team.id was NewID with origin 1. They were evaluated "different" even though they are the same. Fixing that by accessing the record's origin so that we always compare ids as integers. Also rewording a bit the warning to prevent using him/her and more precisely specifying where to activate the multi team option. Task-4283552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Accounting settings now show the company-specific icon for two options that only apply to the currently selected company. This helps users understand that changing these invoice-related settings will not affect other companies in the database.
Original PR description
In Settings, the fields `total_amount_words` and `display_invoice_tax_company_currency` are linked to the company, but the "company-specific" icon was missing. Adding this icon informs users that enabling these settings only affects the currently selected company. task-4297925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents errors when customers edit their address during checkout on Peruvian localized websites. It ensures the required Peru-specific address fields are available, allowing purchases to be completed smoothly.
Original PR description
- Change the company of the first website to the localized company - Open web shop as public user - Make a purchase - Checkout and fill the address - Edit the address - Confirm Issue: Traceback will raise because of the missing localization fields opw-4232531 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue in Odoo Discuss where the 'jump to present' button could move to the wrong spot after opening thread actions or resizing the window. Users now get a more consistent chat navigation experience without visual glitches.
Original PR description
**Current behavior before PR:** When the `jump to present` button was visible and the user opened any thread actions, the button appeared in the wrong position.The issue occurred because the transform style was not being recalculated when the active action changed. Before / After <p> <img src="https://github.com/user-attachments/assets/cf3d4051-20e6-428e-8bba-237e8ef03e8e" width="200px" /> <img src="https://github.com/user-attachments/assets/6e7f1ca0-6adf-4177-a7ea-dd1f7968702d" width="200px" /> </p> **Desired behavior after PR is merged:** After this PR, the transform style is correctly calculated, ensuring the `jump to present` button is properly positioned when thread actions are opened. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adjusts an internal asset bundle test so it no longer assumes the website app is installed. It helps keep automated testing reliable in setups where website features are not enabled, without changing business functionality.
Original PR description
When website is not installed and the user is logged in, the frontend is not loaded by the client making the test `test_assets_bundle_css_error_frontend` invalid (frontend assets are not loaded on backend pages).
This fixes an issue in the website editor where highlighted title text could lose its underline thickness after swapping a snippet and then undoing the action. The change helps preserve the intended page design and prevents unexpected formatting changes while editing website content.
Original PR description
Steps to reproduce: - Drop "Title" snippet. - Select "Highlight" from toolbar. - Select those highlight which have underline thickness of non zero. - Now use swap snippet button. (yellow button) - Now undo the last step. - Notice underline has lost its thickness. After this commit: - highlighted text is no longer losing thickness of underline after swapping and undo. task-4219461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing users can now post a work-in-progress accounting entry even when a work order's time tracking has been started but not ended. This prevents an error screen and keeps the manufacturing accounting workflow moving smoothly.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown  after this commit, no traceback wont be shown in the above scenario Related EE: https://github.com/odoo/enterprise/pull/72345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a point-of-sale issue where restaurant receipts could show zero change after customers overpaid for orders that had already been sent to the kitchen. Receipts now display the correct amount of change, reducing cashier confusion and improving customer trust.
Original PR description
When using the restaurant, orders that were sent to the kitchen did not show the change amount on the receipt. Steps to reproduce: ------------------- * Open restaurant * Select any table, add items…
When using the restaurant, orders that were sent to the kitchen did not show the change amount on the receipt. Steps to reproduce: ------------------- * Open restaurant * Select any table, add items to the order * Select **Order** * Select **Payment** * Select any payment method * Pay more than the order * Validate > Observation: The receipt show a change of 0.0 Why the fix: ------------ Before this commit: https://github.com/odoo/odoo/commit/1649ee1a757ab1a095fd92f7605ac2b004568352 the change could get computed on an onchange: https://github.com/odoo/odoo/blob/662f63b630cae8604179174cdd67536f3300bb53/addons/point_of_sale/models/pos_order.py#L417-L427 By definiton, onchanges will only trigger from web form views. In our case, the onchange was never triggered when synchronizing orders from the UI, even though we would make a change to the payment_ids when adding the change line. After the above mentioned commit, the code inside the onchange was put into a separate function `_compute_prices()` which is still called in the onchange but also in the `write` function. When an order was previously synced from the UI, we call the write function. https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L124 By going into `_compute_prices` in the write method, we compute the `amount_return` before the change line was added to the order. https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L128 Computing `amount_return` before adding the change line is problematic since it is computed with regards to the negative payment lines. https://github.com/odoo/odoo/blob/430656132044f8d675712d5b6cbfef807880d024/addons/point_of_sale/models/pos_order.py#L440 To solve our solution, we call `_compute_prices` after we add the change line. `amount_return` represents the change given to a client. If we give `10$` back to a client, the change payment line will have an amount of `-10$` but `amount_return` should be positive 10. (Thus the change of `-`) We also add a small fix for `amount_difference` which can have precision error and thus show something like `-0.0`. opw-4253292
This update corrects a condition used when handling sales order lines tied to subscription timesheets. It helps prevent incorrect behavior in subscription-related timesheet sales flows, improving reliability for affected users.
Six payment terminal setup now sends the IoT Box request from the user's browser instead of through the server. This helps configuration succeed when the IoT Box is reachable from the customer site but not from the hosted Odoo server.
Original PR description
The wizard to configure a Six payment terminal currently sends a request to the IoT Box via the server. However, often the IoT Box is not on the same network as the server so this request fails. This PR moves the request logic into a JS widget, so as long as the client can reach their IoT Box the Terminal configuration should succeed. task-4214070
Creating invoices or sales orders for Brazilian customers using Avalara automatic tax mapping no longer triggers an error when no lines have been added yet. This prevents a blocking crash and lets users continue preparing documents normally with external tax configuration.
Original PR description
Issue: A traceback occurs when attempting to create an invoice or sales order for a customer whose fiscal position is set to Automatic Tax Mapping in Brazilian accounting. ```python File…
Issue: A traceback occurs when attempting to create an invoice or sales order for a customer whose fiscal position is set to Automatic Tax Mapping in Brazilian accounting. ```python File "/home/odoo/src/enterprise/account_external_tax/models/account_move.py", line 18, in _compute_tax_totals subtotal = tax_totals['subtotals'][0] ~~~~~~~~~~~~~~~~~~~~~~~^^^ IndexError: list index out of range ``` Steps to reproduce: - Have Brazilian localization (including EDI modules) with Avatax configuration. - Create a new Sales Order or Invoice and: - Use a contact with a fiscal position set to "Automatic Tax Mapping (Avalara Brazil)", or - Set the fiscal position to that on the SO or invoice itself. - Observe the traceback as described in the ticket. Explanation: In account_move/sale_order from the modules account_external_tax/sale_external_tax, the method _compute_tax_totals attempted to compute the tax totals when there were no account move lines (tax_totals['subtotals'] is empty), which results in an "out of range" traceback. The Brazilian Automatic Tax Mapping is computed externally, which is why it triggered this issue. opw-4256191
Users signing documents without logging in will no longer see an unexpected session expiration pop-up. This fixes a check in the Sign app so public signing flows correctly handle missing user information.
Original PR description
**Steps to reproduce:** 1. send a sign request to the user. 2. attempt to sign a document without logging in. **Issue:** Session expiration pop-up appears unexpectedly. **Cause:** Due to recent improvements, the userId is not being retrieved as expected. **Fix:** Modify the condition to handle cases where userId is either null or false. task-4178827
The signing interface now keeps the attachment input at its natural size instead of stretching across the full row. This removes a visual glitch and makes the attachment area clearer and easier to use.
Original PR description
Before this PR, the oe_add class caused the input field to stretch across the entire line. After this PR, adjustments to the class ensure it only takes up the necessary space. task-4223539
Users can now request documents directly from My Drive, fixing a limitation in the Documents app. This makes document collection more consistent and reduces confusion for teams working from their personal drive area.
Original PR description
Allow requested documents from `My Drive`. Task-4297530
Manufacturing users can now post a work-in-progress accounting entry even when a work order is still being tracked without an end time. This prevents an unexpected error screen and keeps the manufacturing accounting workflow from being interrupted.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
Miscellaneous changes
Steps to reproduce the bug: 1. Go to Website and select My Account 2. Press Edit Information 3. State/Province field doesn't populate The reason why: The state `option` elements are by default all hidden using `display: none`, and in JS we only show the states by the selected country, using JQuery's `show` method. In 17.2, we were hiding the `option` with `style="display:none;"` and that worked well. However, in 17.4, `option` elements were hidden in commit https://github.com/odo
Original PR description
Steps to reproduce the bug: 1. Go to Website and select My Account 2. Press Edit Information 3. State/Province field doesn't populate The reason why: The state `option` elements are by default all hidden using `display: none`, and in JS we only show the states by the selected country, using JQuery's `show` method. In 17.2, we were hiding the `option` with `style="display:none;"` and that worked well. However, in 17.4, `option` elements were hidden in commit https://github.com/odoo/odoo/commit/da2c32470c63b8a45ddfb3565c158feece33c924 using the bootstrap class `d-none` (to cleanup the code), which also does `display: none`, but adds `!important` to it, making JQuery's `show` method useless. The fix: Manually removing `d-none` class with JQuery's `removeClass`. opw-4275240 Forward-Port-Of: odoo/odoo#184905
To reproduce: ============= - with service product S with create project & task - create sale order with that product - with another service product E with Re-invoice Expenses at cost - create expense with this product and link it to the first sale order - go back to sale order, we find product E added to sale order - create invoice and post it Problem: ======== on project updates we have the expense + the customer invoice which gives wrong profits in stats Solution: ========= e
Original PR description
To reproduce: ============= - with service product S with create project & task - create sale order with that product - with another service product E with Re-invoice Expenses at cost - create expense with this product and link it to the first sale order - go back to sale order, we find product E added to sale order - create invoice and post it Problem: ======== on project updates we have the expense + the customer invoice which gives wrong profits in stats Solution: ========= exclude the customer invoice from the revenues when it's linked to an expense, as the expense is already included in the revenues opw-4000095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186205 Forward-Port-Of: odoo/odoo#182165
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in the next commit. opw-3959983 ---------------------------------------------------------------------------------------------------------------------------------------------- [FIX] web_editor,*: forbid the change of image field by webp CORS image *: website_sale The goal of this commit
Original PR description
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in…
[MOV] web_editor, website: move isImageCorsProtected function in utils The goal of this commit is to move the `isImageCorsProtected()` function in the `web_editor` utils as it is will be needed in the next commit. opw-3959983 ---------------------------------------------------------------------------------------------------------------------------------------------- [FIX] web_editor,*: forbid the change of image field by webp CORS image *: website_sale The goal of this commit is to avoid that a user replaces an image field by a webp CORS protected image (e.g. https://www.gstatic.com/webp/gallery/1.webp). There are two main reasons for that: - As explained in [1], the resized images have to be generated when a webp image has been uploaded. This is something that we are currently not able to do for CORS protected images. - As explained in [2], a jpeg image has to be generated when a webp image has been uploaded. This is also something that we are currently not able to do for CORS protected images. We also apply the same logic for the addition of extra product images. Indeed, in this case, when choosing an image among the existing attachments or when uploading new images, we can not rely on DOM information to determine if the changed image is an image field as the image is not already part of the DOM. [1]: https://github.com/odoo/odoo/commit/0ba3617f9dacf2a63288b30245a610782d943c5a [2]: https://github.com/odoo/odoo/commit/c035d0003d09289fde0aabcb21849c2914524c01 opw-3959983 ----------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] website_sale: avoid converting some extra images to webp Steps to reproduce the bug: - Go on a product page. - Enter in edit mode and click on "Add Extra Images". - Click on "Add URL" and upload an external CORS protected image (e.g. https://tinyjpg.com/images/social/website.jpg). - Click on "Add" to use this image as an external image. -> Error. Since [3], images uploaded through the website builder that are neither gif nor svg are converted to the webp format by default except if those images are CORS protected. The goal of this commit is to adapt [4] to follow the same logic and not convert uploaded product extra image to webp if the image is CORS protected. [3]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d [4]: https://github.com/odoo/odoo/commit/b284293c18b6bcdafe2bda989c5e0a084d1acbd1 opw-3959983 Forward-Port-Of: odoo/odoo#186210 Forward-Port-Of: odoo/odoo#169628
Steps to reproduce: - Drag and drop any snippet with image in it. - Select image and crop image using transform option. - Click replace button. - Image selection popover won't open. After this commit: - The "preserveCursor" method has been used to maintain the cursor state because transform option was losing cursor selection. task-3930743 Forward-Port-Of: odoo/odoo#167338
Original PR description
Steps to reproduce: - Drag and drop any snippet with image in it. - Select image and crop image using transform option. - Click replace button. - Image selection popover won't open. After this commit: - The "preserveCursor" method has been used to maintain the cursor state because transform option was losing cursor selection. task-3930743 Forward-Port-Of: odoo/odoo#167338
If you create a product with a cost and type combo, and you sell it in the PoS. The margin would not be 0 but it should always be 0 as this is the combo product. Steps to reproduce: ------------------- * Create a product, and set a cost on it * Change the product type to combo * Open PoS and sell this product * Go back to the order list > Observation: On the order you just made you will see that the margin for the combo product is not 0. Why the fix: ------------ We make sure to a
Original PR description
If you create a product with a cost and type combo, and you sell it in the PoS. The margin would not be 0 but it should always be 0 as this is the combo product. Steps to reproduce: ------------------- * Create a product, and set a cost on it * Change the product type to combo * Open PoS and sell this product * Go back to the order list > Observation: On the order you just made you will see that the margin for the combo product is not 0. Why the fix: ------------ We make sure to always set the margin to 0 for combo products. Actually combo product should never have a cost, but if you set a cost before changing it's type to combo it would be the case. opw-4171177 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186170
Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings. Rather than that, if the picking type already exist, we use its sequence_code instead of the default one. Related to: opw-4245938 opw-4264520 --- I conf
Original PR description
Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings. Rather than that, if the picking type already exist, we use its sequence_code instead of the default one. Related to: opw-4245938 opw-4264520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186051 Forward-Port-Of: odoo/odoo#185966
Currently, the _create_next_occurence_values method is always called, even if no next occurences need to be created. This is bad, because if the next condition in the code is falsy, we would have created child tasks for nothing since childs are created using copy() in the method to handle recursion. This PR will fix it by checking beforehand if any next occurence should be made, and call _create_next_occurrence_values only if so. task-4269547 Forward-Port-Of: odoo/odoo#185863
Original PR description
Currently, the _create_next_occurence_values method is always called, even if no next occurences need to be created. This is bad, because if the next condition in the code is falsy, we would have created child tasks for nothing since childs are created using copy() in the method to handle recursion. This PR will fix it by checking beforehand if any next occurence should be made, and call _create_next_occurrence_values only if so. task-4269547 Forward-Port-Of: odoo/odoo#185863
This PR updates l10n_uy by adding 22% and 10% VAT-included tax options for sales and purchases, supporting Uruguay’s practice of using both tax-included and tax-excluded amounts per document. The data aligns with XML requirements by specifying VAT inclusion at the document level, enabling accurate automatic vendor bill creation from XML imports. Task Adhoc side: 43467 Task latam side: 1282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
This PR updates l10n_uy by adding 22% and 10% VAT-included tax options for sales and purchases, supporting Uruguay’s practice of using both tax-included and tax-excluded amounts per document. The data aligns with XML requirements by specifying VAT inclusion at the document level, enabling accurate automatic vendor bill creation from XML imports. Task Adhoc side: 43467 Task latam side: 1282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184940
In no-demo tests, there is no link tracker, so the expected length is not max+1 but 3. Follow up of e5b88d3a Task-3502174 Forward-Port-Of: odoo/odoo#174391 Forward-Port-Of: odoo/odoo#173303
Original PR description
In no-demo tests, there is no link tracker, so the expected length is not max+1 but 3. Follow up of e5b88d3a Task-3502174 Forward-Port-Of: odoo/odoo#174391 Forward-Port-Of: odoo/odoo#173303
When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong. Related ticket for which this would have been helpful: #4276907 Forward-Port-Of: odoo/odoo#185535
Original PR description
When an exception occurred during a request to IAP, there was no way of knowing which one it was exactly. This log should help understand what went wrong. Related ticket for which this would have been helpful: #4276907 Forward-Port-Of: odoo/odoo#185535
__Current behavior before commit:__ Events with products that use a pricelist with `discount_policy` set `without_discount` cause 403 for public users on event pages if website setting `show_line_subtotals_tax_selection` = `tax_included`. __Reason:__ This is because of access right issues on taxes for `price_incl` being displayed on the event page. __Fix:__ Added `compute_sudo=True` to the field `price_incl`. __Steps:__ 1. Create new product `detailed_type` `event` with a high pri
Original PR description
__Current behavior before commit:__ Events with products that use a pricelist with `discount_policy` set `without_discount` cause 403 for public users on event pages if website setting…
__Current behavior before commit:__ Events with products that use a pricelist with `discount_policy` set `without_discount` cause 403 for public users on event pages if website setting `show_line_subtotals_tax_selection` = `tax_included`. __Reason:__ This is because of access right issues on taxes for `price_incl` being displayed on the event page. __Fix:__ Added `compute_sudo=True` to the field `price_incl`. __Steps:__ 1. Create new product `detailed_type` `event` with a high price Ex:100. 2. Set the website pricelist entry for this price as lower price Ex:50. 3. Change pricelist `discount_policy` to `without_discount`. 4. Change website setting: (Display Product Price) to (Tax Included) 4. Create event with custom product. 5. Publish event and view the event page from a public user. opw-4264353 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#185970 Forward-Port-Of: odoo/odoo#184893
The grid layout in attachment list makes the non attachment list view look broken. This commit removes the grid from this view. Steps to reproduce: - open a discuss channel - add some non image attachments - go to the attachments list Backport of https://github.com/odoo/odoo/pull/186033 Forward-Port-Of: odoo/odoo#186364
Original PR description
The grid layout in attachment list makes the non attachment list view look broken. This commit removes the grid from this view. Steps to reproduce: - open a discuss channel - add some non image attachments - go to the attachments list Backport of https://github.com/odoo/odoo/pull/186033 Forward-Port-Of: odoo/odoo#186364
Ease adding voice metadata through message_post. Task- Forward-Port-Of: odoo/odoo#186335 Forward-Port-Of: odoo/odoo#186244
Original PR description
Ease adding voice metadata through message_post. Task- Forward-Port-Of: odoo/odoo#186335 Forward-Port-Of: odoo/odoo#186244
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this commit: In [2]: float_round(0.57,2) Out[2]: 0.57 ``` Now, while executing this line of code https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244 ``` Before: In [3]: 0.5700000000000001*100//1 Out[3]: 57.0 After: In [3]: 0.57*
Original PR description
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this…
After this commit 784f1511 , The `float_round()` functionality is changed. Before this commit, If the `qty_available` is 0.57: ``` In [2]: float_round(0.57,2) Out[2]: 0.5700000000000001 After this commit: In [2]: float_round(0.57,2) Out[2]: 0.57 ``` Now, while executing this line of code https://github.com/odoo/odoo/blob/baea953d248471e8aef60e02c1216f77941f1951/addons/mrp/models/product.py#L244 ``` Before: In [3]: 0.5700000000000001*100//1 Out[3]: 57.0 After: In [3]: 0.57*100//1 Out[3]: 56.0 ``` These differences leads to blocking the upgrade process. ``` Traceback (most recent call last): File "/tmp/tmpft9eq3rf/migrations/testing.py", line 212, in test_check self.check(value) File "/tmp/tmpft9eq3rf/migrations/stock/tests/test_on_hand_quantity.py", line 90, in check self.assertEqual(before_results, self.convert_check(after_results), self.message) AssertionError: Lists differ: [[12,[7979 chars]6, '57'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] != [[12,[7979 chars]6, '56'], [20249, '17.06'], [20250, '1705'], [[12354 chars]'1']] First differing element 529: [20246, '57'] [20246, '56'] ``` upg-2096343 opw-4224012 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#185964 Forward-Port-Of: odoo/odoo#183289
Steps to reproduce the bug: - Create a storable product “P1”: - tracked by serial number - Update the quantity with SN1 - Create a delivery: - Customer: Azure Interior - Product: P1 with SN1 - Validate the delivery - Create a return to WH/Stock and validate it - Go to the serial number Problem: The location is not updated and displays the partner location instead of WH/Stock. opw-4285271 Forward-Port-Of: odoo/odoo#186067 Forward-Port-Of: odoo/odoo#185917
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- tracked by serial number
- Update the quantity with SN1
- Create a delivery:
- Customer: Azure Interior
- Product: P1 with SN1
- Validate the delivery
- Create a return to WH/Stock and validate it
- Go to the serial number
Problem:
The location is not updated and displays the partner location instead of WH/Stock.
opw-4285271
Forward-Port-Of: odoo/odoo#186067
Forward-Port-Of: odoo/odoo#185917Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#186056 Forward-Port-Of: odoo/odoo#181333
Original PR description
Monaco is sharing the same CoA as France, therefore we should use l10n_fr when installing account with a company from Monaco. opw-4197369 Forward-Port-Of: odoo/odoo#186056 Forward-Port-Of: odoo/odoo#181333
[FIX] l10n_cl: display the document type border correctly Steps to reproduce: 1 - In the chilean localization create an invoice (with a long text document type). 2 - Preview The observed behaviour: - The right side of the border of the document type would go out of the view. This Fix would just make the maximum width of the said border to never exceed its container. opw-4278374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
[FIX] l10n_cl: display the document type border correctly Steps to reproduce: 1 - In the chilean localization create an invoice (with a long text document type). 2 - Preview The observed behaviour: - The right side of the border of the document type would go out of the view. This Fix would just make the maximum width of the said border to never exceed its container. opw-4278374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185310
…Exempt tax for sale and purchase Description of the issue/feature this PR addresses: The current GST/HST report tax report (Canada) have a missing lines for 90 and 91 as per the Canada Revenue agency Instructions of tax report Added Exempt tax which is 0% in the Exempt category: More info found at: https://www.canada.ca/en/revenue-agency/services/forms-publications/publications/rc4022/general-information-gst-hst-registrants.html#H1_106 More details for lines 90, 91, and 101: https:
Original PR description
…Exempt tax for sale and purchase Description of the issue/feature this PR addresses: The current GST/HST report tax report (Canada) have a missing lines for 90 and 91 as per the Canada Revenue…
…Exempt tax for sale and purchase Description of the issue/feature this PR addresses: The current GST/HST report tax report (Canada) have a missing lines for 90 and 91 as per the Canada Revenue agency Instructions of tax report Added Exempt tax which is 0% in the Exempt category: More info found at: https://www.canada.ca/en/revenue-agency/services/forms-publications/publications/rc4022/general-information-gst-hst-registrants.html#H1_106 More details for lines 90, 91, and 101: https://www.canada.ca/en/revenue-agency/services/tax/businesses/topics/gst-hst-businesses/complete-file-instructions.html#lines909102 Current behavior before PR: Current Tax report missing line 90 and 91: Desired behavior after PR is merged: The tax report should have lines 90 and 91 and line 101 computed based on lines 90 and 91. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186330 Forward-Port-Of: odoo/odoo#184597
Steps to reproduce: - Project app > New Project > New Task - On Task > Subtask tab > Add subtask > Save - On Subtask > Timesheets tab > Record a timesheet - On task > Print timesheets The report shows a line for Task with no timesheets in saas-17.2 and saas-17.4, while it is completely blank in 18.0 (Due to an extra condition added in https://github.com/odoo/odoo/pull/178397). We'd expect only tasks with recorded timesheets to be on the report, regardless of whether their parent tasks
Original PR description
Steps to reproduce: - Project app > New Project > New Task - On Task > Subtask tab > Add subtask > Save - On Subtask > Timesheets tab > Record a timesheet - On task > Print timesheets The report shows a line for Task with no timesheets in saas-17.2 and saas-17.4, while it is completely blank in 18.0 (Due to an extra condition added in https://github.com/odoo/odoo/pull/178397). We'd expect only tasks with recorded timesheets to be on the report, regardless of whether their parent tasks are there or not. Additionally, since subtasks can now appear without parent, the titles have been updated to make tarcking subtask origin easier. opw-4292481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185946
Steps to reproduce: - Install Project and sale_timesheet - Create a project with Timesheet option enabled - Go to that project's setting and allocate hours - Gear Icon > Duplicate The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself. opw-428495
Original PR description
Steps to reproduce: - Install Project and sale_timesheet - Create a project with Timesheet option enabled - Go to that project's setting and allocate hours - Gear Icon > Duplicate The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself. opw-4284950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186292 Forward-Port-Of: odoo/odoo#185890
Steps to reproduce: - Install hr_homeworking - Livechat app > website.com > Configure channels - Mitchell Admin must be among the operators - Employees > Mitchell Admin > Work information tab - Set a 'Remote work' location for the current day - Website app > The livechat popup does not appear (bottom-left) This happens because hr_homeworking changes the im_status field's value to from 'online' to 'presence_[location_type]_online'. That change was not reflected by the function which comp
Original PR description
Steps to reproduce: - Install hr_homeworking - Livechat app > website.com > Configure channels - Mitchell Admin must be among the operators - Employees > Mitchell Admin > Work information tab - Set a 'Remote work' location for the current day - Website app > The livechat popup does not appear (bottom-left) This happens because hr_homeworking changes the im_status field's value to from 'online' to 'presence_[location_type]_online'. That change was not reflected by the function which computes operator availability, meaning the operator will never show as online on days they have a location set. Additionally, im_status 'leave_online' should not be considered as a status that marks available operators. Unfortunately, since locations can be created at will we can't make an exhaustive list here. opw-4196707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184447
Steps to reproduce ------------------ 1. Create a SO with a product with with the "Prepaid" Invoice Policy and "Hours" unit that creates a task in a project. 2. Create a new billable project and a task in that project, and set the partner of the SO created earlier on the new task. 3. Set the SOL of the SO from step 1 on the task. 4. Check that in the Timesheets notebook, you see a value for "Time Remaining on SO". 5. Go to the reporting and group by project, and display the "Time Remaining
Original PR description
Steps to reproduce ------------------ 1. Create a SO with a product with with the "Prepaid" Invoice Policy and "Hours" unit that creates a task in a project. 2. Create a new billable project and a task in that project, and set the partner of the SO created earlier on the new task. 3. Set the SOL of the SO from step 1 on the task. 4. Check that in the Timesheets notebook, you see a value for "Time Remaining on SO". 5. Go to the reporting and group by project, and display the "Time Remaining on SO". 6. There is a value for the project generated by the SO, but not for the one created manually. --- This bug occurs because we only account for the task generated by a SOL of the SO when computing the remaining hours on SO in the reporting. This PR fixes the way it is computed. Task-4280965 Forward-Port-Of: odoo/odoo#184915
Steps to reproduce: - Install Project and sale_timesheet and Accounting - Settings > Enable 'Analytic Accounting' - Create a service product generating a project and task - New Product > Set 'Re-invoice Expenses' to 'Cost' - (If you have hr_expense you need to tick 'Can be expensed') - Create a new quotation for your project generating product > Confirm - Accounting > Vendors > Bills > New > Add your expense product - Set the analytic distribution to your project's (S000... - Customer)
Original PR description
Steps to reproduce: - Install Project and sale_timesheet and Accounting - Settings > Enable 'Analytic Accounting' - Create a service product generating a project and task - New Product > Set…
Steps to reproduce: - Install Project and sale_timesheet and Accounting - Settings > Enable 'Analytic Accounting' - Create a service product generating a project and task - New Product > Set 'Re-invoice Expenses' to 'Cost' - (If you have hr_expense you need to tick 'Can be expensed') - Create a new quotation for your project generating product > Confirm - Accounting > Vendors > Bills > New > Add your expense product - Set the analytic distribution to your project's (S000... - Customer) - Fill in Vendor, Bill Date and Price with arbritrary values > Confirm - Project > ':' Menu on your project's card > Project Updates The analytic line created on vendor bill confirmation is also linked to the sale order line created by the re-invoiced product on the original SO. This error notably does not occur without the sale_timesheet module, and the same flow with hr_expense instead of a vendor bill works flawlessly. Project Updates shows the expense twice under Costs because unlike with the hr_expense module, no expense_id is linked to the account_move_line (Since regular vendor bills do no handle that field). This means we fail to filter the analytic_line in `_get_profitability_aal_domain`, thus reading the same update analytic line and deducting the amount twice. Given that the vendor bill was meant to be treated as an expense, and that the same flow using hr_expense instead of a vendor bill results in only 1 line of costs, we want to replicate that behavior here, but we don't have a clean way to filter for these types of analytic lines. As a workaround we use the property of `_get_costs_items_from_purchase` to label updates in the 'other_purchase_costs' category to single out vendor bill updates and skip processing them the second time they come up. opw-4042729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180589
Before this commit, some unnecessary attributes might be loaded. This change ensures that only the required attributes are loaded, improving efficiency and performance. opw-4298915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186022
Original PR description
Before this commit, some unnecessary attributes might be loaded. This change ensures that only the required attributes are loaded, improving efficiency and performance. opw-4298915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186022
Issue Summary: During the upgrade from Odoo version 16.0 to 17.0, a discrepancy has emerged in the product configuration, specifically with the "Buy" route. The problem arises when computing the available quantity using the _compute_quantities_dict function. see: https://github.com/odoo/odoo/commit/6d8f184f09c213be068f911dd327ffe84fde8bab Problem Description: In version 17.0, when fetching the domain_Quant using the _get_domain_locations function, the domain returned is ('location
Original PR description
Issue Summary: During the upgrade from Odoo version 16.0 to 17.0, a discrepancy has emerged in the product configuration, specifically with the "Buy" route. The problem arises when computing the…
Issue Summary:
During the upgrade from Odoo version 16.0 to 17.0, a discrepancy has emerged in the product configuration, specifically with the "Buy" route.
The problem arises when computing the available quantity using the _compute_quantities_dict function.
see:
https://github.com/odoo/odoo/commit/6d8f184f09c213be068f911dd327ffe84fde8bab
Problem Description:
In version 17.0, when fetching the domain_Quant using the _get_domain_locations function, the domain returned is ('location_id', 'any', [(0, '=', 1)])
if no locations are found.
In version 16.0, it returns an empty list [] if no locations are found. This change results in the domain_quant in version 17.0 being
[('product_id', 'in', [2684, 5474, 5475, 5478, 5487, 5522]), ('location_id', 'any', [(0, '=', 1)])],
which leads to {} values, whereas in version 16.0, the domain
would be [('product_id', 'in', [2684, 5474, 5475, 5478, 5487, 5522])], which returns actual values.
Impact:
The inconsistency in the domain operation between versions results in incorrect or missing quantity data after the upgrade, affecting the accuracy of product availability.
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#175116Description 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#186262
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186262
Steps to reproduce ================== - Install crm - Go to CRM - Open a record - Open actions menu (cog icon next to breadcrumbs) - Add Properties - Set a value to the new property - Go back to kanban view - Switch to list view - Check the property field in optional columns menu to show the column - Remove "My Pipeline" filter - Add "My Pipeline" filter - The property column does not exist anywhere anymore Cause of the issue ================== The relational model adds mod
Original PR description
Steps to reproduce ================== - Install crm - Go to CRM - Open a record - Open actions menu (cog icon next to breadcrumbs) - Add Properties - Set a value to the new property - Go back to kanban view - Switch to list view - Check the property field in optional columns menu to show the column - Remove "My Pipeline" filter - Add "My Pipeline" filter - The property column does not exist anywhere anymore Cause of the issue ================== The relational model adds model info in a global shared field definition object and then list renderer uses these info for properties fields. The search bar also uses this object and adds properties fields info. Both are adding and using incompatible info. Solution ======== Define correctly the minimum acceptable of the properties definitions when needed in the model and do not add model info in these definitions. opw-4264560 Forward-Port-Of: odoo/odoo#186268 Forward-Port-Of: odoo/odoo#185828
Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185843 Forward-Port-Of: odoo/odoo#185807
Original PR description
Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185843 Forward-Port-Of: odoo/odoo#185807
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argenti
Original PR description
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send…
## [FIX] l10n_ar: prevent errors from deleted tax group When users delete the tax group `tax_group_percepcion_ganancias` while using the Argentinian localization, it will an error when trying to send an electronic invoice or generate the VAT books, since it depends on this specific tax group. There is no clearer way to identify this tax group than by its XML ID. This commit does two things: 1. It prevents users from deleting this required tax group when the company is using the Argentinian localization. 2. If the tax group was already removed, it will show a useful error message when it can't be found and redirect the user to the settings where they can reload their chart template in order to reinstall the tax group. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3685073](https://www.odoo.com/odoo/all-tasks/3685073) ## [FIX] account: fallback on company data when loading chart template Currently when loading a chart template for a company which is referencing some records by XML ID, we look for these records in the database. This could fail in some cases, like this: - We have a company set up with a CoA and delete one of its default accounts in the company settings and replace it by another account. - We try to create a branch company under the former one. When trying to save the branch company, we try loading the chart template on it, setting also the default accounts. We look in the database for the right reference, but since the parent company deleted the original account, the process fails and the branch can't be created. In this commit we provide a sensible fallback. If the record referenced in the chart template can't be found, we try looking what was already set on the company or its root. As such, we will be able to create the branch successfully and the user can always adapt the defaults later. [task-3853596](https://www.odoo.com/odoo/all-tasks/3853596) [opw-3677061](https://www.odoo.com/odoo/all-tasks/3677061) [opw-3681481](https://www.odoo.com/odoo/all-tasks/3681481) [opw-3681456](https://www.odoo.com/odoo/all-tasks/3681456) [opw-3672507](https://www.odoo.com/odoo/all-tasks/3672507) [opw-3669164](https://www.odoo.com/odoo/all-tasks/3669164) [opw-3694606](https://www.odoo.com/odoo/all-tasks/3694606) [opw-3705870](https://www.odoo.com/odoo/all-tasks/3705870) [opw-3704826](https://www.odoo.com/odoo/all-tasks/3704826) Forward-Port-Of: odoo/odoo#186091 Forward-Port-Of: odoo/odoo#183609
Description of the issue/feature this PR addresses: Described in #184497 Current behavior before PR: Error when selecting a template that contains field you don't have access to Desired behavior after PR is merged: No error occurs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184943
Original PR description
Description of the issue/feature this PR addresses: Described in #184497 Current behavior before PR: Error when selecting a template that contains field you don't have access to Desired behavior after PR is merged: No error occurs --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184943
Fixed onboarding Email Marketing tour which is not working properly. Reason ====== We're not getting this `'input[name="subject"]',` trigger for some reasons, & there is no `name` attribute with input. we do have `id` in input, but in v16 we got id as `subject` and v17+ gets `subject_0` so that can't be used. Also, the next trigger should be after user click on input field not when they write. One more point, sometimes it got stuck after selecting a theme and did not shows the pointer
Original PR description
Fixed onboarding Email Marketing tour which is not working properly. Reason ====== We're not getting this `'input[name="subject"]',` trigger for some reasons, & there is no `name` attribute with input. we do have `id` in input, but in v16 we got id as `subject` and v17+ gets `subject_0` so that can't be used. Also, the next trigger should be after user click on input field not when they write. One more point, sometimes it got stuck after selecting a theme and did not shows the pointer. Fixed/Improved that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/odoo#186219 Forward-Port-Of: odoo/odoo#182034
This error occurs when we are creating a new operation type in transfer. Steps to reproduce: --- - Install ``l10n_it_stock_ddt`` module - Switch company to ``IT Company`` - Go to transfer and create any new operation type Traceback: --- ``KeyError: 'code'`` At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``. [1]- https://github.com/odoo/odoo/blob/248
Original PR description
This error occurs when we are creating a new operation type in transfer. Steps to reproduce: --- - Install ``l10n_it_stock_ddt`` module - Switch company to ``IT Company`` - Go to transfer and create any new operation type Traceback: --- ``KeyError: 'code'`` At [1], we are facing this error because we are attempting to retrieve ``code`` from the ``vals``, but when we create a new operation type, we only receive ``name`` in the ``vals``. [1]- https://github.com/odoo/odoo/blob/2489a4c4a5aae829bb7dafe24d93529767ce07db/addons/l10n_it_stock_ddt/models/stock_picking.py#L76 sentry-6037671568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186127
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- setti
Original PR description
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This…
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- settings -> accounting -> taxes -> Fiscal Country: Uruguay. 4- create a new tax and make sure that the accounts on % of tax are expenses account so that the tax in non-deductible tax. 5- make sure to select the right tax group and country = Uruguay in the advanced options of tax. 6- create new product, and in accounting tap set the fixed asset account to the expenses account. and in the purchase tap make sure that the vendor taxes is set to the tax created before. 7- create a new vendor bill with the currency set to UYU. and confirm the bill. make sure that the fixed assets account is selected. 8- go to assets and create a new asset, in bills tab add the created bill. the asset will be created and the Original Value filed will contain the wrong amount. When calculating the non_deductible_tax_value for an asset, if there are original move lines in a foreign currency they won't be converted into the assets currency opw-4089386 Forward-Port-Of: odoo/enterprise#73185 Forward-Port-Of: odoo/enterprise#70268
Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders. opw-4295258 Forward-Port-Of: odoo/enterprise#73235
Original PR description
Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders. opw-4295258 Forward-Port-Of: odoo/enterprise#73235
This commit adds voice information to attachments while creating attachments received from meta side. This will let the users play voice messages directly from the discuss channel. Task-3839838 Forward-Port-Of: odoo/enterprise#73340 Forward-Port-Of: odoo/enterprise#73291
Original PR description
This commit adds voice information to attachments while creating attachments received from meta side. This will let the users play voice messages directly from the discuss channel. Task-3839838 Forward-Port-Of: odoo/enterprise#73340 Forward-Port-Of: odoo/enterprise#73291
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the
Original PR description
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the Year" section, which is not correct. On the other hand, if the normal "Profit and Loss" report is selected, the created journal entry is positive and its value is added to "Gross Profit" section, increasing "Net Profit" section, which is correct. opw-4185212 Forward-Port-Of: odoo/enterprise#73272 Forward-Port-Of: odoo/enterprise#72378
Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting
Original PR description
Problem: When rental dates are changed in the cart, the update occurs via an API call, which doesn't trigger the `_onchange_rental_start_date` and `_onchange_rental_return_date` methods. Additionally, we cannot add `rental_return_date` and `rental_start_date` as dependencies for `_compute_name` as outlined in this [commit](https://github.com/odoo/enterprise/commit/de5f3c7521d839e7549f5d44c7832e610fad7f29). Solution: Recompute the description after changing the dates in `_cart_update_renting_period` Steps to reproduce: - Add any rental product to the cart. - On the cart page, modify the rental start and end dates. - The order description does not update to reflect the new dates. opw-4259443 Forward-Port-Of: odoo/enterprise#72201
Steps to reproduce: 1. select a document 2. open chatter 3. drag(preview part) and drop to the others folder 4. the mail-chatter-dropzone remains open Technical Reason: Removing the unnecessary stop propagation on the search panel's document drop event as it was preventing it from being caught by the window keeping the chatter drop zone open. After this commit: The mail-chatter-dropzone will be closed after being moved to drag documents to the folders. Task-4268738 Forward-Por
Original PR description
Steps to reproduce: 1. select a document 2. open chatter 3. drag(preview part) and drop to the others folder 4. the mail-chatter-dropzone remains open Technical Reason: Removing the unnecessary stop propagation on the search panel's document drop event as it was preventing it from being caught by the window keeping the chatter drop zone open. After this commit: The mail-chatter-dropzone will be closed after being moved to drag documents to the folders. Task-4268738 Forward-Port-Of: odoo/enterprise#72937 Forward-Port-Of: odoo/enterprise#72443