Odoo Changelog — 2024-10-15

Tuesday, October 15, 2024

79 changes · master

Improvements(9)

Enhancements to existing features

Using python class name corresponding to odoo models

Coremasteraccount

This change standardizes how Odoo's internal model classes are named so they match the business objects they represent. It is mainly an internal improvement that makes the codebase more consistent and prepares it for future developer productivity improvements such as better typing support.

Original PR description

There are 3 commits in this pr. The first one corresponds to the feature and the addition of the file migration script, the second one is the result of the script and the third one is the adaptations to be made after the script.

===================================

[IMP] *: adapt model class names to correspond to model names

The purpose is to remove the attribute `_name` from model classes, and derive the model name from its class name.  This will lead to more consistent class naming, and will ease the process of making Odoo code more Pythonic.

The script updates every class name to match the new convention. The name of a model (**dotcase**) is determined by the name of its class (**camelcase**) as follows. Each capital letter is lowercased and is preceded by a period, unless it is the first one or is itself preceded by an underscore. The use of underscores in model names is now discouraged.
```
res.users <=> ResUsers
ir.ui.view <=> IrUiView
ir.config_parameter <=> IrConfig_parameter
e.g <=> EG
```

The `_name` attribute on model classes are removed, except in the case where the model name cannot be derived from the class name. The `_inherit` attribute is no longer used as a fallback for the model name, and only the `list` variant is now accepted.

For instance,
```py
class FieldConverter(models.AbstractModel):
    _name = 'ir.qweb.field'

class IntegerConverter(models.AbstractModel):
    _name = 'ir.qweb.field.integer'
    _inherit = 'ir.qweb.field'

class Integer(models.AbstractModel):
    _name = 'ir.qweb.field.integer'
    _inherit = 'ir.qweb.field.integer'
```
becomes:
```py
class IrQwebField(models.AbstractModel):

class IrQwebFieldInteger(models.AbstractModel):
    _inherit = ['ir.qweb.field']

class IrQwebFieldInteger(models.AbstractModel):
    _inherit = ['ir.qweb.field.integer']
```

===================================

Renaming is a first step to set up typing. All model classes will soon be available at the root of the addons. We will not make any changes to the directory structure.

Soon the syntax for extending a model will become:
```py
from odoo import fields
from odoo.addons import base

class IrQwebFieldInteger(base.IrQwebFieldInteger):
```

#model naming#code consistency#developer productivity

[IMP] services : module description cleaning

PR #142220

Coremasterhr_timesheethr_timesheet_attendanceprojectproject_accountproject_hr_expenseproject_mail_pluginproject_mrpproject_purchaseproject_sale_expenseproject_smsproject_timesheet_holidayssale_projectsale_project_stocksale_servicesale_timesheetsale_timesheet_marginspreadsheet_dashboard_hr_timesheetspreadsheet_dashboard_sale_timesheetwebsite_project

[IMP] core: move json_default from tools/date_utils to tools/json

PR #121019

Coremasterbustest_performancebase

This change moves a shared JSON conversion helper into a more appropriate core location. It makes future maintenance clearer for developers without changing business workflows or user-facing behavior.

Original PR description

Since odoo/odoo@1ecb0641efead9966faafb853c1e03138a49f111 `json_default` is no longer entirely related to dates anymore.

Besides, if you want to a new object to implement the JSON serialization for, which has nothing to do with dates, it's weird to have to add it in tools/date_utils.

I therefore suggest to move this in tools/json rather than tools/date_utils

#core#json#maintenance

[IMP] mass_mailing: improve contact form view

PR #179080

Coremastermass_mailing

The mailing contact form is easier to use with clearer guidance on the Title field. Users can also now see all subscriptions directly from the Subscriptions page, making contact subscription details more accessible.

Original PR description

### Purpose:
Improve the form view

### After this PR:
- Added placeholder on Title field
- List of all subscriptions will be displayed inside 'Subscriptions' page

Task-4138413

#contacts#subscriptions#form view

[IMP] mail: remove the delete button

PR #183084

Coremastermail

The email template form no longer shows a separate custom delete button, making the interface cleaner and less confusing. The delete confirmation dialog also receives a small usability refinement to make the action feel more consistent.

Original PR description

Remove the custom delete button from email templates' form view.
And a tiny UI/UX change in delete confirmation dialog.

Task-4231737

