Wednesday, June 1, 2022
60 changes · master
New functionality added to Odoo
Odoo now lets users initiate full refunds for payments made through Authorize.Net directly from the system. If a transaction has not yet settled and cannot be refunded, Odoo will void it instead, helping teams manage payment reversals without leaving Odoo.
Original PR description
Users can now ask for a refund from Odoo for their transactions done through Authorize.net. A refund will be triggered from Odoo when necessary. Only full refunds are possible. Note that unsettled transactions will be voided as they cannot be refunded. Task - 2678757 Continuation of https://github.com/odoo/odoo/pull/79417 See also - https://github.com/odoo/documentation/pull/2091
Project teams can now connect tasks directly to milestones, making it easier to see what work is needed before a milestone is reached. The update adds milestone-based task filters, progress cues, completion prompts, project sharing visibility, and tighter sales invoicing behavior when milestone billing is enabled or disabled.
Original PR description
Purpose ======= The goal of this PR is to create a link between milestones and tasks. Indeed, milestones usually contain a set of tasks. Once all of these tasks are done, the milestone can be…
Purpose ======= The goal of this PR is to create a link between milestones and tasks. Indeed, milestones usually contain a set of tasks. Once all of these tasks are done, the milestone can be considered as reached. This link would help users organize their projects more efficiently and have a better overview of what needs to be done when. ## Implementation details - A new many2one field is added in the `project.task` called `milestone_id` to link a milestone to tasks. - Add `Milestones` as global setting and project setting. It means the user will can globally enable the feature and choose in which project he wants to use the feature. - In the form view of milestone, a stat button is added to display the tasks linked to current milestone. - Add `Late Milestone` filter in tasks, when this filter is applied the user will see the tasks linked to a milestone with a deadline in the past. This filter is also added in the Burndown chart and Tasks analysis report. - When the user set a milestone on a task and no SOL is found in the project and/or parent task related then set the SOL of the milestone as a default SOL for the task. - Display in green the milestone in project update view if all tasks linked to that milestone are in a closed stage. - When a user changes a stage of a task to a closed stage, a wizard will be displayed if the task is linked to a milestone and all others tasks are in a closed stage too. This wizard will allow the user to reach the milestone since all tasks linked to that milestone are considered as finished. - Remove `delivered_milestone` option in the `invoice_policy` selection field in `product.template` model when the Milestones feature is globally disabled. If some products are milestone one than they will be converted into a manual service ones to allow the user to manually set the quantity delivered for those products. - Display the milestone field in task in Project Sharing feature. task-2829542
Enhancements to existing features
Odoo can now hand off delivery of static files and attachments to the front-end web server when configured to do so. This reduces the load on Odoo workers, helping systems stay responsive during heavy file or image traffic while preserving Odoo's access checks.
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
Original PR description
Suggested review order: 1. odoo/tools/_vendor/send_file.py 2. odoo/http.py 3. odoo/addons/base/models/ir_binary.py 4. odoo/addons/base/models/ir_attachment.py 5. addons/web/controllers/binary.py 6.…
Suggested review order:
1. odoo/tools/_vendor/send_file.py
2. odoo/http.py
3. odoo/addons/base/models/ir_binary.py
4. odoo/addons/base/models/ir_attachment.py
5. addons/web/controllers/binary.py
6. odoo/addons/base/models/ir_http.py
7. odoo/addons/test_http/data.xml
8. odoo/addons/test_http/tests/test_static.py
Then the other files in any order.
Note that `website_slides/models/ir_http.py` was fixing a bug that does not exist anymore in master (verified with the original fix author)
---
Rationales
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
Task: 2801675This 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
Messages in Discuss now show all relevant recipients when appropriate, reducing uncertainty about whether everyone intended was included. This improves transparency for users working with mail and project-related communications.
Original PR description
All the recipients of message were not always displayed in discuss and some users were wondering if the message has been sent to everybody concerned. This solves the problem by allowing to specify whether to display all recipients based on the message sub type and defining for which sub type it must. Task-2429708 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
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
Customer rating updates that trigger a notification are now shown directly in the systray preview. This helps users quickly understand feedback outcomes at a glance using familiar rating faces, without opening the full conversation.
Original PR description
Display the rating changes that generate a notification under the systray. Using the rating faces to represent the result. task-2794182 -- 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.
Users can now drag and drop files anywhere in the chatter to upload them, making attachments easier to discover and use. The file area labels were also clarified and now show either an attachment prompt or the number of files already linked to the record.
Original PR description
**PURPOSE** The attachment icon in the chatter is too discrete, a lot of users easily miss it. **SPECIFICATIONS** - Allow for file upload through drag and drop and the whole chatter. It doesn't matter whether the file tray is unfolded. Hence, removed DropZone on attachmentBox as now have DropZone on the whole chatter. - On the file tray, rename "Attachments" to "Files" and "Add attachments" to "Attach files". - When there are files attached to the record, display "X files". - when there is no file yet, display 'Attach files'. Although clicking on it opens the file explorer, but doesn't unfold the tray yet. Once the file is submitted, the file tray unfolds to show confirmed upload to the user. Task-2413814 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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.
Canceled sales orders and invoices can no longer be paid through existing payment links. When a customer opens a payment link for a canceled document, the payable amount is set to zero, reducing accidental or invalid payments.
Original PR description
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019The 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
Tax searches now ignore punctuation and spaces, making it easier to find the right tax while editing invoices or configuring tax settings. Users can type compact shortcuts like “21M” or “0EUT” and still see matching tax names with symbols, spaces, or punctuation.
Original PR description
This PR improves tax name search by ignoring punctuation and spaces. This allows faster searching for taxes (while editing an invoice line or while configuring them) Example: Searching for `21M` should match `21% M.` , `21% EU M.` and `21% M.Cocont`. Searching for `0EUT` should match `0% EU T`. Task id: 2851341
Course publishing is now better synchronized with linked products, preventing shared products from being unpublished too aggressively and keeping eligible learners' access intact. When a course cannot be purchased because its product is unpublished, the storefront now shows clearer messaging for customers and administrators.
Original PR description
This commit adds a couple improvement to the "publish" flow of courses: - Improve the published synchronization between the course and its product - Adapt wording when the course is unavailable on the frontend view See underlying commits for details. task-2842624
The eLearning course interface now uses clearer wording by replacing technical “slide” language with “content” and protects key action buttons from accidental edits. Certification creation is smoother, guiding users directly to add survey questions after creating a certification.
Original PR description
- Added o_not_editable class to buttons to prevent them from being edited - Changed the word 'slide' to 'content' at various locations - Changed the button redirecting to the certification of the full screen mode to match the button of the regular screen mode - Changed the text of the button suggesting to install the survey module when adding a new content - Fixed several missalignments - Changed the modal opened after that the survey module installation suggestion button has been used. Now opens the certification upload modal. - Added a redirection to the linked survey when a certification is created, as well as a button on the page suggesting to add questions to the survey when the user has been redirected after the certification creation.
This update improves day-to-day manufacturing and repair workflows with clearer labels, better filtering of inactive operations, and more reliable transfer creation. Repair users can now manually select valid return pickings, helping reduce mistakes and follow-up corrections.
Original PR description
[IMP] mrp, repair: various back2basics fixes MRP back to basics small fixes and improvements, see individual commits for more details Task Id: 2825321 Enterprise PR: https://github.com/odoo/enterprise/pull/27577 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event attendees now get clearer next steps after registering, reducing dead ends. Free event confirmations link back to the event, while paid event confirmations show the events purchased so customers can easily review what they bought.
Original PR description
Purpose ======= Avoid having "dead-ends" when registering to an event. Specifications ============= Add link to event to registration confirmation for free events. Display list of each bought event on the confirmation page for paid events. Task-2657635
Tax searches now ignore spaces and punctuation, making it easier to find the right tax by typing short codes like 21M or 0EUT. This helps users work faster when editing invoice lines or configuring tax settings.
Original PR description
This PR improves tax name search by ignoring punctuation and spaces. This allows faster searching for taxes (while editing an invoice line or while configuring them) Example: Searching for `21M` should match `21% M.` , `21% EU M.` and `21% M.Cocont`. Searching for `0EUT` should match `0% EU T`. Task id: 2851341 Old PR with remarks: https://github.com/odoo/odoo/pull/91667
The EC sales report now provides clearer totals, more specific error categories, and direct links to the accounting entries behind issues. Belgian reporting also gains an automated consistency check against the tax report, helping finance teams validate filings more easily.
Original PR description
- Refactor _process_query_result to avoid code repetition in BE report, generic report and base report. - Correct typos. - Add Total line. - Split 'same country' and 'non ec country' single error int two distinct errors. - Add links to aml's moves causing errors. - For belgian report, cross check results with tax report where ec sale report total must equal tax report lines 44 + 46L + 46T - (48s44 + 48s46L + 48s46T). - Allow auditing each report line. Task: 2730151
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>
Project milestones can now be connected to the tasks that contribute to them, giving teams a clearer view of progress toward key project goals. Field Service projects keep milestones disabled by default, while reporting now makes it easier to search and group planning and timesheet data by milestone.
Original PR description
Purpose ======= The goal of this PR is to create a link between milestones and tasks. Indeed, milestones usually contain a set of tasks. Once all of these tasks are done, the milestone can be considered as reached. This link would help users organize their projects more efficiently and have a better overview of what needs to be done when. ## Implementation details The implementation is the continuity of odoo/odoo#90972 to use the milestones feature in the enterprise views and also in Fields Services app or even in `Timesheets and Planning analysis` report (by adding the quick search on milestone linked to task and the group by Milestones). However, the `Milestones` feature and also avoid enabling the Milestones feature on fsm project by default. task-2829542
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
Website appointment pages now apply a site's custom background color more consistently across the booking flow. Visual elements such as cards and readable sections adapt better to theme colors, helping maintain a polished and legible customer experience.
Original PR description
PURPOSE: When using a custom background color, it is now used everywhere in website appointment. To maintain good readability, some components have now a style that depends on the theme's colors. Task-2835882
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
Static files used by Documents, Instagram integration, and push notifications are now handed off to the main web delivery mechanism instead of being served directly by each feature. This should improve consistency and performance while reducing maintenance complexity behind the scenes.
Original PR description
Task: 2801675 See odoo/odoo#88134
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