Friday, March 29, 2024
68 changes · saas-17.2
Enhancements to existing features
This update adjusts internal Gantt app tests to work with recent changes in Odoo’s Hoot testing tools. It helps keep automated quality checks reliable while avoiding changes to customer-facing functionality.
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 Community: https://github.com/odoo/odoo/pull/158916 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 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
This fix ensures spreadsheet-related list views keep the necessary page context when opening related actions. It prevents errors in cases such as project task lists that depend on the current record information, improving reliability for users.
Original PR description
Adding the current list context to the loadAction call in case some element are needed For exemple the active_id was needed in the project task list view Task-3815748
Miscellaneous changes
…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
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 fix ensures appointment resource details are always included when grouping calendar events. It prevents crashes and confusing “Undefined Resources” lines when users switch Studio mode in the Resource Bookings Gantt view.
Original PR description
Be sure that resource_ids info are added in the read_group. Indeed, a traceback was raised when the context key appointment_booking_gantt_domain is removed. This context key added a domain to exclude calendar event without appointment resources. This events can then leads to a line with "Undefined Resources" which made the condition `data.get('appointment_resource_ids')` falsy.
For example, this can happen when we toggle studio mode in the gantt view of "Resource Bookings" menu.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 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
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
* 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. Forward-Port-Of: odoo/enterprise#59739
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. Forward-Port-Of: odoo/enterprise#59739
Before this commit, if the end of a table appointment was ending the day after the start day, the appointment wouldn't be displayed. Fixing this, a new issue arises, if an appointment start the day before, showing it next day will create confusion since it will display the starting time of the previous day. To fix this we simply set the starting time to the start of the day. Forward-Port-Of: odoo/enterprise#59612
Original PR description
Before this commit, if the end of a table appointment was ending the day after the start day, the appointment wouldn't be displayed. Fixing this, a new issue arises, if an appointment start the day before, showing it next day will create confusion since it will display the starting time of the previous day. To fix this we simply set the starting time to the start of the day. Forward-Port-Of: odoo/enterprise#59612
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
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
Previously, splitting an order did not cancel the split order line in the preparation display. This commit ensures that the preparation display is updated correctly when an order is split. opw-3809693 Forward-Port-Of: odoo/enterprise#59554
Original PR description
Previously, splitting an order did not cancel the split order line in the preparation display. This commit ensures that the preparation display is updated correctly when an order is split. opw-3809693 Forward-Port-Of: odoo/enterprise#59554
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. runbot-55570 runbot-55571 runbot-55572 runbot-55573 runbot-55574 Forward-Port-Of: odoo/enterprise#59737
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. runbot-55570 runbot-55571 runbot-55572 runbot-55573 runbot-55574 Forward-Port-Of: odoo/enterprise#59737
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
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 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/enterp
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
Changing the pricelist on a confirmed SO is now forbidden. It was done in a fsm test, but the test is working fine without the pricelist, so the pricelist creation and SO update has been removed. See also: https://github.com/odoo/odoo/pull/157742 Forward-Port-Of: odoo/enterprise#58744
Original PR description
Changing the pricelist on a confirmed SO is now forbidden. It was done in a fsm test, but the test is working fine without the pricelist, so the pricelist creation and SO update has been removed. See also: https://github.com/odoo/odoo/pull/157742 Forward-Port-Of: odoo/enterprise#58744
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()
Original PR description
When using the 'Find missing transactions' from account_online_synchronization module, the `transaction_details` field gets encapsulated in `<p></p>` HTML tags This is caused by that field being declared as a HTML field in the transient model `account.bank.statement.line.transient`, but then as a JSON field in the `account.bank.statement.line` model. That encapsulation causes Python JSON decoder to fail to decode from `transaction_details` when called in `_format_transaction_details()` in the bank reconciliation widget, resulting in a traceback Removing the HTML tags after the call to `read()` in the transient model allows the field to be correctly decoded. opw-3783078 opw-3773454 opw-3772561 and more. Forward-Port-Of: odoo/enterprise#58505
Input type and salary attachment type should match the rule name task-3835119 Forward-Port-Of: odoo/enterprise#59616 Forward-Port-Of: odoo/enterprise#59569
Original PR description
Input type and salary attachment type should match the rule name task-3835119 Forward-Port-Of: odoo/enterprise#59616 Forward-Port-Of: odoo/enterprise#59569
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
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
Planning improvement: - Notify the user when no match is found while using auto plan from a shift. Steps: ----------- - Install planning - Create employee and set role - Open Planning Gantt - Create a new shift - Click on the auto plan issue: ------- dict is returned without value. {'open_shift_assigned': []} task-3774045 Forward-Port-Of: odoo/enterprise#58046
Original PR description
Planning improvement:
- Notify the user when no match is found while using auto plan from a shift.
Steps:
-----------
- Install planning
- Create employee and set role
- Open Planning Gantt
- Create a new shift
- Click on the auto plan
issue:
-------
dict is returned without value.
{'open_shift_assigned': []}
task-3774045
Forward-Port-Of: odoo/enterprise#58046The term "Upsell" has a negative impact on customers in some countries. It has been changed to "Quotation" task_id: 3699064 Forward-Port-Of: odoo/enterprise#58645
Original PR description
The term "Upsell" has a negative impact on customers in some countries. It has been changed to "Quotation" task_id: 3699064 Forward-Port-Of: odoo/enterprise#58645
Steps: - install time sheet module - click on start button - before clicking on start button,width is different - after clicking on start button ,width is different Issue: - the width is unstable,seems different before and after clicking on start button Cause: - The problem occurs because of height issue solution: - if we give the height to that class the problem will be solved task-3645747 Forward-Port-Of: odoo/enterprise#59571 Forward-Port-Of: odoo/enterprise#50100
Original PR description
Steps: - install time sheet module - click on start button - before clicking on start button,width is different - after clicking on start button ,width is different Issue: - the width is unstable,seems different before and after clicking on start button Cause: - The problem occurs because of height issue solution: - if we give the height to that class the problem will be solved task-3645747 Forward-Port-Of: odoo/enterprise#59571 Forward-Port-Of: odoo/enterprise#50100
In the form view, new line were linked to new_id which computed the subscription_state value to a wrong version. Forcing readonly=False ensure the value is fetched from the origin and thus correct when computing the discount. task-id: 3699064 Forward-Port-Of: odoo/enterprise#58604
Original PR description
In the form view, new line were linked to new_id which computed the subscription_state value to a wrong version. Forcing readonly=False ensure the value is fetched from the origin and thus correct when computing the discount. task-id: 3699064 Forward-Port-Of: odoo/enterprise#58604
**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#59561 Forward-Port-Of: odoo/enterprise#58825
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#59561 Forward-Port-Of: odoo/enterprise#58825
The aim of this commit is having a correct Partner VAT listing report. Before this fix, the report has a SQL query that uses the load_more_limit value as the limit. The issue was that we applied the limit on a set of 3 queries, as each of these query computes one column, the report gave us enough line but the last column was wrongly computed (as we exceed the limit after the second query). This means that we had an empty column. It was totally wrong. In the same time, other bugs were found. R
Original PR description
The aim of this commit is having a correct Partner VAT listing report. Before this fix, the report has a SQL query that uses the load_more_limit value as the limit. The issue was that we applied the limit on a set of 3 queries, as each of these query computes one column, the report gave us enough line but the last column was wrongly computed (as we exceed the limit after the second query). This means that we had an empty column. It was totally wrong. In the same time, other bugs were found. Report lines are by default ordered by using the res.partner order (based on the complete name), causing that when we generate the xml report, the groupby (from itertools) wrongly grouped lines as we don't sort these lines on the groupby key (vat number). To avoid this issue, we changed the groupby by using the one from odoo.tools. opw-3802689 opw-3766777 opw-3797584 opw-3791023 Forward-Port-Of: odoo/enterprise#59573 Forward-Port-Of: odoo/enterprise#59454
# [FIX] knowledge: remove the focus on click on anchors This commit fixes an issue where the focus of the user's mouse would be moved to the comment box when clicking on the corresponding anchor. This renders the edition inside of the anchors very hard to do. Now, we removed this behavior and you only trigger the focus when clicking on the comment box. Simplifying the edition of text inside of the anchors. # [FIX] knowledge: remove color superposition in anchors This commit fixes
Original PR description
# [FIX] knowledge: remove the focus on click on anchors This commit fixes an issue where the focus of the user's mouse would be moved to the comment box when clicking on the corresponding anchor. This renders the edition inside of the anchors very hard to do. Now, we removed this behavior and you only trigger the focus when clicking on the comment box. Simplifying the edition of text inside of the anchors. # [FIX] knowledge: remove color superposition in anchors This commit fixes an issue where multiple anchors intertwined inside the body would stack their background colour, rendering the text harder to read. Now, we removed the background colour of the anchors that are inside another one. This way there's no more colour stacking. task-3790314 Forward-Port-Of: odoo/enterprise#58146
Before this commit: The generated XAF file while exporting the general ledger is missing the declaration of the accounts with no lines for the given time period but which have an opening balance. The file contains the information regarding an opening balance for an account that is never declared in the file. This leads to an error for some customers when they send the file to the agency. After this commit: All the accounts with an opening balance but no line for the time period are declared
Original PR description
Before this commit: The generated XAF file while exporting the general ledger is missing the declaration of the accounts with no lines for the given time period but which have an opening balance. The file contains the information regarding an opening balance for an account that is never declared in the file. This leads to an error for some customers when they send the file to the agency. After this commit: All the accounts with an opening balance but no line for the time period are declared in the appropriate section of the XAF file. opw-3567617 opw-3624000 Forward-Port-Of: odoo/enterprise#59575 Forward-Port-Of: odoo/enterprise#53532
Steps to reproduce: ------------------- 1. Create a first FSM task with an assignee (e.g. Mitchel Admin) and a planned date 2. Create a second FSM task with another assignee (e.g. Marc Demo) with the same planned date as in the first task 3. Create a third FSM task with both assignees (e.g. Mitchel Admin and Marc Demo) with again, the same planned date 4. Save the third task or change anything in it 5. A traceback occurs Fix: ------------------- In the computed method "_compute_planni
Original PR description
Steps to reproduce: ------------------- 1. Create a first FSM task with an assignee (e.g. Mitchel Admin) and a planned date 2. Create a second FSM task with another assignee (e.g. Marc Demo) with the…
Steps to reproduce: ------------------- 1. Create a first FSM task with an assignee (e.g. Mitchel Admin) and a planned date 2. Create a second FSM task with another assignee (e.g. Marc Demo) with the same planned date as in the first task 3. Create a third FSM task with both assignees (e.g. Mitchel Admin and Marc Demo) with again, the same planned date 4. Save the third task or change anything in it 5. A traceback occurs Fix: ------------------- In the computed method "_compute_planning_overlap()", the "overlap_mapping" dictionary is iteratively updated with the data of the tasks of the users which overlap with the current one. When there were multiple assignees, it was possible that overlap_mapping[task_id] did not contain the user_id key of the assignee yet, hence the KeyError. To prevent that error, we check whether the user_id key exists and if not, we set it to an empty dictionary that will be filled in afterwards. Tests: ------------------- To be consistent with tests from TestPlanningOverlap in project_enterprise, the same test suite was reproduced for FSM tasks in TestFsmPlanningOverlap. task-3812556 version-17.1 Forward-Port-Of: odoo/enterprise#58824
[FIX] account_inter_company_rules: Fix inter-company invoicing issue This fix is to solve a bug that was introduced due to the new change to multi ids in the key of the analytic distribution where the existing code does not consider that and ends up trying to parse a bunch of comma-separated, string of ids. opw-3756270 Forward-Port-Of: odoo/enterprise#58675 Forward-Port-Of: odoo/enterprise#57159
Original PR description
[FIX] account_inter_company_rules: Fix inter-company invoicing issue This fix is to solve a bug that was introduced due to the new change to multi ids in the key of the analytic distribution where the existing code does not consider that and ends up trying to parse a bunch of comma-separated, string of ids. opw-3756270 Forward-Port-Of: odoo/enterprise#58675 Forward-Port-Of: odoo/enterprise#57159
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794
Original PR description
Community: https://github.com/odoo/odoo/pull/159529 Design Themes: https://github.com/odoo/design-themes/pull/794
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the rule's method the registry will [return](https://github.com/odoo/enterprise/blob/961f67d776a8ec1d9293ed599f284807930496d5/web_studio/models/studio_approval.py#L200) a `None` model, which then causes an AttributeError. We add a check for the Model's existence, so that any None models are skipped. Th
Original PR description
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the…
If a `studio.approval.rule` refers to a non-existing model (e.g. the model was removed, or renamed, or it's a custom model that is not present during an upgrade), then while attempting to patch the rule's method the registry will [return](https://github.com/odoo/enterprise/blob/961f67d776a8ec1d9293ed599f284807930496d5/web_studio/models/studio_approval.py#L200) a `None` model, which then causes an AttributeError.
We add a check for the Model's existence, so that any None models are skipped. This follows the approach in [base_automation](https://github.com/odoo/odoo/blob/d11ece23e97189f38040254917a3517e21386e47/addons/base_automation/models/base_automation.py#L847-L857), which was the technical inspiration for the [commit](https://github.com/odoo/enterprise/commit/3db107ae481a8da85aa356c729bae5fc246e655b) that implemented the approval rule logic.
Ticket: [3754939](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form), [3777251](https://www.odoo.com/web#id=3754939&cids=1&menu_id=4720&action=333&active_id=70&model=project.task&view_type=form)
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 606, in load_modules
model._register_hook()
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 203, in _register_hook
_patch(Model, approval.method, approval_method)
File "/home/odoo/src/enterprise/17.0/web_studio/models/studio_approval.py", line 132, in _patch
ModelClass = model.env.registry[model._name]
AttributeError: 'NoneType' object has no attribute 'env'
```
Forward-Port-Of: odoo/enterprise#58688The wrong number was used for identifying the user to the Belastingdienst through SBR when submitting their Tax Report. This new field has to be added through a new module but will be correctly merged in master. opw-3786956 Forward-Port-Of: odoo/enterprise#59217 Forward-Port-Of: odoo/enterprise#58485
Original PR description
The wrong number was used for identifying the user to the Belastingdienst through SBR when submitting their Tax Report. This new field has to be added through a new module but will be correctly merged in master. opw-3786956 Forward-Port-Of: odoo/enterprise#59217 Forward-Port-Of: odoo/enterprise#58485
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