Odoo Changelog — 2022-03-29

Tuesday, March 29, 2022

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_mx_edi: Check amount using 'is_zero'

Enterprisemasterl10n_mx_edi

This fixes Mexican electronic invoices so discounts that round to zero are no longer shown. It prevents tiny rounding amounts from appearing as a discount, making invoice documents clearer and more accurate for customers.

#mexico#invoicing#discounts#rounding

[FIX] project_timesheet_forecast_sale: test adaptation

PR #25664

Enterprisemasterproject_timesheet_forecast_sale

The timesheet forecasting sales tests were updated to reflect corrected employee company and timezone handling. This helps keep automated checks reliable after related platform changes, with no expected direct impact on daily users.

Original PR description

Due to the changes in the community PR, the resource of the employee
is now created directly with the right company (the one provided in create values,
or the environment company, as specified in the default field value).
This means that now, the resource.resource create receives the correct company
and correctly extrapolates the calendar and tz (if not provided).

Previously, when the company/user/calendar/tz were not provided, the resource
tz default used the context/user tz/'UTC'.

Which means that the employees created in the sale_timesheet test common
(including manager_company_B used in the current test) had conflicting
resource and resource calendar tzs, aka 'UTC' for the resource (last default value)
and 'Europe/Brussels' for the resource calendar tz, leading to the previous
result in the test values.

Now that the timezone are the same, the test must be adapted accordingly.

COM PR: https://github.com/odoo/odoo/pull/85601

#tests#timesheets#forecasting#timezone

[REF/FIX] web_enterprise: refactor and fix expiration panel

PR #25587

Enterprisemasterweb_enterpriseweb_studioMEDIUM

The expired subscription experience was adjusted so users can still interact with the subscription renewal panel even when the rest of the interface is blocked. Subscription-related logic was also reorganized into a clearer shared service, improving consistency between expired and soon-to-expire states.

Original PR description

Previously, when the user's subscription had expired, we would block the
UI. In 14.0 and under, the expiration panel was moved into the blockUI
overlay so that the user could still interact with the expiration panel.
With the wowl refactoring, the ui service doesn't expose an API to do
anything similar, as the desired semantics for such an API are unclear
(in particular: in the case of multiple calls to blockUI with different
content, which should we choose? Should we stack them? Should unrelated
code be allowed to unblock the ui?)

This commit fixes that by introducing a main component that will function
similarly to the blockUI overlay and that contains a different copy of
the expiration panel. Since both expiration panels should share most of
their state, the parts of the logic that are related to managing the
enterprise subscription have been extracted to the enterprise service
(which was renamed to enterprise_subscription service to better match
its purpose). With that, when the subscription is exprired, the home
menu will signal on the bus that the UI should be blocked by the
expiration panel, and when the subscription is almost expired, it will
render the expiration panel within itself as usual.

#subscription#expiration#user interface

Due to the changes in the community PR, the resource of the employee is now created directly with the right company (the one provided in create values, or the environment company, as specified in the default field value). This means that now, the resource.resource create receives the correct company and correctly extrapolates the calendar and tz (if not provided). Previously, when the company/user/calendar/tz were not provided, the resource tz default used the context/user tz/'UTC'. Which means that the employees created in the sale_timesheet test common (including manager_company_B used in the current test) had conflicting resource and resource calendar tzs, aka 'UTC' for the resource (last default value) and 'Europe/Brussels' for the resource calendar tz, leading to the previous result in the test values. Now that the timezone are the same, the test must be adapted accordingly. COM PR: https://github.com/odoo/odoo/pull/85601

Previously, when the user's subscription had expired, we would block the UI. In 14.0 and under, the expiration panel was moved into the blockUI overlay so that the user could still interact with the expiration panel. With the wowl refactoring, the ui service doesn't expose an API to do anything similar, as the desired semantics for such an API are unclear (in particular: in the case of multiple calls to blockUI with different content, which should we choose? Should we stack them? Should unrelated code be allowed to unblock the ui?) This commit fixes that by introducing a main component that will function similarly to the blockUI overlay and that contains a different copy of the expiration panel. Since both expiration panels should share most of their state, the parts of the logic that are related to managing the enterprise subscription have been extracted to the enterprise service (which was renamed to enterprise_subscription service to better match its purpose). With that, when the subscription is exprired, the home menu will signal on the bus that the UI should be blocked by the expiration panel, and when the subscription is almost expired, it will render the expiration panel within itself as usual.