Daily updates from Odoo
Navigate
Branch
Friday, March 29, 2024
124 changes
43 changes
Enhancements to existing features
This update improves Odoo's internal JavaScript testing tools and test reliability, especially around the HOOT framework used by developers. It helps make automated tests easier to maintain, clearer to diagnose, and less prone to random failures, with limited direct impact on day-to-day business users.
Original PR description
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203…
Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Enterprise: https://github.com/odoo/enterprise/pull/59291 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds better internal testing tools for validating generated page markup in Odoo's web module. It helps developers write clearer and more reliable tests, reducing the risk of display-related regressions reaching users.
Original PR description
This commit adds new matchers in hoot, which allow to test the inner/outerHTML of a node with a string (exact matching) or regex. In the case of a string, both the inner/outerHTML of the given node and the expected string are formatted, s.t. we can indent the expected value as we wish. This commit also adds a web test helper: expectMarkup. It allows to test the equality of two strings enconding html/xml. This is especially useful for view compilers. Again, the values are formatted before being compared. 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
Resolved issues and error corrections
A spelling mistake in the Website Livechat settings description was corrected from “Alow” to “Allow.” This improves clarity and professionalism in the settings interface without changing any functionality.
Original PR description
Description: Small typo in the Livechat setting description. Desired behavior after PR is merged: Change 'Alow' to 'Allow' in description. opw-3817716
This fixes issues that prevented customers from applying eWallet credit during online checkout. It also ensures loyalty rewards meant for future orders are clearly shown, reducing checkout confusion and missed promotional benefits.
Original PR description
Due to https://github.com/odoo/odoo/commit/994ee3f514d55c5c01975d3c0d77663eb173e775 commit, ewallet could no longer be applied.
This fixes an issue where automated live chat sidebar tests could fail unpredictably because a channel member timestamp was missing. The change improves test reliability and helps prevent false failures during development without affecting end users.
Original PR description
missing last_interest_dt of channel member can lead to unwanted unpinned channel in test due to race condition. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now runs server actions once when loading them and directly returns the resulting screen. This prevents duplicate executions when users navigate back through breadcrumbs, reducing unexpected repeated actions and improving navigation labels.
Original PR description
Before this commit, when an action is loaded, the server is called to find all the information of the action, if the action is a server action kind, a new call to the server is executed to run the…
Before this commit, when an action is loaded, the server is called to find all the information of the action, if the action is a server action kind, a new call to the server is executed to run the server action, the result of this running is a new action (close action or window action). Since [1], when a server action is found in the url, it will be executed to retrieve the window action when is the current action. If the server action is found in multiple places in the url, it will be executed each time it becomes the current action. For instance, /crm/12, will execute the server action crm to retrieve the window action at the first load, and the same server action will be executed again when clicking on the breadcrumb to go back to the multi-record view. Now, when an action is loaded, if the action is a server action, the server will execute the action directly and return the resulting action. This is to avoid a back and forward between the client side and the server side. Note that, this will also use the correct display name on the breadcrumb, the one of the window action. [1] https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
This fixes an error that prevented buyers from opening the product catalog after products had already been added to a purchase request. Users can now continue adding products from the catalog without disruption, improving the purchasing workflow.
Original PR description
Steps to reproduce: - Open purchase app. - Create an RFQ and add any product(s) to it. - Click on "Catalog" button in products tab to add products from the catalog. => Expected behavior: Catalog opens with a list of products to choose from. => Current behavior: An error is triggered: `TypeError: PurchaseOrderLine._get_product_catalog_lines_data() got an unexpected keyword argument 'parent_record'` This is because `_get_product_catalog_lines_data` in `purhcase.order.line` model is the only override of this function that does not accept keyword arguments. So when `_get_product_catalog_order_line_info` in `product.catalog.mixin` calls this function with any keyword argument, this error is triggered. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a small accounting issue caused by an extra comma and improves how tax-related Python rules are processed. The changes reduce the chance of minor accounting configuration problems and make repeated tax rule checks more efficient.
Original PR description
[FIX] account: Fix trailing comma [IMP] account_tax_python: Compile the regex --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Odoo's web test tools handle simulated data and server calls more accurately. It helps prevent test failures caused by incorrect mock behavior, improving confidence in future web changes without affecting end users directly.
Original PR description
This commit fixes two issues. The first one was in the mocked Model, in _unityReadRecords. When reading reference fields, we must read a related record, whose model and id are encoding in the value…
This commit fixes two issues.
The first one was in the mocked Model, in _unityReadRecords. When reading reference fields, we must read a related record, whose model and id are encoding in the value of the reference fields. Before this commit, we read the record on the wrong model (the main one, not the one of the reference field).
The second issue was in the MockServer. Commit [1] recently introduced the function stepAllNetworkCalls to call expect.step() for each server method/route called during the test. However, this didn't work properly for the route /web/dataset/call_kw/<path>. First because of a small mistake ("===" instead of "startswith" to match the route). Second because we didn't call the regular mock function for those routes, leading to crashes as the server always returned undefined.
[1] e721f1c7ce923b8f74abc3fef57ee5e9dd4c43ed
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-prThis fixes unstable automated tests around mail and live chat sidebar behavior caused by timing issues. The change helps prevent false test failures, improving confidence in future updates without changing user-facing functionality.
Original PR description
missing last_interest_dt of channel member can lead to unwanted unpinned channel in test due to race condition. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Enterprise: https://github.com/odoo/enterprise/pull/59568 Design Themes: https://github.com/odoo/design-themes/pull/794
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/59568 Design Themes: https://github.com/odoo/design-themes/pull/794
1. Fixes an issue where the parent product wasn't correctly set when computing the routes of a component, leading on components from subcontracted products displaying the wrong route (as it was trying to resupply the selected warehouse instead of the subcontracted location). Note: This part of the fix is only necessary up to version `saas-16.4`, as it was fixed from `17.0` onwards through f9c58a61ee21f1ad955ee2a5a0e868de30ae083f. 2. If a route is found when searching for subcontracting route
Original PR description
1. Fixes an issue where the parent product wasn't correctly set when computing the routes of a component, leading on components from subcontracted products displaying the wrong route (as it was…
1. Fixes an issue where the parent product wasn't correctly set when computing the routes of a component, leading on components from subcontracted products displaying the wrong route (as it was trying to resupply the selected warehouse instead of the subcontracted location). Note: This part of the fix is only necessary up to version `saas-16.4`, as it was fixed from `17.0` onwards through f9c58a61ee21f1ad955ee2a5a0e868de30ae083f. 2. If a route is found when searching for subcontracting routes but doesn't lead to a way to resupply the stock (either buy buying or manufacturing something), then ignore the found rules and revert to the default of trying to resupply the stock location. This avoids issue when using reordering rules to resupply the subcontracted location instead, where the 'Buy' route would be hidden even if it was selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159383 Forward-Port-Of: odoo/odoo#158785
[IMP] analytic: Add a function to get the analytic accounts off of analytic_distribution dict, this improvement is to avoid rewriting the same code all over whenever we wanna get the accounts. [related PR](https://github.com/odoo/enterprise/pull/57159) opw-3756270 Forward-Port-Of: odoo/odoo#157712 Forward-Port-Of: odoo/odoo#156866
Original PR description
[IMP] analytic: Add a function to get the analytic accounts off of analytic_distribution dict, this improvement is to avoid rewriting the same code all over whenever we wanna get the accounts. [related PR](https://github.com/odoo/enterprise/pull/57159) opw-3756270 Forward-Port-Of: odoo/odoo#157712 Forward-Port-Of: odoo/odoo#156866
This traceback arises when the payment status is 404. A comma at the end is forgotten while creating a tuple with a single record, which leads to a type error traceback. Error:- "TypeError: 'in <string>' requires string as left operand, not int" https://github.com/odoo/odoo/blob/7e3267fc69324a3c98d36983705a50420b5143f9/addons/payment_mercado_pago/const.py#L35-L39 https://github.com/odoo/odoo/blob/7e3267fc69324a3c98d36983705a50420b5143f9/addons/payment_mercado_pago/models/payment_tr
Original PR description
This traceback arises when the payment status is 404. A comma at the end is forgotten while creating a tuple with a single record, which leads to a type error traceback. Error:- "TypeError: 'in <string>' requires string as left operand, not int" https://github.com/odoo/odoo/blob/7e3267fc69324a3c98d36983705a50420b5143f9/addons/payment_mercado_pago/const.py#L35-L39 https://github.com/odoo/odoo/blob/7e3267fc69324a3c98d36983705a50420b5143f9/addons/payment_mercado_pago/models/payment_transaction.py#L165-L170 sentry-5103720097 Forward-Port-Of: odoo/odoo#159526 Forward-Port-Of: odoo/odoo#159433
Since [1] when `extraClass` was introduced, styles are wrongly applied if an `extraClass` is defined on a `selectStyle` option, but both the class and the option modify the same CSS property. Typically, the "Round Corners" option sets the `border-radius` property and uses the `rounded` extra class. But that extra class specifies values for the `border-radius` properties. Without the class, `applyCSS` determines that the style of some corners is already `0px` and does therefore not need
Original PR description
Since [1] when `extraClass` was introduced, styles are wrongly applied if an `extraClass` is defined on a `selectStyle` option, but both the class and the option modify the same CSS property.…
Since [1] when `extraClass` was introduced, styles are wrongly applied if an `extraClass` is defined on a `selectStyle` option, but both the class and the option modify the same CSS property. Typically, the "Round Corners" option sets the `border-radius` property and uses the `rounded` extra class. But that extra class specifies values for the `border-radius` properties. Without the class, `applyCSS` determines that the style of some corners is already `0px` and does therefore not need to be added to the inline style. But once the class is added, this is not true anymore - and the `0px` should have been specified. This commit avoids this issue by applying the CSS again once the `extraClass` is added. Steps to reproduce: - Drop a "Text - Image" snippet. - Select the image. - Set the "Round Corners" to "50 0 0 0". - Press tab to leave the field. => The entered field values was transformed. [1]: https://github.com/odoo/odoo/commit/bf5b4b69330747af7b09d48e59218b78a29a4b14 task-3800288 Forward-Port-Of: odoo/odoo#159385 Forward-Port-Of: odoo/odoo#157434
**Description of the issue/feature this PR addresses:** Change the way odoo compares product's attributes on website. **Current behavior before PR:** By default Odoo does only compare attributes of type "create_variant" = "dynamic" or "always" but unfortunately it does not allow to compare attributes with "create_variant" = "no_variant". **Desired behavior after PR is merged:** Odoo allows to compare attributes with "no_variant" See also: - https://github.com/odoo/odoo/pull
Original PR description
**Description of the issue/feature this PR addresses:** Change the way odoo compares product's attributes on website. **Current behavior before PR:** By default Odoo does only compare attributes of type "create_variant" = "dynamic" or "always" but unfortunately it does not allow to compare attributes with "create_variant" = "no_variant". **Desired behavior after PR is merged:** Odoo allows to compare attributes with "no_variant" See also: - https://github.com/odoo/odoo/pull/148326 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159597 Forward-Port-Of: odoo/odoo#159552
Current behavior: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Fix: --- Patched the phonenumbers library, adding a 9 at the right place for mobile phone numbers. opw-3694150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153282
Original PR description
Current behavior: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Fix: --- Patched the phonenumbers library, adding a 9 at the right place for mobile phone numbers. opw-3694150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153282
In https://github.com/odoo/odoo/commit/8e3283aabfd93a78eb4d72c4fd97f6a20ad08ef4 we solved the issue of onboarding progress records preventing the deletion of a company. We also added a test for this solution. In practice, it will not always make sense nor will it be allowed to delete a company and in some cases, the first thing that would fail is a foreign key from another model where it wouldn't make sense to cascade as we do for onboarding progress. Some modules create related records
Original PR description
In https://github.com/odoo/odoo/commit/8e3283aabfd93a78eb4d72c4fd97f6a20ad08ef4 we solved the issue of onboarding progress records preventing the deletion of a company. We also added a test for this solution. In practice, it will not always make sense nor will it be allowed to delete a company and in some cases, the first thing that would fail is a foreign key from another model where it wouldn't make sense to cascade as we do for onboarding progress. Some modules create related records when a company is created such that it would be cumbersome to bypass that. Therefore, we disable this test until a clean flow robust to all sorts of installed modules configuration is implemented. See runbot 60475 Task-3829936 Forward-Port-Of: odoo/odoo#159337
Currently, a logger exception is generated when the user tries to upload any document in the mass mail. Stack trace on sentry: ``` UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70> File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url image = Image.open(io.BytesIO(content)) File "PIL/Image.py", line 3008, in open raise UnidentifiedImageError( ``` This is because an UnidentifiedImageError occurs when the user
Original PR description
Currently, a logger exception is generated when the user tries to upload any document in the mass mail.
Stack trace on sentry:
```
UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70>
File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url
image = Image.open(io.BytesIO(content))
File "PIL/Image.py", line 3008, in open
raise UnidentifiedImageError(
```
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1]-https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
Forward-Port-Of: odoo/odoo#157513Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". =>
Original PR description
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". => The "Border" option is reset to 0. [1]: https://github.com/odoo/odoo/commit/2a6355c36ebfc4397451289589ebbeaa2afc1396 [2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4 task-3800288 Forward-Port-Of: odoo/odoo#159657 Forward-Port-Of: odoo/odoo#159452
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed
Original PR description
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed on the right and expand on the left. (exactly the opposite of ltr direction). Before: ======  After: =====  task-3721794 Forward-Port-Of: odoo/odoo#159468 Forward-Port-Of: odoo/odoo#157400
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined
Original PR description
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the…
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined Function: operator does not exist: date <= boolean` * confirm the invoice, ensuring the confirmation and invoice dates have different currency rates. * print the confirmed invoice.* print the invoice You should see that the printed rate does not align with the actual transaction amounts. ### Cause The system incorrectly uses the `l10n_sa_confirmation_datetime` to calculate and display the currency rate on the PDF. This field is only populated upon invoice confirmation, leading to errors when printing unconfirmed invoices. Moreover, using this date for confirmed invoices results in displaying an incorrect rate, as it may differ from the `invoice_date`, which should be used for accurate rate calculations. opw-3731624 Forward-Port-Of: odoo/odoo#156054
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156175
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156175
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do the certification through the received link - As admin, go to "Employee" and got to "Reporting -> Certifications" - You will see the certification in red under "Marc Demo" This means that the certification is already expired and should not. When completing a certification (survey), a hr_re
Original PR description
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do…
How to reproduce: - Install hr_skills_survey with demo data - As admin, in "Survey", create a simple certification with one question - Click on share and send it to Marc demo - As a public user, do the certification through the received link - As admin, go to "Employee" and got to "Reporting -> Certifications" - You will see the certification in red under "Marc Demo" This means that the certification is already expired and should not. When completing a certification (survey), a hr_resume_line is inserted in the database with a start_date and an end_date set to the completion date, causing the certification to be expired right away. We only do "cosmetic" correction here as the real fix will be done in master to avoid multiple upgrade: - to avoid existing certification to be displayed in red in the reporting view, we correct the display (by avoiding adding danger decoration to the line if the date_start equals the date_end). That correction won't avoid to find those certifications as expired as we can't correct the computed field as it is stored. Also, if the expiration_status column is shown (hidden by default), it will display expired on those certifications. - We do a similar correction in the display of the employee resume. Note: the end_date problem is anterior to v17 but the resume line expiration has been introduced in v17. Task-3389395 Forward-Port-Of: odoo/odoo#158047
Description of the issue/feature this PR addresses: Replace the use of 't-esc' with 't-field' for the payment icon image in the icons list template. The latter, for an image field, provides two options for rendering the payment icon image: use the PIL library to obtain the image when given the option 'qweb_img_raw_data', or use a URL. The former only considers the first option, allowing only image formats compatible with the PIL library. Current behavior before PR: Only image formats co
Original PR description
Description of the issue/feature this PR addresses: Replace the use of 't-esc' with 't-field' for the payment icon image in the icons list template. The latter, for an image field, provides two options for rendering the payment icon image: use the PIL library to obtain the image when given the option 'qweb_img_raw_data', or use a URL. The former only considers the first option, allowing only image formats compatible with the PIL library. Current behavior before PR: Only image formats compatible with the PIL library can be used for the payment icons. Desired behavior after PR is merged: Other formats including the ones compatible with the PIL library can be used for the payment icons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159586 Forward-Port-Of: odoo/odoo#158728
Current behavior before PR: - Unable to save subtasks when adding a project. - Traceback occurs when creating a new task from the subtask kanban view in project sharing. Desired behavior after PR is merged: - Enable successful saving of subtasks after adding a project. - Resolve traceback issue during new task creation in project sharing, ensuring correct task creation without traceback. task-3584963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Current behavior before PR: - Unable to save subtasks when adding a project. - Traceback occurs when creating a new task from the subtask kanban view in project sharing. Desired behavior after PR is merged: - Enable successful saving of subtasks after adding a project. - Resolve traceback issue during new task creation in project sharing, ensuring correct task creation without traceback. task-3584963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143282
This commit's purpose is to display the correct currency for the hourly cost of employee in the project sol mapping. Currently, the currency displayed is the one of the sol instead of the currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c We added a monetary widget, but we are feeding it the wrong id. After this commit, the correct currency is displayed task - 3749225 Forward-Port-Of: odoo/odoo#159588 Forwa
Original PR description
This commit's purpose is to display the correct currency for the hourly cost of employee in the project sol mapping. Currently, the currency displayed is the one of the sol instead of the currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c We added a monetary widget, but we are feeding it the wrong id. After this commit, the correct currency is displayed task - 3749225 Forward-Port-Of: odoo/odoo#159588 Forward-Port-Of: odoo/odoo#154240
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft state, split the quantity into 10 **Problem:** The created MOs have component quantities of 0.1 instead of 1. When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_
Original PR description
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft…
**Steps to Reproduce the Bug:**
- Create a BoM:
- Product: P1, Quantity: 1 unit
- Component:
- C1, Quantity: 1 unit
- Create a MO to produce 10 units of P1:
- This requires 10 units of C1
- In draft state, split the quantity into 10
**Problem:**
The created MOs have component quantities of 0.1 instead of 1.
When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_qty of the MO. Therefore, the move will be updated to 1.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1793
Subsequently, the factor is calculated based on the `move_qty` and the `qty_initial` of the MO.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1828
Factor = 1 / 10 = 0.1
Afterwards, this quantity is set on the original move and the backorder moves:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1830
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1835
opw-3825708
Forward-Port-Of: odoo/odoo#159492The method `_get_reward_values_free_shipping` assumes there is only one delivery line per sale order. But it is not always the case. This commit therefore makes sure the method does not raise an error in case of multiple lines by taking into account only the first delivery line. Fixes #136395 Forward-Port-Of: odoo/odoo#159584
Original PR description
The method `_get_reward_values_free_shipping` assumes there is only one delivery line per sale order. But it is not always the case. This commit therefore makes sure the method does not raise an error in case of multiple lines by taking into account only the first delivery line. Fixes #136395 Forward-Port-Of: odoo/odoo#159584
Forward-Port-Of: odoo/odoo#159621
Original PR description
Forward-Port-Of: odoo/odoo#159621
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numb
Original PR description
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number…
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numbers are skipped if they are the same as the partner's number. [Reproduce] - Install mass_mailing_sms, sale_management, and sale_subscription modules. - Add an SMS token to the IAP account. - Create a contact (C) with a valid phone number. - Create a new quotation with contact (C) as the partner. - Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module). - Do not change the contact number on the pop-up (ensure it matches C's phone number exactly). - Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error. opw-3596207 Forward-Port-Of: odoo/odoo#153429
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted. This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py". Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behavior
Original PR description
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted. This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py". Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behaviors. The goal here is to delete all the old drivers and interfaces before downloading the new ones to make sure we don't have this issus task-3729890 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159538 Forward-Port-Of: odoo/odoo#158412
Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
Original PR description
Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
Addresses the issue where reapplying an already applied coupon in the website shop led to the disappearance of the discount. With this fix, the discount remains applied, and the system continues to inform the user that the coupon has already been used, preventing confusion and maintaining consistency in the discount application process. task-3621246 Forward-Port-Of: odoo/odoo#153485
Original PR description
Addresses the issue where reapplying an already applied coupon in the website shop led to the disappearance of the discount. With this fix, the discount remains applied, and the system continues to inform the user that the coupon has already been used, preventing confusion and maintaining consistency in the discount application process. task-3621246 Forward-Port-Of: odoo/odoo#153485
Test 'test_unpack_and_quants_history' may fail with error ``` ERROR: StockQuant.test_unpack_and_quants_history Traceback (most recent call last): File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history dst_location = stock_location.child_ids[0] File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__ return self.browse((self._ids[key],)) IndexError: tuple index out of range ``` Forward-Port-Of: odoo/odoo#159611
Original PR description
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
Forward-Port-Of: odoo/odoo#159611Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
Original PR description
Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
It cannot happen through the default SO form view, but some funny guys have found other ways to do it, even though it can be quite problematic, especially if the new pricelist is in another currency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159694 Forward-Port-Of: odoo/odoo#157742
Original PR description
It cannot happen through the default SO form view, but some funny guys have found other ways to do it, even though it can be quite problematic, especially if the new pricelist is in another currency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159694 Forward-Port-Of: odoo/odoo#157742
When using the `/image` command in the composer, or otherwise uploading a file the editor should add the attachment to the composer if it is the current model During a change in js relational models [1] the code was not adapted properly. This lead to a traceback when using the command inside the composer. [1]: 218ad8456a06503dd508e7216edcffdc90b35cac task-3741858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1557
Original PR description
When using the `/image` command in the composer, or otherwise uploading a file the editor should add the attachment to the composer if it is the current model During a change in js relational models [1] the code was not adapted properly. This lead to a traceback when using the command inside the composer. [1]: 218ad8456a06503dd508e7216edcffdc90b35cac task-3741858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155704
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the iss
Original PR description
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the issue / fix: This part of the report is displayed under a `t-elif` condition. However for internal trasnfers the condition of the `t-if` and of the `t-elif` are both `true` so that two `t-if` should be used for an appropriate display of the report. ### Note: Prior to commit 567b8d6, two `t-if` were used. opw-3797998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158852
The barcode nomenclature allows to define custom prefix for gift cards. e.g. the default nomenclature in demo data allows both 043 or 044 as prefix for rule of type coupon. Therefore the hardcoded string with 044 doesn't allow to sell a gift card whose barcode does not start with this. Instead of hardcoding the value, fetch it from the configuration and the nomenclature that is defined in the settings. OPW-3499787 --- I confirm I have signed the CLA and read the PR guidelines at www
Original PR description
The barcode nomenclature allows to define custom prefix for gift cards. e.g. the default nomenclature in demo data allows both 043 or 044 as prefix for rule of type coupon. Therefore the hardcoded string with 044 doesn't allow to sell a gift card whose barcode does not start with this. Instead of hardcoding the value, fetch it from the configuration and the nomenclature that is defined in the settings. OPW-3499787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159512 Forward-Port-Of: odoo/odoo#159349
Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized the current user, further prioritize based on companies matching the records passed to `_mail_find_partner_from_email`, avoiding potential access rights errors in multi-company environments. opw-3705199 Forward-Port-Of: odoo/odoo#159108 Forward-Port-Of: odoo/odoo#156158
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being created / uniqueness constraint issues on journal codes. The matching happens in `_pre_reload_data`. This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid. The problem was introduced in commit d6695f2892ded178371f6c69cf594037
Original PR description
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being…
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name).
This then leads to duplicate journals being created / uniqueness constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
- (1) We load the chart data in en_US to be able to use the code translations
- (2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2); Code is not translatable.
- We compare those values (journal code / name) against the en_US term due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version) against the translated values.
Forward-Port-Of: odoo/odoo#159738
Forward-Port-Of: odoo/odoo#159635## Description Adding missing indexes to support most of the searches on survey's models to avoid seq.scans and non-selective index scans. Also adding indexes that are inverse to One2many, or dependencies of compute fields (as those if not indexes will trigger a seq.scan when the ORM resolves the dependency tree). If a domain had multiple criteria, only fields with the highest selectivity were indexed. This shall also reduce the amount of tuples returned, reducing IO access and cache trashing.
Original PR description
## Description Adding missing indexes to support most of the searches on survey's models to avoid seq.scans and non-selective index scans. Also adding indexes that are inverse to One2many, or dependencies of compute fields (as those if not indexes will trigger a seq.scan when the ORM resolves the dependency tree). If a domain had multiple criteria, only fields with the highest selectivity were indexed. This shall also reduce the amount of tuples returned, reducing IO access and cache trashing. ## Cardinality survey_survey -> X (reference quantity) survey_question -> 10X survey_question_answer -> 50X survey_user_input -> 330X survey_user_input_line -> 7200X ## Reference task-3724844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158136
1 change
Enhancements to existing features
This update incorporates changes to Ecuadorian income withholding taxes mandated by the SRI (Superintendencia de Riego) for 2024. The update includes new tax rates and data adjustments to ensure accurate reporting of income taxes for businesses operating in Ecuador. This ensures compliance with local regulations.
Original PR description
In 2024 the SRI changes income withholding taxes. We update minor data and create new taxes for the new percentages Forward-Port-Of: odoo/odoo#157226 Forward-Port-Of: odoo/odoo#156740
29 changes
Enhancements to existing features
The IoT system now checks whether its live connection is actually needed before activating it on an IoT box. This reduces unnecessary background activity and can help improve reliability and resource usage without changing day-to-day user workflows.
Original PR description
Previously, the WebSocket connection remained active even when not in use. Now, the system checks WebSocket usage before sending the iot_channel to the iot box. If the WebSocket is unused, False will be sent. task:3761864 community: 158775
This update adds automated checks for task scheduling from the task Gantt view. It helps ensure users can continue planning tasks based on selected timeframes without regressions in future changes.
Original PR description
In task 3644342, a feature was added to allow users to plan their tasks according to the timeframe they selected in the gantt view of tasks. This PR will add some tests to ensure that this feature is never broken. task-3800455
The project map view now shows a helpful message when there are no tasks to display. This gives users clearer guidance instead of leaving the map area empty, improving usability in project navigation.
Original PR description
- master ### Project map view improvement - Added a helper message when there is no task available in the map view. task-3734820
The Field Service Report module’s automated tests were updated to stay aligned with related platform changes. This helps maintain reliability and reduces the risk of regressions without changing day-to-day user workflows.
Original PR description
This commit is a follow-up of its community part. It aims to update the tests to fit the changes made. task - 3741976 community pr: https://github.com/odoo/odoo/pull/156086
Timesheet billing rate targets and leaderboards can now be enabled separately for each company instead of applying to everyone in the database. This gives multi-company organizations better control over which employees see billing indicators and leaderboard features while keeping settings aligned with each company’s needs.
Original PR description
# Goal The "Billing Rate Target" and "Billing Rate Leaderboard" settings in sale_timesheet_enterprise are not company-dependent ; activating them activates the leaderboard and the indicators for every employee registered in the DB. The goal of this PR is to make those feature company-dependent. # Changes - The "group_timesheet_leaderboard_show_rates" and "group_use_timesheet_leaderboard" were removed. This has the side effect of displaying the "Tips" menuitem at all times, but this is not a problem. - Two new boolean fields "timesheet_show_rates" and "timesheet_show_leaderboard" were added to res.company. They control whether the indicators and the leaderboard are displayed for the company or not. - Settings and views were edited to support those fields. task-3702877
Journal reports have been rewritten to provide a simpler, cleaner reporting experience. The expand option has been removed, reducing visual complexity and making the report easier for accounting users to navigate.
Original PR description
Rewriting the journal report Removing expand functionality Cleaning the UI task: 3698843
The Field Service report menu for planning by worksheet template now shows its views in the same order as other planning menus. This makes navigation more predictable and reduces confusion for users moving between planning screens.
Original PR description
…plate menu Before this PR: - The views in the 'planning by worksheet template' menu are not in the same order as the other 'planning' menus from field service, which is inconsistent. After this PR: - The views in the 'planning by worksheet template' menu are the same order as the other 'planning' menus from field service, which is consistent now task-3770938
Resolved issues and error corrections
The Swiss payroll setup now points to the correct employee view after a duplicate payroll section was removed. This prevents related payroll information from being placed incorrectly and helps keep employee payroll screens consistent.
Original PR description
Before this commit, and the commit introduced in odoo/odoo#158508, two group named "payroll_group" were present on the employee view. The group introduced in hr has been removed and the one in payroll kept. This commit changes the xml_id used as inheritance in l10n_ch_hr_payroll to inherit the view defined in payroll rather than the view from hr_contract to allow inserting some content after the group mentionned above.
The field service task signing pop-up now appears above the page header as intended. This prevents confusion for workers signing worksheets from the customer portal and removes a visual overlay gap at the top of the page.
Original PR description
Steps: Install industry_fsm, worksheet and website. Create a task, set Joel Willis as assignee and add a worksheet. Log in as Joel Willis, got to that task and click sign. Issue: Z-wise, the modal isn't above the header. Cause: The modal is at the same level as the sign button, that is in the sidebar, which has `position: sticky;`. This fixes the `z-index` to the default value (even setting it manually has no impact). The fact that the modal's z-index is greater than the header's doesn't matter, as its container limits it. Solution: Put the modal div in the main content, which will never be sticky. Also, `mt-5 pt-5` were creating a "non grayed" stripe in the upper part of the page (where the header is at), so we delete it. task-3644729
Website form submissions to existing helpdesk tickets no longer add confusing HTML tags or irrelevant text in the ticket chatter. This keeps ticket history clearer for support teams reviewing customer requests.
Original PR description
**Steps:** - Open website and go to contact us - Using web editor option click on existing form and change its action - In create task action > select an existing ticket - Fill and submit the form - Open Ticket and go to the ticket given in create task action - Open the ticket created from the website - Have a glance at the chatter **Issue:** - Chatter is showing irrelevant information. (namely html tags) **Cause:** - Regrettably, due to last-minute changes preceding the merge, the review process for PR(https://github.com/odoo/enterprise/pull/47278) was unintentionally skipped. As a result, certain modifications were pushed that do not align with the expected standards. **Fix:** - Taking corrective action by adding proper if condition and assigning values correctly which will resolve this issue promptly. **Task**-3674768
This fix prevents a system error in Mexican electronic invoicing for Point of Sale orders by checking whether invoice information is available before using it. It helps keep automated validation and related POS invoicing flows stable without changing user-facing behavior.
Original PR description
### Commit 1: Fix the runbot issue number 60914 by verifying that the field to_invoice exists in the pos.order dict before trying to access it. Runbot error ID: 60914
This update standardizes how Odoo interprets internal filtering rules and fixes a case where empty filters could be handled incorrectly. It reduces the risk of unexpected search results, access behavior, or warnings across several business apps.
Original PR description
This pr is to be reviewed commit by commit. It stems from task opw-2495504 following which a series of changes were established with the framework-py team. [IMP] all: domain leaf semantics (1, "=", 1) is replaced by a boolean [FIX] all: fix misinterpretation of empty domain in expression.OR [IMP] all: better normalization and warnings for wrong domain operator
Features or functions removed from Odoo
The unused Worldline Last Transaction Status button has been removed from Point of Sale. This simplifies the payment terminal integration and reduces maintenance for a feature rarely used by customers.
Original PR description
We currently have an unnecessary and unused feature for Worldline "Last Transaction Status". It's a button which checks the status of the last transation processed by the terminal and sends this data to the PoS frontend. This button adds some unnecessary complexity to our codebase and is widely unused by the clients, so we are removing it in the latest version. task-3460003
Code cleanup and technical improvements
Automated product tours and tests now use event behavior that more closely matches real user interactions, such as typing and key presses. This makes the tours easier to understand and reduces hidden automatic behavior, improving reliability across many business flows.
Original PR description
In this commit, events in addons/web_tour/static/src/tour_service/tour_utils.js writed with native dispatchEvents has been refactored to use Hoot events. These events are much closer to the behavior…
In this commit, events in
addons/web_tour/static/src/tour_service/tour_utils.js writed with native dispatchEvents has been refactored to use Hoot events. These events are much closer to the behavior of a user (e.g. instead of overwriting the value of an input, it simulates the encoding using keydowns).
The motivation of these changes is to make the tours more understandable and significantly less implicit. As a result, “automatic” behaviors have been removed.
Here below are the main modifications made in RunningTourActionHelper class :
- The auto method has been removed.
- remove_text() has been replaced by clear().
- text() has been splitted in edit(), fill(), select(), selectByIndex(), selectByLabel() and editor().
- Default "Test" string has been removed. No text => No text (Then, note that `run edit` will just clear the input)
- New events has been added like range(), press() and blur().
A New feature has been added in tour_compiler.js :
You can now chain events in run attribute of a step with `&&` :
e.g. :
```
{
extra_trigger: ".o_web_studio_sidebar .o_web_studio_properties.active",
trigger: "input[name='string']",
run: "edit new name && press Enter",
},
```
Still to do in a next PR :
- refactor click()
- refactor drag_and_drop_native()
task~3820046
https://github.com/odoo/odoo/pull/158055Miscellaneous changes
Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: 3754211 Forward-Port-Of: odoo/enterprise#59510
Original PR description
Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: 3754211 Forward-Port-Of: odoo/enterprise#59510
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#59442 Forward-Port-Of: odoo/enterprise#57822
Original PR description
There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#59442 Forward-Port-Of: odoo/enterprise#57822
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has als
Original PR description
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has also been fixed. The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. This issue was solved in 17 in this commit: https://github.com/odoo/enterprise/commit/49f664db942f3b7f5d343ac7a42608839b5595bf. It is backported in order to make the draft closing entry flow as smooth as possible. task-3520338 Forward-Port-Of: odoo/enterprise#59476 Forward-Port-Of: odoo/enterprise#52875
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Original PR description
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794 Forward-Port-Of: odoo/enterprise#59568
Original PR description
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794 Forward-Port-Of: odoo/enterprise#59568
See also: - https://github.com/odoo/odoo/pull/159618 Forward-Port-Of: odoo/enterprise#59607
Original PR description
See also: - https://github.com/odoo/odoo/pull/159618 Forward-Port-Of: odoo/enterprise#59607
This tour was failing undeterministically because the values set in the dialog were not saved to the database. A naive fix was quickly merged in 2be6e64ef23717ab36dbba87723db666a1757eee: we kept the default values in the dialog (so it was no longer failing even if the values weren't saved). This actually occurs because we call `action_pos_order_invoice` before saving the values of the dialog to the server. Adding an `await` fixes this. Hence we can set a random (different from the default
Original PR description
This tour was failing undeterministically because the values set in the dialog were not saved to the database. A naive fix was quickly merged in 2be6e64ef23717ab36dbba87723db666a1757eee: we kept the default values in the dialog (so it was no longer failing even if the values weren't saved). This actually occurs because we call `action_pos_order_invoice` before saving the values of the dialog to the server. Adding an `await` fixes this. Hence we can set a random (different from the default) `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public`. runbot build error 60671 Forward-Port-Of: odoo/enterprise#59354
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax
Original PR description
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%.…
### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected. ### Solution There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. opw-3744872 Forward-Port-Of: odoo/enterprise#59221 Forward-Port-Of: odoo/enterprise#58377
STEP TO REPRODUCE: ================== * Go on Appraisal application * Select an appraisal * Click on "ask feedback" button * Add in recipients field an employee without user linked to him task: 3818033 Forward-Port-Of: odoo/enterprise#59464 Forward-Port-Of: odoo/enterprise#59125
Original PR description
STEP TO REPRODUCE:
==================
* Go on Appraisal application
* Select an appraisal
* Click on "ask feedback" button
* Add in recipients field an employee without user linked to him
task: 3818033
Forward-Port-Of: odoo/enterprise#59464
Forward-Port-Of: odoo/enterprise#59125During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
Original PR description
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367
Original PR description
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
Original PR description
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them. Example (formatted): ```sql SELECT "mrp_routing_workcenter".id FROM "mrp_routing_workcenter" LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id" ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id" WHERE "mrp_rou
Original PR description
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG…
When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
Forward-Port-Of: odoo/enterprise#59406
Forward-Port-Of: odoo/enterprise#58756Bug === If the thumbnail update failed, an error is raised in the browser. This can happen if it was already updated by someone else. Forward-Port-Of: odoo/enterprise#59144
Original PR description
Bug === If the thumbnail update failed, an error is raised in the browser. This can happen if it was already updated by someone else. Forward-Port-Of: odoo/enterprise#59144
27 changes
Security fixes and vulnerability patches
Fixed a security issue where users could see folder names from other companies they don't have access to. Now, when viewing folder hierarchies, any folders the user cannot access will display as "Restricted Folder" instead of showing their actual names. This prevents unauthorized information disclosure while maintaining the ability to navigate the complete folder structure.
Original PR description
Steps to reproduce: - Install `documents` module - Ensure you have access to 2 companies (Co. 1 and Co. 2) - Enable both companies - Create a Folder A in Co. 1 - Create a Folder B in Co. 2 with Folder A as parent - Create a Folder C in Co. 1 with Folder B as parent - Put a file in each folder - Enable only Co. 1 - On left panel, select Folder A and unfold until Folder C appears Issue: The folder B is visible. Cause: When retrieving the folders to display in the search_panel, we retrieve all the ancestors of the available folders to display the complete folder tree for all available folders. Solution: Change the name of the unauthorized folders to "Restricted Folder". opw-3701633 Forward-Port-Of: odoo/enterprise#59551 Forward-Port-Of: odoo/enterprise#58422
New functionality added to Odoo
This update adds support for new VAT tax rates (5% and 15%) required by Ecuador's tax regulations as of March 2024. The changes include configuring these new tax rates in the system, updating tax reporting to properly handle the new percentages, and ensuring electronic tax documents are generated correctly with the updated tax information.
Original PR description
- Set up tax support configuration for new VAT purchase taxes of 5% and 15%. - Add rate and tax group codes for electronic documents - Add unit test for VAT 5% and 15% - Fix ATS report to declare VAT taxes inactive - Add tax support configuration migration for new VAT taxes in 2024 - Cover base and tax amounts scenario for the ATS, including new tax percentages - Fix missing tax support configuration for taxes with xml_ids: tax_vat_545_sup_08_vat0, tax_vat_545_sup_08_vat_exempt, tax_vat_545_sup_08_vat_not_charged - Add default company configuration for sale and purchase taxes, with new 15% tax
Enhancements to existing features
This update improves the speed and efficiency of survey operations by adding database indexes to frequently searched fields. These indexes help the system find survey data faster and reduce unnecessary processing, resulting in quicker response times when users interact with surveys and survey results.
Original PR description
## Description Adding missing indexes to support most of the searches on survey's models to avoid seq.scans and non-selective index scans. Also adding indexes that are inverse to One2many, or dependencies of compute fields (as those if not indexes will trigger a seq.scan when the ORM resolves the dependency tree). If a domain had multiple criteria, only fields with the highest selectivity were indexed. This shall also reduce the amount of tuples returned, reducing IO access and cache trashing. ## Cardinality survey_survey -> X (reference quantity) survey_question -> 10X survey_question_answer -> 50X survey_user_input -> 330X survey_user_input_line -> 7200X ## Reference task-3724844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed a confusing error message that appeared when users added companies to a worksheet template that previously had no companies assigned. The error message now clearly explains the issue instead of displaying blank company names, making it easier for users to understand what went wrong and how to fix it.
Original PR description
This commit's purpose is to improve the error message when a user is adding new company to a template that had none set before. Steps to reproduce: - open fsm app - open configuration menu, worksheet template - select the 'Device installation and maintenance' worksheet (it is the one with tasks linked to it) - add a new company 'my company (chicago)' and save. A validation error message pops up. That is fine and the expected behavior, since the new companies of the template are not consistent with the task already linked to it. Source: the generic message is using the old values of the companies of the worksheet, but since there were none, no names are displayed and the error message is confusing. Solution: check if the worksheet used to have companies set before the user changes. If not, display a relevant error message task - 3749225
Corrected a bug in Ecuador's withholding tax feature where adding multiple withholding lines would incorrectly use the same tax base amount for each line instead of calculating the remaining balance. This fix ensures accurate tax withholding calculations when processing bills with multiple withholding entries.
Original PR description
With an Ecuador company setup Create a bill adding: - Ecuador partner - Bill Date - Document Number (ex. 001-001-123456789) - Payment Method - a bill line with tax "12% 510 01" Post the bill Hit 'Add witholding' In the witholding widget: - Add a line with tax "10% WH" - Add a second line with tax "10% WH" Issue: second line base amount will be same as first, while it should use the remaining withholding base amount opw-3763838
This update corrects misleading button and filter labels in the Documents module. Users were seeing "Archive" labels on buttons and filters that actually move documents to trash, causing confusion. The labels have been updated to accurately say "Move to trash" to match the actual behavior of the feature.
Original PR description
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Configuration -> Workspaces - Click on the search view dropdown - The filters section still has a filter named 'Archived Workspace' instead of 'Moved to trash' even though it displays trashed workspaces. This PR changes the string of filter from 'Archived Workspace' to 'Moved to trash'. Task: [3787404](https://www.odoo.com/web#id=3787404&cids=2&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)
This fix resolves an error that occurred in the General Ledger report when attempting to format currency values (such as K$, M$). The issue was caused by incorrect handling of currency data when reformatting values. The fix ensures currency information is properly processed, preventing errors both in standard and expanded report views.
Original PR description
In General Ledger report, we get an error when trying to reformat value (K$, M$, ..) Reason: When setting the 'currency' value on each column, we take the currency of the account, which is interpreted as a string on js side, then used to call format_value in where we try to get `currency.id`, leading to the error. To avoid that, we return only the id of the currency if there is one. Also, we get a KeyError whendoing the same flow with unfolded lines opw-3793209
The permission panel in the Knowledge module was not refreshing when its values changed, causing users to see outdated information. This fix ensures the panel now properly updates and displays the latest values whenever changes occur.
Original PR description
**Before this PR:** The permission panel was not being updated when its values changed, resulting in outdated values being displayed. **After this PR:** the permission panel now re-rendered to reflect the updated values correctly. **Task**-3792165 Forward-Port-Of: odoo/enterprise#58825
This fix corrects test validation values for eco voucher calculations in the Belgian payroll module. The expected test values were not updated in a previous change that excluded parental time off from eco voucher eligibility. This ensures payroll tests run correctly without demo data.
Original PR description
Expect value for test without demo data wasn't changed in this PR :odoo/enterprise#50794 Fixed with this commit. task: 3837296
This fix prevents subscription orders from being locked when the "Lock Confirmed Sales" setting is enabled. Previously, enabling this security setting would incorrectly lock subscription orders after invoicing, preventing further modifications. The fix ensures this setting only applies to regular sales orders, not subscriptions, as intended.
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59118 Forward-Port-Of: odoo/enterprise#58332
Fixed an issue where importing Mexican electronic bills (CFDI) would crash if certain tax rate information was missing. Now the system gracefully handles these cases by logging a message and continuing the import process instead of failing completely.
Original PR description
When trying to import a bill that sometimes did not had TasaOCuota attribute. This resulted in a crash of a failed float parse Now when this happens, a message in the chatter is created and the tax_id is ignored task:3777664 Forward-Port-Of: odoo/enterprise#58812
This update fixes appointment scheduling tests that were failing when demo data wasn't available. The system now properly handles timezone settings and removes dependencies on specific demo user accounts, making tests more reliable and independent of sample data.
Original PR description
* With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. * Remove the use of demo data (Mitchell Admin and Joe Willis) for test tour.
Fixed an issue where the "Connect to a bank" button would disappear from the journal dashboard after removing a bank synchronization. Users can now properly reconnect to their bank after resetting the sync without needing to refresh or navigate away from the dashboard.
Original PR description
…ter reset sync - Connect to a bank with the button in the journal dashboard - Remove sync (sometime you should do this) --> Issus the button Connect to a bank is not show on the dashboard
This fix resolves an issue where deleting trashed documents from the activity view would lose the applied search filter. Now when users delete a document that was filtered to show inactive items, the filter is properly maintained after the deletion, ensuring a consistent user experience.
Original PR description
**Before this PR:**
When user deletes a trashed document (accessed by applying a custom filter
with domain `[('active', '=', False)]`) from the activity view, search domain
(i.e. existing filter) is not applied after deletion.
**After this PR:**
The issue has been addressed by calling the 'load' method of activity model
along with the model 'config' as arguments to ensure that proper domain is
applied according to the search filter after delete operation.
Task: [3714544](https://www.odoo.com/web#id=3714544&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form)
Forward-Port-Of: odoo/enterprise#59661
Forward-Port-Of: odoo/enterprise#56357This update corrects how planned hours are calculated when they fall on public holidays or employee leaves. Previously, a workaround was needed because timesheets weren't created for holidays, but this is now fixed in version 16.3+. The system now properly accounts for holidays by automatically subtracting actual timesheet hours from planned hours, ensuring accurate remaining hours in the Timesheets & Planning analysis.
Original PR description
This reverts commit 55cba9f899be0f058834bcd81bd239547c9cebd6. The issue this intended to fix was rooted in the fact that no timesheets were created for public holidays, leading to the remaining hours shown in Timesheets & Planning analysis being wrong. This is no longer an issue starting from version 16.3, timesheets do get created, so any *planned* hours that fall on a holiday get subtracted by the corresponding effective hours from timesheets. opw-3509155 Forward-Port-Of: odoo/enterprise#59645
Fixed an issue that prevented non-accounting managers from opening journal statements due to a bank synchronization check requiring manager access rights. The system now skips this update for non-managers, allowing them to view journals while managers handle the synchronization updates.
Original PR description
…when opening journal statements When opening journal, a check is done to update the bank sync state It is not possible to update the state without accounting manager access rights Introducing a skip for non account managers to allow opening the journal. Furthermore, non-managers can't see the online sync anyway so we don't update it until a manager opens the journal. opw-3800147
This update fixes an issue with DHL shipping where shipper and receiver reference information was not being set correctly during delivery validation. The fix ensures that when customers create sales orders with DHL shipping and validate deliveries, the proper reference details are now included in the DHL shipment request, improving the accuracy of shipping documentation.
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order add dhl shipping and validate the delivery Fix: set the correct shipper and receiver referrence opw-3775347 Forward-Port-Of: odoo/enterprise#59627
This fix ensures that product tracking is properly enabled in barcode scanning tests, preventing test failures when demo data is not available. The change ensures that test lines are correctly grouped during barcode operations, maintaining test reliability across different environments.
Original PR description
The product tracking is enabled by default in the demo data. Running the test without those data will break, as the 2 lines in the tour won't be grouped. runbot 54158 Forward-Port-Of: odoo/enterprise#59647
A test in the Planning module was failing due to daylight saving time changes. This fix ensures the test consistently uses UTC timezone throughout, eliminating failures caused by seasonal time changes. This makes the test more reliable and easier to maintain.
Original PR description
Before this commit, the test fails since 23 March 2024 because next week the hours changed (summer time). The problem is there if the timezone is not UTC. This commit ensures the whole test uses the same timezone and only UTC one to avoid having to manage summer/winter time in the test. runbot-60932 Forward-Port-Of: odoo/enterprise#59366
This update fixes an issue where Ponto's consent expiration dates were not being tracked correctly in the online account synchronization system. The fix ensures that expiration dates are checked and updated each time the system communicates with Odoofin, providing more accurate and timely information about account access permissions.
Original PR description
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
This update fixes two issues in the barcode scanning system for warehouse transfers. Previously, users could scan any location as a source location, and packages stored in sub-locations were incorrectly rejected during scanning. Now the system properly recognizes packages and locations that belong to the picking's source location or its child locations, allowing warehouse staff to complete transfers more efficiently without unexpected error messages.
Original PR description
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new storable product > - Update onhand qty: 20 package: PKG1, location: WH/Stock/Shelf 1 > - in Barcode app create a new transfer and scan PKG1 > > Bug: > the current package location is different from the default source location therefore package is ignored and an error is thrown (you are expected to scan one or more products ....) > > Fix: > check if the package is in a child location aswell > > opw-3595643 Forward-Port-Of: odoo/enterprise#59526 Forward-Port-Of: odoo/enterprise#58896
Portal users were unable to filter opportunities by activity date (Overdue/Today/This Week) due to insufficient access rights, resulting in a 403 error. This fix adjusts how the system handles permission checks during searches, allowing users to properly filter their assigned opportunities while maintaining security controls.
Original PR description
…search **Issue Description:** Due to changes in field access rights verification as seen here: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345…
…search **Issue Description:** Due to changes in field access rights verification as seen here: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345 And the removal of sudo rights for CrmLead: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/addons/website_crm_partner_assign/controllers/main.py#L98 Attempting to open a search by domain with the `activity_date_deadline` field triggers a 403 error: "You do not have enough rights to access the fields 'activity_date_deadline' on Lead/Opportunity (crm.lead). Please contact your system administrator." **Steps to Reproduce:** 1. Install the `website_crm_partner_assign` module. 2. Assign Joel Willis a partner level (via the partner assignment tab in the `Contact` app). 3. Navigate to CRM, select an opportunity, and assign it to Joel Willis (using the assigned partner tab in the lead form). 4. Log in to the portal as Joel Willis, navigate to Opportunities, and click any filter on the activities date `Overdue / today / this week activities`. This action results in a crash. **Proposed Solution:** Our approach focuses on secure and efficient access to data, especially for sensitive fields like `activity_date_deadline` and `activity_ids.date_deadline`. We selectively apply higher permissions during search operations to ensure users can access crucial information without compromising data security. By carefully using higher permissions and applying internal rules after searches, we strike a balance between making data available for legitimate needs and upholding our security measures. opw-3703583
This fix resolves an issue where uploading files or using the image command in the email composer was causing errors. The code was not properly updated after recent changes to how the system handles file relationships, preventing attachments from being correctly added to messages.
Original PR description
When using the `/image` command in the composer, or otherwise uploading a file the editor should add the attachment to the composer if it is the current model During a change in js relational models [1] the code was not adapted properly. This lead to a traceback when using the command inside the composer. [1]: 218ad8456a06503dd508e7216edcffdc90b35cac task-3741858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where batch transfers would fail validation when some products didn't require lot/serial tracking while others did. Now users can validate operations with mixed tracked and non-tracked products, and the system automatically creates backorders for incomplete items instead of blocking the entire operation.
Original PR description
In Settings>Inventory>Operations enable "Batch Transfers" Create a [NonTrackedProd] product: - Product Type: Storable Product - Tracking: No tracking Create a [TrackedProd] product: - Product Type: Storable Product - Tracking: By Lot Create and confirm two POs with: - Prod [NonTrackedProd] qty 1 - Prod [TrackedProd] qty 1 Open Barcode Scanning app Select "Batch Transfers" Create a new batch with the incoming transfers from the POs Set only the [NonTrackedProd] lines as done and validate Issue: Error will block validation "You need to supply a Lot/Serial number for products" The system should let the user validate the operation and create a backorder instead of blocking the user opw-3777701
This fix ensures that only active employees can be assigned to project tasks. Previously, inactive users were appearing in the assignment dropdown, which could lead to tasks being assigned to users who are no longer active in the system. This improves data quality and prevents confusion when managing task assignments.
Original PR description
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task…
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task ### Cause of the issue: Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 is overriden in the view: https://github.com/odoo/odoo/blob/fcd66ee3321649405cf21bc1d625d71abf3d5819/addons/project/views/project_task_views.xml#L649 inactive users will not be filtered out by the domain. On the other hand, they chould still be filtered out during this call because inactive records should automatically be filtered out by the `_where_calc` method, unless explicitely asked for: https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5389 https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5091-L5093 However, since the `'active_test'` is set to `False` in the context of the the `user_ids` field: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 the inactive records will also not be filtered out by the call of the `_where_calc` method. #### Note: Prior to version 17.0, the flow worked "as expected" since the context set in the `user_ids` was not properly taken into account and inactive records were therefore filtered out by the call of this `_where_calc` method. Thanks to commit c3e497f this context is now relevant. opw-3796425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where kit products and their components were being incorrectly mixed together on delivery slip documents. Previously, when generating a delivery slip for orders containing both kit products and regular products, items would appear in the wrong sections. Now kit components appear only under their parent kit, and regular products appear in the correct non-kit section.
Original PR description
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section…
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section "products not associated with a kit" Steps to reproduce: --- 1. Create 4 products (K1,P1,P2,C1,C2) 2. Create a Bills of Materials for K1 3. Set Type as Kit 4. Add C1 and C2 as components 5. Create a sale quotation for K1, P1, P2 6. Set the quantity at 4 for all products 7. On the quotation, click on Delivery 8. In Done, put 4 for P1 and 3 for C1,C2,P2 9. Validate and select No Backorder 10. Click on Print, Delivery Slip 11. In the document: 12. P2 is in the kit section (K1) 13. C1,C2 in the "not associated with a kit" section Expected behaviour: --- Only C1 and C2 should be in the K1 section Only P1 and P2 should be in the "Products not associated with a kit" section opw-3568390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144276
Code cleanup and technical improvements
This update makes tax rounding compensation functionality available to all countries, not just France. Previously, only the French tax report could automatically handle and compensate for rounding differences when closing taxes. Now this capability is built into the core tax reporting system, allowing other countries to benefit from the same functionality without duplicating code.
Original PR description
The tax closing in France did an override of `_postprocess_vat_closing_entry_results` to be able to compute and compensate (by creating a move) difference from rounding taxes. As this functionality starts to be needed in other countries, we extract that method to `account_generic_tax_report` and made it generic. task-3691312 Forward-Port-Of: odoo/enterprise#56510