Tuesday, June 14, 2022
38 changes · master
Enhancements to existing features
This update makes Odoo's dialog service available in older web interface components. It helps keep legacy screens compatible with newer interface capabilities, reducing friction for future improvements.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail module now uses a standard built-in escaping tool instead of a custom one. This reduces duplicate code and helps keep message-related display behavior easier to maintain without changing day-to-day user workflows.
Original PR description
We instead use the standard owl.utils.escape. This allows having less custom implementations of escaping and rely on existing tools. Task-2622893 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update separates how Odoo tracks web controllers from how it builds routing maps, making the web request system easier to evolve. It lays groundwork for future improvements such as websocket support while keeping current website behavior stable.
Original PR description
Some ideas for websocket...
The CRM helper text is improved for users who are not assigned to a sales team. When users have the right permissions, the message now includes a direct link to the sales team setup area, making it easier to resolve the issue and start using their pipeline.
Original PR description
In the current version, the wording of the helper in CRM does not have a hyperlink to redirect to the sales team if the user does not have a member of any sales team. This commit Improve the wording of the helper and also add the hyperlink to redirect the sales team if the user does not have a member of any sales team and has enough access rights. task-2846401 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves internal test tools so they now report an error when a simulated user action targets something hidden on the page. This helps developers spot faulty tests faster and reduces the risk of unclear failures during quality checks.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Automated tests were adjusted to match a stricter validation behavior in Odoo's test tools. This helps ensure hidden interface elements are not incorrectly used during testing, improving confidence in future changes without affecting end users directly.
Original PR description
This commit is the counter part of odoo/odoo#93549 which makes the triggerEvent test utils throw an error if the target is invisible. Due to this change of behavior, some tests needed to be adapted.
Several Odoo apps now use a shared internal-user check instead of repeating the same group check. This keeps behavior consistent across appointment scheduling, documents spreadsheets, and VoIP while reducing maintenance risk.
Original PR description
`_is_internal` is now used in the codebase where it is clear that
`.has_group('base.group_user')` was called on a single record.
Part of Task-2762102
See odoo/odoo#85703The Belgian reports module no longer shows a broken web link in the citizen identification help text. This avoids confusing users with a link that led to a missing page and could not be easily clicked or copied from the help popup.
Original PR description
SPECIFICATION Currently the link in the citizen identification help attribute leads to a 404 page and even if it worked it's not possible for one to click on it nor copy it since it's displayed in the help popup. It's thus removed from the help. LINKS Task-2821356
Social posts and comments now display more cleanly, with fewer unwanted spaces around content such as emojis and better handling of long links. The update also improves how links and hashtags are recognized, helping posts remain readable and clickable while preserving existing URL parameters.
Original PR description
@ validators & reviewers: I added a minor change since I spotted unnecessary spaces within the social.post kanban rendering. Could be merged in rebase-ff. Tell me if you want me to split PRs / tasks.
Resolved issues and error corrections
This update corrects a missed internal reference in the Mail call interface that could cause a crash. It helps keep call-related screens stable for users after a recent change.
Original PR description
Change forgotten references to `state` to references to the record. Fix crash introduced in https://github.com/odoo/odoo/pull/93330/
Features or functions removed from Odoo
An obsolete Sales menu entry with no action or submenus was removed. This keeps the system cleaner by eliminating a menu item that served no purpose and reduced unnecessary clutter in the code and database.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update cleans up internal layout code in the Mail app, including naming changes that make the code easier to maintain. It does not introduce visible feature changes, but supports future improvements by keeping the calling interface code more consistent.
Original PR description
part of task-2692836
Miscellaneous changes
This update adjusts an internal test threshold for Belgian payroll payslip PDF generation after a small unpredictable increase in database activity. It helps keep automated testing reliable while the team investigates the underlying cause, with no expected change for users.
Original PR description
Since this week (maybe/probably linked to the new t-cache thing), the PDF generations for payslips adds 1 indeterministic query. Adapt the query counter instead of disabling the test while we figure what going on there.
When purchase is returned, the product may move to internal location first. If option `Update quantities on SO/PO` is active, it does decrease the qty. However, when the option is disabled, it increase the qty instead of doing nothing. Fix it by making a proper if-else block structure STEPS: - Create a PO, confirm it and receive the product - On the transfer, make a return to a location that is not a child of your warehouse (PhysicalLocations/W/...), for instance, choose the location
Original PR description
When purchase is returned, the product may move to internal location first. If option `Update quantities on SO/PO` is active, it does decrease the qty. However, when the option is disabled, it…
When purchase is returned, the product may move to internal location first. If option `Update quantities on SO/PO` is active, it does decrease the qty. However, when the option is disabled, it increase the qty instead of doing nothing. Fix it by making a proper if-else block structure STEPS: - Create a PO, confirm it and receive the product - On the transfer, make a return to a location that is not a child of your warehouse (PhysicalLocations/W/...), for instance, choose the location Physical Locations/Subcontracting Location - Untick the "Update quantities on SO/PO" (visible in debug), and validate the return transfer - Check your initial PO BEFORE: the received quantities have been updated, even if we asked not to do it AFTER: the received quantities is not changed opw-2858390 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#92505
Foreign companies that trade with non-enterprises in the EU may have a VATIN starting with "EU" instead of a country code. Currently, the user is facing a traceback in this situation since stdnum doesn't have any format method for vat number starting with 'EU'. ticket: 2877716 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93463
Original PR description
Foreign companies that trade with non-enterprises in the EU may have a VATIN starting with "EU" instead of a country code. Currently, the user is facing a traceback in this situation since stdnum doesn't have any format method for vat number starting with 'EU'. ticket: 2877716 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93463
The Customer Invoices and Vendor Bills bar graphs in the accounting dashboard skip empty weeks so the following weeks will be displayed sooner Steps to reproduce: 1. Install Accounting 2. Go to the accounting dashboard 3. The bar graph of Customer Invoices is not correct: it ends with empty weeks but they should be in between the data Solution: Use a fallback date in the sql query so that whenever there are no moves in a certain week, we can know which week it was in order to sort
Original PR description
The Customer Invoices and Vendor Bills bar graphs in the accounting dashboard skip empty weeks so the following weeks will be displayed sooner Steps to reproduce: 1. Install Accounting 2. Go to the accounting dashboard 3. The bar graph of Customer Invoices is not correct: it ends with empty weeks but they should be in between the data Solution: Use a fallback date in the sql query so that whenever there are no moves in a certain week, we can know which week it was in order to sort the results by date Problem: The SQL query didn't return any date for empty weeks so sorting the result by date would leave some weeks out of the bar graph opw-2844159 Forward-Port-Of: odoo/odoo#91441
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93208
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#93208
Issue: attributes could be generated by directives and not be used (for example on <t>). These attributes could end up unwittingly on the next node. Forward-Port-Of: odoo/odoo#93139 Forward-Port-Of: odoo/odoo#86801
Original PR description
Issue: attributes could be generated by directives and not be used (for example on <t>). These attributes could end up unwittingly on the next node. Forward-Port-Of: odoo/odoo#93139 Forward-Port-Of: odoo/odoo#86801
In some cases, an unexpected line "Undefined" is displayed on the graph of the Forecasted Report To reproduce the issue: 1. Create a storable product P 2. Process a receipt R01 with 1 x P 3. Process a delivery D01 with 1 x P 4. Create and confirm a planned receipt R02: - Scheduled date: In 7 days - Operations: 1 x P 5. On the form of P, open the On Hand page 6. Back to the form of P, open Forecasted page Error: An unexpected line "Undefined" is displayed on the graph and i
Original PR description
In some cases, an unexpected line "Undefined" is displayed on the graph of the Forecasted Report To reproduce the issue: 1. Create a storable product P 2. Process a receipt R01 with 1 x P 3. Process…
In some cases, an unexpected line "Undefined" is displayed on the graph
of the Forecasted Report
To reproduce the issue:
1. Create a storable product P
2. Process a receipt R01 with 1 x P
3. Process a delivery D01 with 1 x P
4. Create and confirm a planned receipt R02:
- Scheduled date: In 7 days
- Operations: 1 x P
5. On the form of P, open the On Hand page
6. Back to the form of P, open Forecasted page
Error: An unexpected line "Undefined" is displayed on the graph and is
always equal to zero
Suppose the user does the same as above without the step 5: there won't
be any unexpected line on the graph. Here are the explanations: after
step 3, a quant for P exists and its quantity is zero. So, suppose the
user doesn't open the "On Hand page" and directly opens the Forecasted
Report. Considering its definition:
https://github.com/odoo/odoo/blob/a9dc406b52a3702f6901f686503e8d841f81724e/addons/stock/report/report_stock_quantity.py#L41
Four things happen (we only consider the state `forecast`):
- The SM of R01 is propagated from `today minus 3 months` to `yesterday`
- Same for SM of D01
- The quant is propagated from `today minus 3 months` to `today plus 3
months`
- The SM of R02 is propagated from `in 7 days` to `today plus 3 months`
-> Thanks to the quant, there are some data between `yesterday` and `in
7 days`
Let's now consider the step 5. Opening the page leads to:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L621-L630
where, in `_quant_tasks`, we unlink the zero quants:
https://github.com/odoo/odoo/blob/b22a23435a0cc42b7084ded21dbd4ef3a4a2113e/addons/stock/models/stock_quant.py#L562-L565
Therefore, in the `report.stock.quantity`, we are creating a hole
between `yesterday` and `in 7 days`. When performing the RPC
`read_group` to get the graph data, a key-context is defined
(`fill_temporal`). Thanks to this, the hole is filled by the server but
the generated data do not mean anything:
https://github.com/odoo/odoo/blob/80ec56bd246869567c3bbc746be1ebce52970a63/odoo/models.py#L2005-L2007
i.e., the value of `empty_item` is:
```py
{'id': False, 'date_count': 0, 'product_qty': False, 'product_id':
False}
```
Later on, on JS-side, when processing the `read_group` result:
https://github.com/odoo/odoo/blob/ee84815f2b57ed7ba096d3390aa8c6509e3f7845/addons/web/static/src/js/views/graph/graph_model.js#L235-L241
We are grouping by date and by product. As explained above, some data
have an undefined `product_id` so, in such case, `labels` will contain a
date and an `undefined` value. This explains why we have two lines on
the graph:
- one for the product P
- one for the data generated by the server to fill the hole in the dates
range
OPW-2800818
Forward-Port-Of: odoo/odoo#92972
Forward-Port-Of: odoo/odoo#92176This dialog hadn't been correctly adapted since the move to owl2. As a consequence, it couldn't even open itself. 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#93382 Forward-Port-Of: odoo/odoo#93264
Original PR description
This dialog hadn't been correctly adapted since the move to owl2. As a consequence, it couldn't even open itself. 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#93382 Forward-Port-Of: odoo/odoo#93264
Remove leftover translations from some modules that no longer exists. Forward-Port-Of: odoo/odoo#93509 Forward-Port-Of: odoo/odoo#93343
Original PR description
Remove leftover translations from some modules that no longer exists. Forward-Port-Of: odoo/odoo#93509 Forward-Port-Of: odoo/odoo#93343
Create an empty database and start 2 http workers, go on the web app menu and install website (don't install website via -i). Once website is installed, you are redirected on `/website/configurator` but the route does not exist and it fails with a 500 internal server error. The problem is due to an invalid registry manipulation introduced in the saas-15.3's httpocalypse. When new modules are installed the registry must be reloaded in all workers. The function that determine if the regis
Original PR description
Create an empty database and start 2 http workers, go on the web app menu and install website (don't install website via -i). Once website is installed, you are redirected on `/website/configurator` but the route does not exist and it fails with a 500 internal server error. The problem is due to an invalid registry manipulation introduced in the saas-15.3's httpocalypse. When new modules are installed the registry must be reloaded in all workers. The function that determine if the registry must be reloaded and reloads it is `check_signaling`. When the current registry is up-to-date, it is returned as-is by `check_signaling`. When it is outdated, `check_signaling` creates and returns a new fresh registry; it does not nor discard nor change in-place the previous (outdated) registry, it is up to the callee to discard the previous registry itself. Forward-Port-Of: odoo/odoo#93482
Before this commit, when the project is created from SO, the quantity of SOL is set in allocated hours. But In the 'invoicing' tab an employee is added with a new SOL Then the 'allocated hours' changed to zero. So this commit fixes this issue by updating the compute method so on an update of SOL in invoicing tab or pricing line of the employee, the allocated hours should not be updated to 0. task-2788878 Forward-Port-Of: odoo/odoo#92407
Original PR description
Before this commit, when the project is created from SO, the quantity of SOL is set in allocated hours. But In the 'invoicing' tab an employee is added with a new SOL Then the 'allocated hours' changed to zero. So this commit fixes this issue by updating the compute method so on an update of SOL in invoicing tab or pricing line of the employee, the allocated hours should not be updated to 0. task-2788878 Forward-Port-Of: odoo/odoo#92407
As we are trying to create custom move lines before unlinking the reserved ones, we can be unable to reserve the lot we need if already in another move line. 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#93413 Forward-Port-Of: odoo/odoo#93304
Original PR description
As we are trying to create custom move lines before unlinking the reserved ones, we can be unable to reserve the lot we need if already in another move line. 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#93413 Forward-Port-Of: odoo/odoo#93304
Current behavior: If you made a sales with a partner wich is part of a company. And then archive that partner and click on the sales smart button from the company the sales from that partner wouldn't appear in the list. The problem is the same for the invoices Steps to reproduce: - Install sales and contacts - Create a sale for a partner (e.g. Edwin Hansen from Gemini) - Archive that partner - Go in the company view, click on sales button - The sale from the archived partner do not a
Original PR description
Current behavior: If you made a sales with a partner wich is part of a company. And then archive that partner and click on the sales smart button from the company the sales from that partner wouldn't appear in the list. The problem is the same for the invoices Steps to reproduce: - Install sales and contacts - Create a sale for a partner (e.g. Edwin Hansen from Gemini) - Archive that partner - Go in the company view, click on sales button - The sale from the archived partner do not appear in the company sales list opw-2850115 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93483 Forward-Port-Of: odoo/odoo#92780
task-2882007 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93521 Forward-Port-Of: odoo/odoo#93477
Original PR description
task-2882007 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#93521 Forward-Port-Of: odoo/odoo#93477
Follow-up of https://github.com/odoo/odoo/pull/88950 Commit above introduced `MessageSeenIndicatorView`. Conceptually, `MessageSeenIndicatorView/messageSeenIndicator` is required. However, the current implementation make it possible to have a view without the related pure logic record. This commit simply guards the template to take this implementation detail into account, as to not make it crash. Note that future changes in modelling will enforce `MessageSeenIndicatorView/message
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/88950 Commit above introduced `MessageSeenIndicatorView`. Conceptually, `MessageSeenIndicatorView/messageSeenIndicator` is required. However, the current implementation make it possible to have a view without the related pure logic record. This commit simply guards the template to take this implementation detail into account, as to not make it crash. Note that future changes in modelling will enforce `MessageSeenIndicatorView/messageSeenIndicator` being required, so that we won't need to guard it in template. But this is a fix in stable version, so it's safer to keep minimal code changes. Forward-Port-Of: odoo/odoo#93573
The embed code snippet (introduced at [1]) comes with a default "half-screen" min-height. Since [2] (patched with [3]), the min-height option is not shown anymore for snippets which are dropped in other snippets ("inline" snippets)... and [4] actually made the embed code snippet an "inline" one later on. The problem is that once dropped as an "inline" one, the embed code snippet had thus a "half-screen" min-height which was impossible to remove. This commit patches the snippet so that i
Original PR description
The embed code snippet (introduced at [1]) comes with a default "half-screen" min-height. Since [2] (patched with [3]), the min-height option is not shown anymore for snippets which are dropped in…
The embed code snippet (introduced at [1]) comes with a default
"half-screen" min-height. Since [2] (patched with [3]), the min-height
option is not shown anymore for snippets which are dropped in other
snippets ("inline" snippets)... and [4] actually made the embed code
snippet an "inline" one later on. The problem is that once dropped as
an "inline" one, the embed code snippet had thus a "half-screen"
min-height which was impossible to remove.
This commit patches the snippet so that it does not use a default
"half-screen" min-height but default paddings which work both as
"main" and "inline" snippets. The user can still use the min-height
option by himself if he wants to.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
[2]: https://github.com/odoo/odoo/commit/58503a248e7ab6b66d61d00869cdae6719e5a068
[3]: https://github.com/odoo/odoo/commit/bebb45e6d5e8224f2d534d5644b9af45fea903b1
[4]: https://github.com/odoo/odoo/commit/6336d1ba35f36733958cab48c1d90b6e3c0505d2
opw-2870772
Forward-Port-Of: odoo/odoo#93396Before this commit, since the removal of the modelManager from the scope of some components, the call systray menu would never show up as messaging was never defined. Forward-Port-Of: odoo/odoo#93581
Original PR description
Before this commit, since the removal of the modelManager from the scope of some components, the call systray menu would never show up as messaging was never defined. Forward-Port-Of: odoo/odoo#93581
Before this commit, generate coupon and send mail there is an empty note and False template due to invalid template_id in default_get so it logged empty message in the chatter. So in this commit, added default right template reference as default template. task-2858277 Forward-Port-Of: odoo/odoo#92156
Original PR description
Before this commit, generate coupon and send mail there is an empty note and False template due to invalid template_id in default_get so it logged empty message in the chatter. So in this commit, added default right template reference as default template. task-2858277 Forward-Port-Of: odoo/odoo#92156
Prior to this commit: - When a user wants to plan a `project.task` that has more than one assignee set in the gantt view, he/she can't do it as the view is default grouped by user_ids and the selected records will take the value of the group_by where the magnifier was clicked. Feedbacks show that users would try to achieve that by using the magnifier in the unassigned group_by, which unfortunately unassign all users from the selected tasks. After this commit: - Planning exist
Original PR description
Prior to this commit: - When a user wants to plan a `project.task` that has more than one assignee set in the gantt view, he/she can't do it as the view is default grouped by user_ids and the selected records will take the value of the group_by where the magnifier was clicked. Feedbacks show that users would try to achieve that by using the magnifier in the unassigned group_by, which unfortunately unassign all users from the selected tasks. After this commit: - Planning existing slots with assigned user will be possible by using the magnifier on the unassigned row. task-2871825 Forward-Port-Of: odoo/enterprise#28055
Bug === `_onRefreshNow` have a parameter to force the refresh of the feed view. But, when we click on the "Refresh" button, the DOM event is given do this function, make it think that it should force the refresh. Task-2744125 Forward-Port-Of: odoo/enterprise#28346
Original PR description
Bug === `_onRefreshNow` have a parameter to force the refresh of the feed view. But, when we click on the "Refresh" button, the DOM event is given do this function, make it think that it should force the refresh. Task-2744125 Forward-Port-Of: odoo/enterprise#28346
Currently validated timesheet can be updated in timesheet grid view. In this commit, if the validated timesheet is updated, a new timesheet will be created. task-2853277 Forward-Port-Of: odoo/enterprise#28335 Forward-Port-Of: odoo/enterprise#27320
Original PR description
Currently validated timesheet can be updated in timesheet grid view. In this commit, if the validated timesheet is updated, a new timesheet will be created. task-2853277 Forward-Port-Of: odoo/enterprise#28335 Forward-Port-Of: odoo/enterprise#27320
Remove leftover translations from some modules that no longer exists. Forward-Port-Of: odoo/enterprise#28320 Forward-Port-Of: odoo/enterprise#28259
Original PR description
Remove leftover translations from some modules that no longer exists. Forward-Port-Of: odoo/enterprise#28320 Forward-Port-Of: odoo/enterprise#28259
Purpose - set default project in the wizard of map menu gantt view - fixed computation of 'task in conflict' filter in task analysis report task-2788878 Forward-Port-Of: odoo/enterprise#26079
Original PR description
Purpose - set default project in the wizard of map menu gantt view - fixed computation of 'task in conflict' filter in task analysis report task-2788878 Forward-Port-Of: odoo/enterprise#26079
Current behavior: If you archived a partner and try to look for the ticket using the smart button from the partner view, the ticket list would be empty Steps to reproduce: - Install helpdesk - Go in any partner view (e.g. Azure Interior) - Archive the partner - Click on the Tickets smart button - There are no tickets in the list opw-2859273 Forward-Port-Of: odoo/enterprise#27828
Original PR description
Current behavior: If you archived a partner and try to look for the ticket using the smart button from the partner view, the ticket list would be empty Steps to reproduce: - Install helpdesk - Go in any partner view (e.g. Azure Interior) - Archive the partner - Click on the Tickets smart button - There are no tickets in the list opw-2859273 Forward-Port-Of: odoo/enterprise#27828
When sharing a custom appointment type, if there are slots on multiple months, we display a badge next to the navigation arrows. This badge contains the number of slots in the next/previous months. Before the badge didn't take into account the availability of the slot. Now the number of slots match correctly with the number of slots dipslayed. task-2836723 Forward-Port-Of: odoo/enterprise#28311 Forward-Port-Of: odoo/enterprise#27020
Original PR description
When sharing a custom appointment type, if there are slots on multiple months, we display a badge next to the navigation arrows. This badge contains the number of slots in the next/previous months. Before the badge didn't take into account the availability of the slot. Now the number of slots match correctly with the number of slots dipslayed. task-2836723 Forward-Port-Of: odoo/enterprise#28311 Forward-Port-Of: odoo/enterprise#27020