#email templates#user experience#cleanup

[IMP] planning_holidays: convert tests to hoot

PR #69487

Enterprisemasterplanningplanning_holidays

The planning time-off module's automated tests were moved to a newer testing framework. This helps keep future maintenance more reliable without changing day-to-day user behavior.

Original PR description

Purpose of this PR:

This PR aims to convert QUnit tests which rely on mail/test_utils to hoot.

Part of task: 3818666

#testing#maintenance#planning

[IMP] account_reports: set country before availability condition

PR #71334

Enterprisemasteraccount_reports

The accounting reports tests now set the country before applying country-based availability rules. This keeps the test process aligned with the latest validation requirements and helps prevent avoidable failures during development.

Original PR description

In the community PR, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set.

Therefore, in tests where the availability condition is set to country, the country should be set before.

task-4160643

#accounting#reports#tests#validation

[IMP] services : module description cleaning

PR #50755

Enterprisemastercrm_helpdeskdata_merge_helpdeskdata_merge_projectdocuments_fsmdocuments_projectdocuments_project_saledocuments_project_signhelpdesk_accounthelpdesk_fsmhelpdesk_fsm_reporthelpdesk_fsm_salehelpdesk_holidayshelpdesk_mail_pluginhelpdesk_repairhelpdesk_salehelpdesk_sale_loyaltyhelpdesk_sale_timesheethelpdesk_smshelpdesk_stock

Using python class name corresponding to odoo models

PR #69762

Enterprisemasteraccount_3way_matchaccount_accountant

This update standardizes internal class names so they better match the related Odoo accounting models. It helps developers maintain the accounting code more easily without changing day-to-day user workflows.

Original PR description

see: https://github.com/odoo/odoo/pull/178200

#accounting#maintenance#code-consistency

Bug Fixes(2)

Resolved issues and error corrections

[FIX] Monetary widget throws error without aggregation in list view

PR #132272

Coremasterweb

List views no longer show a misleading currency aggregation error when users display monetary values without totaling the column. This prevents unnecessary confusion while keeping the warning available when aggregation is actually used.

Original PR description

### Impacted versions:
16.0

### Steps to reproduce:
1. Create list view
2. Use the monetary widget for a column with various currencies.
3. Do not aggregate the column.

### Bug Fix Description:

**Bug Description:**

Previously, in the `web` module's `list_render`, an issue occurred where an error message was incorrectly being displayed below a table column with multiple currencies, even when the column wasn't being aggregated. This behavior was misleading and could confuse users, as the error message appeared even when it wasn't relevant.

**Root Cause:**

The error message was triggered regardless of whether the column was being aggregated by the user. This resulted in incorrect behavior and an unnecessary error display.

**Resolution:**

In this PR, the issue has been addressed by modifying the error display logic. The error message will no longer appear if the user does not choose to aggregate the column. This enhancement ensures that the error message is contextually relevant and only displayed when aggregation is being attempted on the column.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Other(68)

Miscellaneous changes

[FW][IMP] l10n_ar: We have adapted the demo data module to enhance data privacy.

PR #183663

Coremasterl10n_ar

Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182780 Forward-Port-Of:

Original PR description

Task: 41734
Odoo-task: 1239

Description of the issue/feature this PR addresses:
This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number.

Current behavior before PR:

Desired behavior after PR is merged:
Edit the demo data with fake information except for the VAT number.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#182780
Forward-Port-Of: odoo/odoo#175390

