Odoo Changelog — 2024-09-16

Monday, September 16, 2024

3 changes · saas-17.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] project: makes sure the view project is shown in email for user

Coresaas-17.2project

Project notification emails now keep the View Project button visible for internal users. The button is only hidden from customer portal recipients when the project is private, helping staff access project details directly from email while preserving intended customer visibility rules.

Original PR description

Before this commit, due to 715d6be, the `View Project` button in the email sent even if the receiver is an internal user, which is not really expected.

This commit makes sure the button is only hidden for the customer portal when the project is private.

X-Original-Commit: 715d6be

Forward-port of #180257

#email#project access#portal

[FIX] web: lazy controller for server actions

PR #179916

Coresaas-17.2web

Opening a CRM lead directly from a link now keeps the breadcrumb trail accurate, including the option to return to the broader list of records. This helps users navigate consistently when actions are launched indirectly in Odoo.

Original PR description

Before this commit when opening a CRM Lead from the URL, the breadcrumb
doesn't show the multi-record controller. This occurs, because the CRM
action is a server action that returns a window action, and the lazy
controller is never created.

Now, the lazy controller is correctly created also for the server
actions.

#navigation#breadcrumbs#CRM#server actions

[FIX] mrp,stock: include soon-to-start MOs in quantity forecast

PR #173842

Coresaas-17.2mrpstockMedium

Manufacturing orders that are already planned to start soon are now counted correctly in stock forecasts. This prevents reordering rules from adding too much quantity to existing manufacturing orders when sales orders are repeated.

Original PR description

Steps
---
1. install `mrp,sales_management`
2. Create a manufacture-routed product P with a manufacturing BOM:
   * Operation OP1, duration = 1 hr
   * some component
3. Create a reording rule for P with a manufacturing route:
   * min qty = 0
   * max qty = 0
4. Create an SO for 15 > Confirm
   * (A MO for 15 P should have been generated)
6. duplicate the SO > Confirm
   * (The **same** MO is now for 30 P)
7. duplicate the SO > Confirm
=> The MO is for 75 P instead of 45

Cause
---
When the reordering rule is triggered, we attempt create a procurement
for the opposite of the forecast quantity of product P and add it to the
MO.
But the reordering rule's visibility days is 0 (default), so once the
MO's expected finished date (now + qty * 1 hr) is tomorrow or more [1]
we do not consider the quantity coming from the MO for the stock
forecast.
Therefore the procurement is for the sum of all the previous orders for
P (ie 15 * 3 = 45), so the MO's quantity will be 30 + 45 = 75 instead of
30 + 15 = 45

[1] (cf commit 1) There is another bug this PR fixes where the date finished
for MOs is not computed at creation time but only at write time,
therefore, we need to be at least on the 3rd SO for the bug to appear.
(The 2nd one writes to the MO)

Fix
---
When computing the quantity in progress for product P, take into account
MOs such that `date_start <= end_of_orderpoint_forecast < date_finished`

\+ [1] Do compute the finished date at creation when it isn't specified in
the vals and do not specify it in the above flow.

opw-4034475

#manufacturing#forecast#reordering#sales orders

Before this commit, due to 715d6be, the `View Project` button in the email sent even if the receiver is an internal user, which is not really expected. This commit makes sure the button is only hidden for the customer portal when the project is private. X-Original-Commit: 715d6be Forward-port of #180257

Before this commit when opening a CRM Lead from the URL, the breadcrumb doesn't show the multi-record controller. This occurs, because the CRM action is a server action that returns a window action, and the lazy controller is never created. Now, the lazy controller is correctly created also for the server actions.

Steps --- 1. install `mrp,sales_management` 2. Create a manufacture-routed product P with a manufacturing BOM: * Operation OP1, duration = 1 hr * some component 3. Create a reording rule for P with a manufacturing route: * min qty = 0 * max qty = 0 4. Create an SO for 15 > Confirm * (A MO for 15 P should have been generated) 6. duplicate the SO > Confirm * (The **same** MO is now for 30 P) 7. duplicate the SO > Confirm => The MO is for 75 P instead of 45 Cause --- When the reordering rule is triggered, we attempt create a procurement for the opposite of the forecast quantity of product P and add it to the MO. But the reordering rule's visibility days is 0 (default), so once the MO's expected finished date (now + qty * 1 hr) is tomorrow or more [1] we do not consider the quantity coming from the MO for the stock forecast. Therefore the procurement is for the sum of all the previous orders for P (ie 15 * 3 = 45), so the MO's quantity will be 30 + 45 = 75 instead of 30 + 15 = 45 [1] (cf commit 1) There is another bug this PR fixes where the date finished for MOs is not computed at creation time but only at write time, therefore, we need to be at least on the 3rd SO for the bug to appear. (The 2nd one writes to the MO) Fix --- When computing the quantity in progress for product P, take into account MOs such that `date_start <= end_of_orderpoint_forecast < date_finished` \+ [1] Do compute the finished date at creation when it isn't specified in the vals and do not specify it in the above flow. opw-4034475