Wednesday, June 1, 2022
43 changes · master
Enhancements to existing features
This update makes error messages more specific when a report or grouped view cannot use a selected field. Instead of requiring technical debugging to identify the problem field, the message now points directly to it, helping teams resolve configuration issues faster.
Original PR description
Avoid to debug to find which field is not stored. **Description of the issue/feature this PR addresses:** Avoid to debug to find which field is not stored. Normally, you have one field in the 'groupby' clause, but you may have more than one. **Current behavior before PR:** In case you get that error, you then have to debug to know which field is causing the error, which is a waste of time. **Desired behavior after PR is merged:** The error shows which field is causing the error. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now download image attachments directly from the chatter by hovering over the image and clicking a download icon. This makes saving shared images quicker and more discoverable without changing the underlying attachment workflow.
Original PR description
**Current behavior before PR:** Improve how image attachments are downloaded from the chatter by adding the `download` button when hovering image files **Desired behavior after PR is merged:** add a `Download` button (icon) on the bottom right corner of image attachments on hover Task-2802810 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies internal documentation for a mail testing helper related to screen size handling. It helps maintain reliable automated tests while avoiding changes to customer-facing behavior.
Original PR description
patchUiSize used to patch both legacy and wowl sizes (browser, env.device, ...). Now that the wowl env is used in the discuss app, patching the legacy sizes is useless. This PR cleans this dead code.
This update removes an unnecessary layout setting from the Discuss app's full-screen view. It keeps the screen behavior the same while simplifying the underlying styling, reducing maintenance overhead for future changes.
Original PR description
DiscussContainer is specific component for content of Discuss app in "whole screen" client action. The parent is not flex, so it needs `h-100` to take the whole screen. Consequently, `min-height: 0` is useless, hence this commit removes it.
The mail module now includes a shared throttling mechanism to better manage repeated actions and updates. This helps keep messaging interactions smoother and more reliable by preventing unnecessary rapid processing behind the scenes.
Original PR description
Task-2831082
This update improves internal spreadsheet test files so development tools can better understand them. It helps maintain code quality and reduces noise for developers, with no expected change for end users.
Original PR description
Very usefull if you have a tsconfig.json file, otherwise everything is red :) Co-authored-by: Rémi Rahir <rar@odoo.com>
The manufacturing work order timer setting is now shown in the manufacturing settings area, making it easier for users to find and manage. The subscription label on analytic account forms was updated to a clearer sales-related wording.
Original PR description
[IMP] mrp_workorder, sale_subscription: back2basics mrp_workorder: The timer setting was moved to mrp instead of stock sale_subscription: label changed Task Id: 2825321 COM PR: https://github.com/odoo/odoo/pull/91879
This update adjusts automated checks for the mail chatter's file drag-and-drop behavior. It helps ensure attachment previews continue to work reliably as the drag-and-drop experience is improved.
Original PR description
qunit adapt Task-2413814
Resolved issues and error corrections
The Point of Sale action used for home-page login setup has been renamed from “Open POS Menu” to “Reload POS Menu.” This makes the action’s purpose clearer for administrators configuring internal users to land directly on the POS menu.
Original PR description
Some users use home action to have internal users directly login on the pos menu but trying to do so is difficult because of the current misleading names: "Open POS Menu" is a client action used in the code to reload the page so a better fit would be "Reload POS Menu" ~~There are two "Point of Sale" actions thus changing them to "Point of Sale Configuration" and "Point of Sale Menu" is relevant.~~ opw-2830883
Features or functions removed from Odoo
An unused attachment template was removed from the Live Chat module. This is a minor cleanup that reduces obsolete code without changing the customer-facing chat experience.
Original PR description
The Attachments xml template is not used anymore, It can be deleted safely Task-2825235
Code cleanup and technical improvements
This update reorganizes mock server tests into a single place and applies code style cleanup. It helps keep the web module's automated checks easier to maintain without changing business functionality.
Original PR description
Also lint the mock_server file. 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
Documentation and clarification updates
This pull request updates a corporate contributor license agreement document for Eskatr. It helps keep contribution permissions current so fixes can be submitted under the required legal terms.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: We cannot send fixes Desired behavior after PR is merged: We can send fixes -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit When removing the style of a link in an html_field, the style was not removed. After this commit When removing the style of a link in an html_field, the style is removed. task-2857072 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92506
Original PR description
Before this commit When removing the style of a link in an html_field, the style was not removed. After this commit When removing the style of a link in an html_field, the style is removed. task-2857072 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92506
This change removes an outdated layout setting from the Discuss messaging area. It keeps the interface code aligned with the current page structure and reduces the chance of unnecessary layout side effects.
Original PR description
The discuss container used to have a flex parent but hasn't anymore (its parent is now the actionManagerContainer instead of the discussWidget). The flex-grow class has now become useless. This PR removes it.
This fixes an issue in the Mail app’s internal data handling so certain update instructions are accepted correctly. It helps prevent errors in mail-related features and improves stability without changing the user experience.
The live chat code has been reorganized by moving one of its display templates into its own dedicated file. This makes the module easier to maintain without changing how customers or website visitors use live chat.
Original PR description
The goal is to split the public_livechat.xml file into multiple parts, and move each template into its own file located in `im_livechat/static/src/legacy/widgets/` Task-2825235
The live chat feedback template was moved into its own dedicated file as part of a cleanup of the live chat interface files. This makes the codebase easier to maintain without changing how users experience live chat.
Original PR description
The goal is to split the public_livechat.xml file into multiple parts, and move each template into its own file located in `im_livechat/static/src/legacy/widgets/` Task-2825235
The live chat interface files were reorganized by moving the chat thread template into its own dedicated file. This makes the live chat codebase easier to maintain and update without changing the customer-facing behavior.
Original PR description
The goal is to split the public_livechat.xml file into multiple parts, and move each template into its own file located in `im_livechat/static/src/legacy/widgets/` Task-2825235
The live chat code has been reorganized by moving the document viewer template into its own dedicated file. This makes the module easier to maintain and update without changing how users experience live chat.
Original PR description
The goal is to split the public_livechat.xml file into multiple parts, and move each template into its own file located in `im_livechat/static/src/legacy/widgets/` Task-2825235
Steps to reproduce: install crm and change a lead between two won stages Expected behavior: The date_closed does not change Current behavior: The date_closed changes opw-2839298 Forward-Port-Of: odoo/odoo#92455 Forward-Port-Of: odoo/odoo#90774
Original PR description
Steps to reproduce: install crm and change a lead between two won stages Expected behavior: The date_closed does not change Current behavior: The date_closed changes opw-2839298 Forward-Port-Of: odoo/odoo#92455 Forward-Port-Of: odoo/odoo#90774
Reproduction : Install "Finnish Localization", go on chart of accounts and add tag_ids on the tree view. Current behavior before PR: There are some mismatches between the tags and the accounts Desired behavior after PR is merged: Tags are modified/created/deleted to have no mismatch and to correspond to Finnish accounting opw-2702912 Forward-Port-Of: odoo/odoo#88198
Original PR description
Reproduction : Install "Finnish Localization", go on chart of accounts and add tag_ids on the tree view. Current behavior before PR: There are some mismatches between the tags and the accounts Desired behavior after PR is merged: Tags are modified/created/deleted to have no mismatch and to correspond to Finnish accounting opw-2702912 Forward-Port-Of: odoo/odoo#88198
Steps to reproduce: - In CRM seetings, activate Leads - Create a sales team with "Pipeline" selected in Sales Teams Settings - Set a form. The action is "create opportunity" and the Sales Team is the one you created - Send a form Issue: A lead will be created. Not opportunity. Solution: Fetch the info related to the team opw-2856520 Forward-Port-Of: odoo/odoo#92143
Original PR description
Steps to reproduce: - In CRM seetings, activate Leads - Create a sales team with "Pipeline" selected in Sales Teams Settings - Set a form. The action is "create opportunity" and the Sales Team is the one you created - Send a form Issue: A lead will be created. Not opportunity. Solution: Fetch the info related to the team opw-2856520 Forward-Port-Of: odoo/odoo#92143
Continuity of b859d78c. The assets generated for project sharing feature suffer from the same issue than `point_of_sale`. In master, we have to properly declare every file we need instead of realying on the whole `web.assets_backend`. Part of task 2860257 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92490 Forward-Port-Of: odoo/odoo#92326
Original PR description
Continuity of b859d78c. The assets generated for project sharing feature suffer from the same issue than `point_of_sale`. In master, we have to properly declare every file we need instead of realying on the whole `web.assets_backend`. Part of task 2860257 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92490 Forward-Port-Of: odoo/odoo#92326
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.0-beta-8 Fixes ----- - portal: allow use of expression to describe portal target - compiler: fix issue with identifiers with same name - reactivity: fix memory leak - app: validate props for root component in dev mode Improvements ------------ - component: display nice error for wrong child component - props_validation: have clearer error messages - component: only useState on props that are already reactive - comp
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.0-beta-8 Fixes ----- - portal: allow use of expression to describe portal target - compiler: fix issue with identifiers with same name -…
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.0-beta-8 Fixes ----- - portal: allow use of expression to describe portal target - compiler: fix issue with identifiers with same name - reactivity: fix memory leak - app: validate props for root component in dev mode Improvements ------------ - component: display nice error for wrong child component - props_validation: have clearer error messages - component: only useState on props that are already reactive - compiler: add better support for "in" and "new" operators in templates - misc: export the validate function - app: add setting to warn if no static props object - add static App.registerTemplate and update Portal to use it - add basic infrastructure to buid owl-runtime without compiler Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92513
Since [1] which tried to fix the data-oe-xpath branding on nodes in some cases, the branding actually became potentially incorrect on siblings of a node which is replaced multiple times. E.g. Parent view: ```xml <hello> <world class="a"></world> <world class="b"></world> <world class="c"></world> </hello> ``` Child view 1: ```xml <xpath position="//world[hasclass('a')]" position="replace"> <world class="new_a"></world> </xpath> ``` Child view 2: ```x
Original PR description
Since [1] which tried to fix the data-oe-xpath branding on nodes in some cases, the branding actually became potentially incorrect on siblings of a node which is replaced multiple times. E.g. Parent…
Since [1] which tried to fix the data-oe-xpath branding on nodes in some
cases, the branding actually became potentially incorrect on siblings of
a node which is replaced multiple times. E.g.
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
<world class="c"></world>
</hello>
```
Child view 1:
```xml
<xpath position="//world[hasclass('a')]" position="replace">
<world class="new_a"></world>
</xpath>
```
Child view 2:
```xml
<xpath position="//world[hasclass('b')]" position="replace">
<world class="new_b"></world>
</xpath>
```
No problem, two distincts elements are replaced, the system understands
that the `data-oe-xpath` of the third world of the parent view should be
`/hello[1]/world[3]`.
But in this other case:
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
<world class="c"></world>
</hello>
```
Child view:
```xml
<xpath position="//world[hasclass('a')]" position="replace">
<world class="new_a"></world>
</xpath>
```
Child view of the child view:
```xml
<xpath position="//world[hasclass('new_a')]" position="replace">
<world class="another_new_a"></world>
</xpath>
```
The `data-oe-xpath` of the third world of the parent view (in the
resulting view) was wrong: `/hello[1]/world[4]` -> because the system
saw two replacements + the unreplaced second `<world>`, so the index "4"
was computed.
Now the system will understand that the double replacement in fact acts
as a single replacement.
Note: this was also the same with "cross inheriting" (if the "new_a"
`<world>` of the child view was replaced by another child view of the
parent view).
At last, another 4th case was found and worth mentioning because it is
in fact the root cause of the problem. The problem is not actually the
double replacement as mentioned above but simply the replacement of a
root level element of a child view (which is what is basically done in
the last two mentioned cases). In that case, the root level nodes added
by the first child view have already their `data-oe-xpath` branding
computed before they are potentially replaced. Indicating the location
of the replacement in that case was thus only leading to bugs. E.g.
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
</hello>
```
Child view:
```xml
<xpath expr="//world[hasclass('a')]" position="after">
<world class="x"></world>
<world class="y"></world>
</xpath>
```
Child view of the child view:
```xml
<xpath expr="//world[hasclass('x')]" position="replace"/>
```
Before this commit, before the branding is distributed, the result is:
```xml
<hello data-oe-model="ir.ui.view" data-oe-id="1439" data-oe-field="arch">
<world class="a"/>
<?apply-inheritance-specs-node-removal world?>
<world class="y" data-oe-id="1440" data-oe-xpath="/data/xpath/world[2]" data-oe-model="ir.ui.view" data-oe-field="arch"/>
<world class="b"/>
</hello>
```
=> Hence the `data-oe-xpath` of the last `<world>` was computed to
`/hello[1]/world[3]` instead of `/hello[1]/world[2]` after branding
distribution because the ProcessingInstruction marking the node
removal location should not have been added: it could only be useful
to following siblings which are not branded, which is not possible as
the branding added on the second `<world>` of the child view
(`/data/xpath/world[2]`) was computed before any removal.
Tests are added in this commit for the 3 last mentioned cases. As
explained, the last case is actually the same of the 2nd and 3rd ones
but it was decided to keep the 3 tests as it helps to understand the
problems better and, if the code evolves, it could become different
cases (= this is 3 cases which are currently technically equivalent but
these are different functionnal use cases). A test was written for the
first case then removed as it is basically a pure copy of other existing
tests written in [2] (trying to be improved by [1]).
[1]: https://github.com/odoo/odoo/commit/f67832a3ae0d9a3b5b53129132762e6bc1aed874
[2]: https://github.com/odoo/odoo/commit/c077ef05575d9677bce284195683f96c68386788
Forward-Port-Of: odoo/odoo#92570
Forward-Port-Of: odoo/odoo#92374Steps to reproduce: - Create a Time off Type for which an allocation can be requested by the employee and with approval "Set by Time Officer" - Set a Time Off approver on the employee - Create an allocation Current behavior: The allocation approval activity is assigned to the employee Expected behavior: The allocation approval activity is assigned to the time off officer Explanation: The first fix commit c2bac984f2de160008b27fb52b1d0ae7abd02abb didn't take into consideration the
Original PR description
Steps to reproduce: - Create a Time off Type for which an allocation can be requested by the employee and with approval "Set by Time Officer" - Set a Time Off approver on the employee - Create an allocation Current behavior: The allocation approval activity is assigned to the employee Expected behavior: The allocation approval activity is assigned to the time off officer Explanation: The first fix commit c2bac984f2de160008b27fb52b1d0ae7abd02abb didn't take into consideration the "Set by Time Officer" approval, we add here this possible value "set" in order to have a complete fix. opw-2849972 previous pr: https://github.com/odoo/odoo/pull/91291 Forward-Port-Of: odoo/odoo#92545
Description of the issue/feature this PR addresses: Mollie shows a 404 page when only one payment method is active Mollie supports multiple payment methods, these payment methods can be enabled/disabled from the mollie dashboard. When you activate only one payment method from the mollie dashboard, you will get a 404 page instead of a payment page. This commit will fix that issue by providing the necessary query parameters in the URL. Current behavior before PR: Desired behavior afte
Original PR description
Description of the issue/feature this PR addresses: Mollie shows a 404 page when only one payment method is active Mollie supports multiple payment methods, these payment methods can be enabled/disabled from the mollie dashboard. When you activate only one payment method from the mollie dashboard, you will get a 404 page instead of a payment page. This commit will fix that issue by providing the necessary query parameters in the URL. Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92582 Forward-Port-Of: odoo/odoo#92422
Before this commit: if a user is the attendee of an event containing a private contact, the user couldn't sync with google calendar. Because of the "res.partner.rule.private.employee" record rule restriction. Steps to reproduce the issue: 1. Create users A and B 2. Enable "Access to Private Addresses" for user A and disable it for B 3. Login with user A 4. Integrate with Google Calendar in setting 5. Create a contact with private address (type = 'private') 6. Sync with Google Ca
Original PR description
Before this commit: if a user is the attendee of an event containing a private contact, the user couldn't sync with google calendar. Because of the "res.partner.rule.private.employee" record rule…
Before this commit: if a user is the attendee of an event containing a private contact, the user couldn't sync with google calendar. Because of the "res.partner.rule.private.employee" record rule restriction. Steps to reproduce the issue: 1. Create users A and B 2. Enable "Access to Private Addresses" for user A and disable it for B 3. Login with user A 4. Integrate with Google Calendar in setting 5. Create a contact with private address (type = 'private') 6. Sync with Google Calendar in the calendar module 7. Create an event with user B and the private contact as attendees 8. Reset account of google calendar from user A setting 9. Login with user B 10. Try to sync with Google Calendar => You will receive an access error The solution is to give access for accessing to the private contact email address. opw-2850552 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92530 Forward-Port-Of: odoo/odoo#91309
In mass mailing, when an iframe is loaded, the `contentDocument.body` could be `undefined` this caused a traceback when trying to observe the iframe. Observing the `contentDocument` is safer as it will always be defined. task-2869490 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92600
Original PR description
In mass mailing, when an iframe is loaded, the `contentDocument.body` could be `undefined` this caused a traceback when trying to observe the iframe. Observing the `contentDocument` is safer as it will always be defined. task-2869490 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92600
On 02eba891cb8cd58985837090f2b60cf263bce065 we changed https://github.com/odoo/odoo/blob/b5cf1ee3e21f2e60b8edd64f24c04c952fb7df3f/addons/payment/models/account_payment.py#L47 to https://github.com/odoo/odoo/blob/02eba891cb8cd58985837090f2b60cf263bce065/addons/payment/models/account_payment.py#L47-L48 Effectively moving the place where `sudo` is called. This causes issues during migration of some DBs upg-328570 Description of the issue/feature this PR addresses: Current behavior be
Original PR description
On 02eba891cb8cd58985837090f2b60cf263bce065 we changed https://github.com/odoo/odoo/blob/b5cf1ee3e21f2e60b8edd64f24c04c952fb7df3f/addons/payment/models/account_payment.py#L47 to https://github.com/odoo/odoo/blob/02eba891cb8cd58985837090f2b60cf263bce065/addons/payment/models/account_payment.py#L47-L48 Effectively moving the place where `sudo` is called. This causes issues during migration of some DBs upg-328570 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92527
Forward-Port-Of: odoo/odoo#92548
Original PR description
Forward-Port-Of: odoo/odoo#92548
Ensure the selection in the fonts tags after `applyColor`, otherwise an undetermined race condition could generate a wrong selection during multiples call of `_processAndApplyColor` from the color picker. task-2822221 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#90960
Original PR description
Ensure the selection in the fonts tags after `applyColor`, otherwise an undetermined race condition could generate a wrong selection during multiples call of `_processAndApplyColor` from the color picker. task-2822221 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#90960
Description of the issue/feature this PR addresses: When https://github.com/odoo/odoo/blob/13.0/addons/product/models/product_attribute.py#L352 is called with ptav_to_unlink empty causes https://github.com/odoo/odoo/blob/13.0/addons/product/models/product.py#L386 to be called empty as well, which in turn causes the flush method to be called in self, where self is an empty recordset. This flush method on an empty recordset in https://github.com/odoo/odoo/blob/13.0/addons/product/models/produc
Original PR description
Description of the issue/feature this PR addresses: When https://github.com/odoo/odoo/blob/13.0/addons/product/models/product_attribute.py#L352 is called with ptav_to_unlink empty causes https://github.com/odoo/odoo/blob/13.0/addons/product/models/product.py#L386 to be called empty as well, which in turn causes the flush method to be called in self, where self is an empty recordset. This flush method on an empty recordset in https://github.com/odoo/odoo/blob/13.0/addons/product/models/product_attribute.py#L250 causes, in turn, a cascade of unnecessary queries that negatively affects performance. Desired behavior after PR is merged: The unlink should only occur when there are actually records to unlink -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#92396
Current behavior before PR: When editing a mailing in "wide" mode, the emoji widget is outside of the subject field Desired behavior after PR is merged: The emoji widget will be inside the subject field Task: https://www.odoo.com/web#id=2826521&menu_id=4720&cids=2&action=4043&model=project.task&view_type=form -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#82945
Original PR description
Current behavior before PR: When editing a mailing in "wide" mode, the emoji widget is outside of the subject field Desired behavior after PR is merged: The emoji widget will be inside the subject field Task: https://www.odoo.com/web#id=2826521&menu_id=4720&cids=2&action=4043&model=project.task&view_type=form -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#82945
When instrumenting the Chrome Browser and asking to navigate to a location, it happens that the 10 seconds timeout is exceeded. This happens particularly when executing qunit tests by navigating to `/web/tests`. This route has an average loading time around 7 seconds but when the runbot is loaded, it can exceed 10 seconds. With this commit, the timeout is set to 15s. It would be better to split the qunit tests by module in order to avoid the huge assets bundle generation. Forward-Por
Original PR description
When instrumenting the Chrome Browser and asking to navigate to a location, it happens that the 10 seconds timeout is exceeded. This happens particularly when executing qunit tests by navigating to `/web/tests`. This route has an average loading time around 7 seconds but when the runbot is loaded, it can exceed 10 seconds. With this commit, the timeout is set to 15s. It would be better to split the qunit tests by module in order to avoid the huge assets bundle generation. Forward-Port-Of: odoo/odoo#92657
If a future depreciation entry is reverted, currently, the pause is prevented. So we can never pause an asset if an entry is posted in the future. We now accept reverted entries (the same way as for a disposal/sale) Forward-Port-Of: odoo/enterprise#27935 Forward-Port-Of: odoo/enterprise#27929
Original PR description
If a future depreciation entry is reverted, currently, the pause is prevented. So we can never pause an asset if an entry is posted in the future. We now accept reverted entries (the same way as for a disposal/sale) Forward-Port-Of: odoo/enterprise#27935 Forward-Port-Of: odoo/enterprise#27929
Before this commit: When executing activities, all marketing.traces are read, then sorted by activity. This can timeout on large enough marketing campaigns, and no marketing emails are ever sent. After this commit: Since we have the activity_ids available, we just fetch the relevant traces, and pre-sort them. This reduces the execution time for that part of the code to a few seconds even on several hundred records, and the server has time to start processing emails.
Original PR description
Before this commit: When executing activities, all marketing.traces are read, then sorted by activity. This can timeout on large enough marketing campaigns, and no marketing emails are ever sent. After this commit: Since we have the activity_ids available, we just fetch the relevant traces, and pre-sort them. This reduces the execution time for that part of the code to a few seconds even on several hundred records, and the server has time to start processing emails. Related tickets: 2832422, 2524780 Forward-Port-Of: odoo/enterprise#27895 Forward-Port-Of: odoo/enterprise#26944
Starting July 2022, Amazon will disable some endpoints of the MWS API in favor of the new Selling Partners API (SP-API). This commit adds a new module `sale_amazon_spapi` to patch the business methods of the currently existing modules of the Amazon Connector and interface with the SP-API. Some changes are made to the base modules too but these should still function normally until Amazon disables the MWS API or the new module is installed. task-2466636 See also: - https://github.c
Original PR description
Starting July 2022, Amazon will disable some endpoints of the MWS API in favor of the new Selling Partners API (SP-API). This commit adds a new module `sale_amazon_spapi` to patch the business methods of the currently existing modules of the Amazon Connector and interface with the SP-API. Some changes are made to the base modules too but these should still function normally until Amazon disables the MWS API or the new module is installed. task-2466636 See also: - https://github.com/odoo/iap-apps/pull/419 - https://github.com/odoo/documentation/pull/1654 Forward-Port-Of: odoo/enterprise#27913 Forward-Port-Of: odoo/enterprise#18597
Before this PR: In delivery guides, if the quantity_done is 0 because of partial delivery, and there is no backorder the amount of the quantity is shown as it is, in 0. This is not acceptable for a delivery guide. After the PR: the lines with the quantity in 0 are skipped from the delivery guide. Forward-Port-Of: odoo/enterprise#27485 Forward-Port-Of: odoo/enterprise#26428
Original PR description
Before this PR: In delivery guides, if the quantity_done is 0 because of partial delivery, and there is no backorder the amount of the quantity is shown as it is, in 0. This is not acceptable for a delivery guide. After the PR: the lines with the quantity in 0 are skipped from the delivery guide. Forward-Port-Of: odoo/enterprise#27485 Forward-Port-Of: odoo/enterprise#26428
…ting XAF file Exporting the XAF file from the general ledger can lead to errors when checking with the xsd file because some values inside a journal item (like partner_id) might be NULL. Also adapt template files to avoid errors when the xsd is checked. With template xaf_audit_file: Shorten the phone, zip and street_number if it is too long. With template xaf_audit_file_v2: Shorten the phone, zip and street_number if it is too long. Change some condiftions to better match xaf_au
Original PR description
…ting XAF file Exporting the XAF file from the general ledger can lead to errors when checking with the xsd file because some values inside a journal item (like partner_id) might be NULL. Also adapt template files to avoid errors when the xsd is checked. With template xaf_audit_file: Shorten the phone, zip and street_number if it is too long. With template xaf_audit_file_v2: Shorten the phone, zip and street_number if it is too long. Change some condiftions to better match xaf_audit_file. opw-2786991 opw-2828518 Forward-Port-Of: odoo/enterprise#27325 Forward-Port-Of: odoo/enterprise#26865
With the update to owl 2.0.0-beta-8, the props validation system is slightly more strict, which causes the home menu to fail, because the webIcon props is declared mandatory. Forward-Port-Of: odoo/enterprise#27908
Original PR description
With the update to owl 2.0.0-beta-8, the props validation system is slightly more strict, which causes the home menu to fail, because the webIcon props is declared mandatory. Forward-Port-Of: odoo/enterprise#27908
It was not possible to load a cell containing an Odoo link from the data because its constructor was using getters declared in a UI plugin. When importing the data, such plugins are not yet loaded and should not be used to create core data anyway. In order to import such cells, there are to requirements: - the cells constructors need to be loaded before we start the import process - the constructors need to access the env services (specifically `menu`) To solve this issue, we introdu
Original PR description
It was not possible to load a cell containing an Odoo link from the data because its constructor was using getters declared in a UI plugin. When importing the data, such plugins are not yet loaded and should not be used to create core data anyway. In order to import such cells, there are to requirements: - the cells constructors need to be loaded before we start the import process - the constructors need to access the env services (specifically `menu`) To solve this issue, we introduce a new service `spreadsheetLinkMenuCell` which sole purpose is to load the different odoo link constructors to the cell factory, before we create an instance of `Model`, hence before the import process. Task 2860257 Forward-Port-Of: odoo/enterprise#27890 Forward-Port-Of: odoo/enterprise#27721
Step to reproduce: - Go to 'My timesheet' - Select a cell with no data - Update the value multiple time Current behaviour: - Multiple timesheet adjustement are created - The domain of a row is the union of the domain of the cell with data comprised in the row. In our case, date should never be related to the row and so restrict our search of existing line related to the row. Behaviour after PR: - Date is not taken into account when looking for an AAL related to the row. opw-[2
Original PR description
Step to reproduce: - Go to 'My timesheet' - Select a cell with no data - Update the value multiple time Current behaviour: - Multiple timesheet adjustement are created - The domain of a row is the union of the domain of the cell with data comprised in the row. In our case, date should never be related to the row and so restrict our search of existing line related to the row. Behaviour after PR: - Date is not taken into account when looking for an AAL related to the row. opw-[2745572](https://www.odoo.com/web#id=2745572&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#27639 Forward-Port-Of: odoo/enterprise#27000