There are 3 commits in this pr. The first one corresponds to the feature and the addition of the file migration script, the second one is the result of the script and the third one is the adaptations to be made after the script. =================================== [IMP] *: adapt model class names to correspond to model names The purpose is to remove the attribute `_name` from model classes, and derive the model name from its class name. This will lead to more consistent class naming, and will ease the process of making Odoo code more Pythonic. The script updates every class name to match the new convention. The name of a model (**dotcase**) is determined by the name of its class (**camelcase**) as follows. Each capital letter is lowercased and is preceded by a period, unless it is the first one or is itself preceded by an underscore. The use of underscores in model names is now discouraged. ``` res.users <=> ResUsers ir.ui.view <=> IrUiView ir.config_parameter <=> IrConfig_parameter e.g <=> EG ``` The `_name` attribute on model classes are removed, except in the case where the model name cannot be derived from the class name. The `_inherit` attribute is no longer used as a fallback for the model name, and only the `list` variant is now accepted. For instance, ```py class FieldConverter(models.AbstractModel): _name = 'ir.qweb.field' class IntegerConverter(models.AbstractModel): _name = 'ir.qweb.field.integer' _inherit = 'ir.qweb.field' class Integer(models.AbstractModel): _name = 'ir.qweb.field.integer' _inherit = 'ir.qweb.field.integer' ``` becomes: ```py class IrQwebField(models.AbstractModel): class IrQwebFieldInteger(models.AbstractModel): _inherit = ['ir.qweb.field'] class IrQwebFieldInteger(models.AbstractModel): _inherit = ['ir.qweb.field.integer'] ``` =================================== Renaming is a first step to set up typing. All model classes will soon be available at the root of the addons. We will not make any changes to the directory structure. Soon the syntax for extending a model will become: ```py from odoo import fields from odoo.addons import base class IrQwebFieldInteger(base.IrQwebFieldInteger): ```

Since odoo/odoo@1ecb0641efead9966faafb853c1e03138a49f111 `json_default` is no longer entirely related to dates anymore. Besides, if you want to a new object to implement the JSON serialization for, which has nothing to do with dates, it's weird to have to add it in tools/date_utils. I therefore suggest to move this in tools/json rather than tools/date_utils

In the community PR, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643

### Impacted versions: 16.0 ### Steps to reproduce: 1. Create list view 2. Use the monetary widget for a column with various currencies. 3. Do not aggregate the column. ### Bug Fix Description: **Bug Description:** Previously, in the `web` module's `list_render`, an issue occurred where an error message was incorrectly being displayed below a table column with multiple currencies, even when the column wasn't being aggregated. This behavior was misleading and could confuse users, as the error message appeared even when it wasn't relevant. **Root Cause:** The error message was triggered regardless of whether the column was being aggregated by the user. This resulted in incorrect behavior and an unnecessary error display. **Resolution:** In this PR, the issue has been addressed by modifying the error display logic. The error message will no longer appear if the user does not choose to aggregate the column. This enhancement ensures that the error message is contextually relevant and only displayed when aggregation is being attempted on the column. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values. **Cause:** The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices. **Fix:** The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants. Affected Version: 17.0~master opw-4061530 Forward-Port-Of: odoo/odoo#183281

Description of the issue this commit addresses: Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals. --- Steps to reproduce: 1. Install account 2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date. 3. Go to the dashboard, click the <[X] To Pay> button. 4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button. This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves. --- Desired behavior after this commit is merged: The right amount of To Pay and Late moves is shown at all times. --- Enterprise PR: https://github.com/odoo/enterprise/pull/70725 No task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181535

Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale from `hashchange` to `popevent` with a check on the event's `state?.newURL` attribute. Issue is that this will always be `undefined`, as there's no logic in place to push or replace states[^1] when viewing products. Solution -------- Revert the change, and have the listener trigger on `hashchange` events[^2] again. > [!Note] > In the future we could consider moving away from using the URL hash property[^3] for storing product attribute ids to a more conventional practice, as was intended by the commit that made this change. opw-4150284 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/PopStateEvent/state [^2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/hashchange_event [^3]: https://developer.mozilla.org/en-US/docs/Web/API/URL/hash Forward-Port-Of: odoo/odoo#183373 Forward-Port-Of: odoo/odoo#183210

## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183667 Forward-Port-Of: odoo/odoo#183358

Since [1], when using a website boxed layout, the Bootstrap $body-bg variable was used as the color of the *box* instead of the body itself. Indeed, it made sense as default Bootstrap components started to use that $body-bg value themselves, supposing those components would be placed in the body by default, and not a colored main box. The color of the body itself was then forced to the user-chosen Odoo color, by setting the --body-bg CSS variable Bootstrap sets up and which at the time, was only used for that. However, since [2], the new Bootstrap version started to use that CSS variable instead of the $body-bg SCSS variable to style components. Therefore, in boxed layout, this was broken: the components used the "color behind the box" instead of the "color of the box". Commit [3] solved a specific consequence of this issue: the tables, in boxed layouts, would use the "color behind the box" (for instance, on the shop page) breaking the design. It fixed the issue by restoring the table transparent background color as wanted (not only in those boxed layouts). But other components that use var(--body-bg) would still be broken... (un)fortunately, it seems to not be the case as we force those variables ourselves to $body-bg instead of var(--body-bg) (which will be changed in master to follow Bootstrap conventions). [1]: https://github.com/odoo/odoo/commit/977868f5e0f50937499c89efacadf1d30ed19b5d [2]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935 [3]: https://github.com/odoo/odoo/commit/17592b131001647cc4c8028db8c1dacb05797c0b Related to opw-4203976 Forward-Port-Of: odoo/odoo#183132

Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. Another fix (from [2]) was added later to exceptionally authorize the editor's creation for "invisible" elements in translate mode, with a small adaptation on `_activateSnippet()` to prevent activating invisible snippets when their related sidebar buttons are clicked. This code unintentionally leads to keeping the old editors created for a text snippet when switching to another one in the DOM. To fix this behaviour, we still need to ensure existing editors are destroyed so we only create the ones we need in translate mode. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3 task-3975683 Forward-Port-Of: odoo/odoo#183245 Forward-Port-Of: odoo/odoo#168642

This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime module - Install 'Sales' application and 'l10n_mx_edi' module - In a company with mexican localization selected go to Sales > Quotations and create a new Order - Select a contact with the Addenda Autozone selected - Confirm it and create the corresponding invoice - Confirm the invoice and generate the CFDI 2. Traceback with invoice that have multiple sale order linked. In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order when we create a invoice for multiple sale orders Initialize sale_id with the first order retrieved to use it task-no Forward-Port-Of: odoo/enterprise#71939 Forward-Port-Of: odoo/enterprise#71875

Description of the issue this commit addresses: Since recently, the <[X] To Pay> and <[X] Late> buttons don't send the user to an account.move.line model view anymore but to an account.move model one but when that change was made, the computation of the number of items on the dashboard was not changed so it was still counting the amount of account.move. line there was in the account.move items that were shown in the view resulting in wrong totals. --- Steps to reproduce: 1. Install account 2. Create new Vendor Bill with a split payment term ("30% now, Balance 60 Days" for example) on today's date for Bill Date. 3. Go to the dashboard, click the <[X] To Pay> button. 4. the amount of moves in the view that is opened with the button is one above the value of "X" in the button. This is due to using a split payment term that creates two installment for a single vendor bill hence counting one more aml than there are moves. --- Desired behavior after this commit is merged: The right amount of To Pay and Late moves is shown at all times. --- Note on the fix: The fix for this issue is in the community PR of the bundle, the fix modifies a method which was overriden in enterprise and this PR addresses the override to match with the new version of the method. --- Community PR: https://github.com/odoo/odoo/pull/181535 No task Forward-Port-Of: odoo/enterprise#70725

Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create thread._message_auto_subscribe(create_values, followers_existing_policy='update') File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe res = self._message_auto_subscribe_followers(updated_values, def_ids) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers if salesperson and user_id == salesperson.id and user_id != self.env.user.id: ^^^^^^^^^^^^^^ File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__ raise ValueError("Expected singleton: %s" % record) ValueError: Expected singleton: res.users(56, 60) ``` Forward-Port-Of: odoo/enterprise#71478 Forward-Port-Of: odoo/enterprise#71188

**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create the backorder, the resulting backorder will have split the remaining raw moves in an unintuitive manner. **Expected behavior:** The backorder should have one move for the remaining component quantity. **Steps to reproduce:** 1. Create a production for 10 of some final product consuming 10 some component -> Confirm 2. Open the production in barcode, add 5 of the final product to its line and 5 of the component to its line -> exit the transfer view 3. Reopen the production and validate it -> create backorder 4. Open the backorder to see the odd split of the component product's moves **Cause of the issue:** When creating the backorder we normally expect each component product to be encapsulated by a single line- so the split that occurs when we leave the transfer initially without validating which creates 2 moves for the same product means we get 2 moves for the component for half of the remaining quantity for that component. **Fix:** Incomplete barcode lines for production transfers should get split into additional move lines as opposed to moves. opw-4148050 Forward-Port-Of: odoo/enterprise#71636 Forward-Port-Of: odoo/enterprise#69149

Improvements(9)

Using python class name corresponding to odoo models

[IMP] services : module description cleaning

[IMP] core: move json_default from tools/date_utils to tools/json

[IMP] mass_mailing: improve contact form view

[IMP] mail: remove the delete button

[IMP] planning_holidays: convert tests to hoot

[IMP] account_reports: set country before availability condition

[IMP] services : module description cleaning

Using python class name corresponding to odoo models

Bug Fixes(2)

[FIX] Monetary widget throws error without aggregation in list view

Other(68)

[FW][IMP] l10n_ar: We have adapted the demo data module to enhance data privacy.

Improvements(9)

Using python class name corresponding to odoo models

[IMP] services : module description cleaning

[IMP] core: move json_default from tools/date_utils to tools/json

[IMP] mass_mailing: improve contact form view

[IMP] mail: remove the delete button

[IMP] planning_holidays: convert tests to hoot

[IMP] account_reports: set country before availability condition

[IMP] services : module description cleaning

Using python class name corresponding to odoo models

Bug Fixes(2)

[FIX] Monetary widget throws error without aggregation in list view

Other(68)

[FW][IMP] l10n_ar: We have adapted the demo data module to enhance data privacy.

[FIX] account_reports: fix company order

[FW][FIX] product: hide price from catalog in case of mrp or repair orders

[FW][FIX] hw_drivers: disable extensions in chromium

[FW][FIX] website_sale: display base unit price for product variants

[FW][FIX] pos_self_order: kitchen order ticket in kiosk self order

[FW][FIX] website{_hr_recruitment}: don't log warning message in recruitment

[FW][FIX] stock: collection of 18.0 bugfixes for mrp

[FW][CLA] Kernet S.L. signs Odoo CCLA

[FW][FIX] event: don't block setup with demo cron

[FW][FIX] survey: overlap images on user side result page

[FW][FIX] mrp: ensure available product is reserved for backorder

[FW][FIX] sale_timesheet: filter task SO without commercial partner id

[FW][IMP] point_of_sale: show tracking field in the product form view in pos

[FW][FIX] account: wrong waiting and late count on dashboard

[FW][FIX] website_sale: update window after selecting variant in carousel

[FW][FIX] web: list: no layout issue when re-ordering records

[FW][IMP] delivery: display shipping pickup point name

[FW][FIX] sale: fix the title of the SO card in the portal

[FW][PERF] mail: speedup GC when deleting `ir.attachment`

[FW][FIX] web: remove red dot from search panel on small screen

[FW] PRHOOT 25

[FW][FIX] account: wrong comparison in bank account

[FW][FIX] web_editor: convert webp images to png in inline

[FW][FIX] point_of_sale: trigger reordering rules on pos closing

[FW][FIX] website: restore proper body-bg meaning with boxed layouts

[FW][FIX] purchase: Rename 'Purchase Order' field

[FW][FIX] analytic: remove view button to use the one from the list view

[FW][IMP] website: make cookie watcher container list custo-friendly

[FW][FIX] l10n_it_edi: naming key in dict

[FW][FIX] web: fix menus and user language mismatch

[FW][FIX] website_sale: ensure delivery page is displayed in checkout

[FW][MOV] l10n_iq: move from enterprise

[FW][FIX] pos_self_order: prevent multiple payment page renders

[FW][FIX] project_todo: take whole page height for the todo form view

[FW][FIX] survey: chart issues

[FW][FIX] l10n_*: try loading the coa using parent company first

[FW][FIX] hw_drivers: command line argument handling

[FW][FIX] Calendar: missing of AM/PM split when Arabic is set

[FW][FIX] web_editor, website: fix text options display in translation mode

[FW][FIX] core: avoid modifying shared fields

[FW][IMP] l10n_in: gst number based State Auto-population and Mismatch Warning

[FW][FIX] l10n_it_edi_ndd: Payment method, state is already paid

[FW][FIX] product,sale_pdf_quote_builder: prevent uploading non-supported files

[FW][FIX] l10n_de_pos_cert: fix pos receipt with fiskaly

[FW][FIX] l10n_mx_edi: negative line in DIOT report

[FW][FIX] l10n_be_hr_payroll: fix wrong end date holiday attest

[FW][FIX] project_enterprise: grey out weekends project gantt groupby

[FW][FIX] account_avatax: partner address check on expenses

[FW][FIX] l10n_mx_edi: Addenda autozone error for invoice with sale order

[FW][FIX] l10n_*: try loading the coa using parent company first

[FW][FIX] tes_website_sale_full,_*: ensure delivery page is displayed in …

[FW][FIX] sale_subscription: use assertAlmostEqual on amounts