Daily updates from Odoo
Friday, March 20, 2026
36 changes · master
New functionality added to Odoo
This update reflects changes in Belgian government regulations regarding the deductibility of certain business expenses. The update incorporates new fiscal rates and account codes (616580, 616541, 623610) to ensure accurate accounting and tax reporting in Belgium. This ensures compliance with current tax laws.
Original PR description
Belgian Government changed some rules regarding the fiscal deductibility of some expenses, so we need to update that data accordingly for accounts 616580, 616541, 623610 Task-5973880 Forward-Port-Of: odoo/enterprise#110075
This update allows users to create Documents records directly from employee files uploaded through standard form fields. Previously, this feature was blocked for attachments with a specific field setting. This change improves the process of managing employee-related documents within Odoo Enterprise.
Original PR description
TEMP
This update incorporates the 2033-E document, a key component of the French 'Liasse fiscale' reporting requirement. This addition ensures our Odoo Enterprise system is fully compliant with French tax regulations, facilitating accurate financial reporting for our French clients.
Original PR description
This commit will add the 2033-E document of the "Liasse fiscal" task-5417361
Enhancements to existing features
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing leave creation even when a payslip is validated. Specifically, it now permits leave creation under certain conditions related to continued pay percentages and disability benefits, improving flexibility for HR processes. This change ensures accurate leave tracking within the Odoo Enterprise system.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
This update streamlines the job promotion process by removing redundant buttons and adjusting user access rights. Specifically, the 'Post on Job Board' button has been removed as it's now accessible through another option, and the 'Promote' button's access has been restricted to 'officer' users, enhancing security and workflow efficiency.
Original PR description
This commit is part of a 9-part task aiming to improve the user experience of multiple apps related to hr_recruitment. This commit: - removes the radio button in the job promotion wizard - removes the "Post on Job Board" button, since that action already exists in the cog menu (albeit under a different name: "Publish on Job Board") - changes the access rights of the 'Promote' button on a Job Form from 'admin' users to 'officer' users task-5184168
This update introduces a new system for automatically analyzing Seculine return files after salary declarations. It centralizes all feedback responses, allowing for quicker identification and resolution of any errors reported by the Seculine platform. This improves payroll accuracy and reduces manual effort.
Original PR description
- With this commit, we introduce a new model to handle the Seculine return files that are sent back by the Seculine platform after salary declaration to analyze and see the errors if any. - Centralizes all necessary responses required by Seculine for salary declaration feedback. task-4737849
This update enhances the visual appearance of spreadsheet controls by adopting a custom component, improving the overall user experience. This change focuses on the spreadsheet edition within Odoo, aligning its design with other Odoo modules. It's an internal improvement to the user interface.
Original PR description
We implemented a custom `Select` component in o-spreadsheet to improve the look and feels over native `<select>` elements, but didn't change the `<select>` present only in Odoo. Task: [6043744](https://www.odoo.com/web#id=6043744&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update simplifies the user experience by replacing all 'Cancel' buttons with 'Discard' buttons across several Odoo modules. This change improves clarity and consistency for users, allowing them to easily revert actions without confusion. The change is a minor improvement to the user interface.
Original PR description
Use Discard rather than Cancel Task: [5353199](https://www.odoo.com/odoo/2328/tasks/5353199)
This update enhances the user experience by adding visual warnings when accounts linked within Odoo are marked as inactive. This helps users quickly identify and manage inactive accounts, preventing potential errors and streamlining financial processes. The change impacts several accounting modules.
Original PR description
This commit will add a related field for each many2One linked to an account so that we can have a decoration to warn the user that this account is inactive. task-542461
This update centralizes how external requests are mocked across various Odoo modules. This change improves control over access to external resources and simplifies default settings, leading to more reliable and consistent testing. It's a foundational step towards better security and maintainability.
Original PR description
Centralize all requests-related mocking in one place This is a first step in our effort to centralise requests/responses/session objects in order to have better control on what should and should not be accessible to internal and to server action developers, as well as improve defaults. Creating a facade for most requests/responses & session objects breaks a lot of tests, as each module mocks responses in their own way, and thus makes building minimal facades difficult. task-4930532 Related: https://github.com/odoo/odoo/pull/249057
This update redesigns the survey results reporting page by adapting key Odoo addons like documents_spreadsheet and hr_appraisal to align with the overall survey redesign. This ensures a more consistent and user-friendly experience for analyzing survey data.
Original PR description
*: documents_spreadsheet, hr_appraisal Adapt different addons to the results (statistics) page of surveys as a part of the main redesign. Community PR: https://github.com/odoo/odoo/pull/247409 task-3884703
Resolved issues and error corrections
This update fixes an issue where errors in PDF generation would halt the entire batch, preventing regeneration. Now, individual PDFs with errors can be regenerated, and the 'Generate PDFs' button works correctly when 'Select All' is used, streamlining the payroll report process.
Original PR description
**Current behavior before PR:** When the PDFs are processed, they are in batch of max(batch_size,30) by the scheduled actions, if one of the PDFs is in error, the whole batch will not be generated and it will be put in draft. Also, when you select lines that have a generated PDF, you do not have the option to regenerate them. **Desired behavior implemented in this PR:** When a PDF is in error, it should not affect the other ones of the batch. Also, you can now select lines with generated PDFs and have the option to regenerate them if needed. This PR also fixes the following UX issue associated with the generation and posting of the PDFs in the employee declaration list view: - The two buttons "Generate PDFs" and "Post PDFs" were working only on the selected records in the current page, even if the user clicked on "Select All" button. task-5909426
This update optimizes the database by removing unnecessary default values from company and partner records. Specifically, the automatic setting of branch codes and purchase date defaults has been removed for multi-company environments, reducing data storage and improving performance. This change ensures that each company's data is accurate and efficient.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129 Forward-Port-Of: odoo/enterprise#105917
This update resolves a problem where generating VAT reports (FAIA) for invoices in different currencies caused errors. The fix ensures the necessary currency information is included in the report template, allowing accurate VAT calculations for Luxembourg companies. This improves the reliability of financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update resolves a problem preventing users from successfully connecting their expense accounts via Stripe. The issue occurred when users attempted to connect through the expense settings, specifically by accepting the terms of service and clicking the 'Connect' button. This fix ensures seamless integration for expense reporting.
Original PR description
To reproduce: - Install hr_expense_stripe_demo - Open the expense Settings - Accept the TOS - Click on Connect (demo)
This update resolves an error that occurred when setting an accounting period for Dutch companies using the l10n_nl_reports module. The fix corrects a mistake in how tax tags were being retrieved, preventing a traceback and allowing users to successfully create accounting periods. This ensures accurate reporting for Dutch businesses.
Original PR description
Creating an accounting period for a Dutch company raises a traceback. Steps to reproduce the error: - Install ``l10n_nl_reports`` and ``accountant`` module with demo data - Switch to NL Company - Go to Accounting > In Tax Returns > Click Set Periods > Set Opening Date > Apply Traceback: ```py 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report' ``` https://github.com/odoo/enterprise/blob/f23c592a933d7e5e5745aea60d0dcc5738249580/l10n_nl_reports/models/account_return.py#L20 In commit [1], Here, ``_get_tax_tags_for_nl_sales_report()`` method is called instead of ``_get_ec_sales_tax_tags()``. which leads to the above traceback. [1]:https://github.com/odoo/enterprise/commit/0a0fa0dae918ec5198a019a3e5be71a919f0e7c6 sentry-7340518330 Forward-Port-Of: odoo/enterprise#110948
This update corrects a technical issue in the Account Avatax module, ensuring that company-specific settings are accurately identified. Previously, a key piece of information was missing, which has now been added to improve the module's functionality and data accuracy. This ensures proper tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update fixes an issue where multiple email addresses on a contact were being overwritten when creating a helpdesk ticket. The change ensures that all email addresses associated with a contact are correctly captured, improving the reliability of ticket creation. This was caused by a technical limitation in how email addresses were handled, and the fix simplifies the process.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
This update resolves an issue preventing new employee creation when generating BVG-LLP reports. The fix addresses a technical problem with how Odoo compares report data, ensuring accurate employee record creation. This improves the reliability of payroll processing for Swiss companies.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335A recent update to the document layout, including VAT information, caused a test to fail. This fix addresses a problem where the test's editor selection wasn't correctly updated after adding the VAT block, preventing a key feature from working. The update ensures the test now passes, guaranteeing correct VAT display functionality.
Original PR description
Issue The test `test_edit_header_only_company` was failing after updating the document layout to include the VAT block in the company address section. Cause Adding the VAT line modified the DOM structure of the header layout. The tour step inserting the placeholder span no longer correctly set the editor selection, preventing the powerbox from opening and causing the test to fail. Solution Update the tour to explicitly reset the editor selection after inserting the span so that the powerbox can open correctly. opw-5373374 Related Community PR : https://github.com/odoo/odoo/pull/249225 Forward-Port-Of: odoo/enterprise#109924
This update ensures that follow-up emails for invoices now send the actual invoice PDF, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDFs, ensuring accurate and consistent invoice reminders are sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#111085 Forward-Port-Of: odoo/enterprise#98820
This update resolves a technical problem within Odoo's web studio that prevented users from correctly editing views, specifically when using inherited views. The fix ensures that the studio accurately recognizes and incorporates inherited views during the view creation process, preventing errors and crashes. This improves the stability and usability of the web studio.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#111245 Forward-Port-Of: odoo/enterprise#110835
This update fixes an issue with the numbering of lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was corrected. This ensures the report accurately reflects financial data for Vietnamese businesses using Odoo Enterprise.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111335 Forward-Port-Of: odoo/enterprise#111234
This update corrects a visual issue in the partner ledger report where overdue invoices and negative amounts weren't consistently displayed with the correct color (red and blue, respectively). The fix ensures that key financial information is clearly highlighted, improving report readability and accuracy for users reviewing their accounts. This improves the user experience when analyzing overdue invoices.
Original PR description
commit introducing the issue: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 Steps to reproduce: - open the partner ledger with some one overdue invoice -> The expected result should be to see the due date in red. -> Negative amounts in the partner ledger should be displayed in blue as well. Forward-Port-Of: odoo/enterprise#111295
This update corrects a problem where text fields in Odoo Sign's PDF forms were incorrectly displayed as checkmarks. The issue stemmed from an error in how the system interpreted PDF tags, specifically when standard text fields had appearance settings. This change ensures that text field values are correctly rendered in signed documents.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260 Forward-Port-Of: odoo/enterprise#110865 Forward-Port-Of: odoo/enterprise#110292
This update resolves an issue where Odoo would display an error message if Sendcloud didn't respond with shipping price information. The fix prevents a program crash by gracefully handling the situation where Sendcloud doesn't provide a response, ensuring a smoother user experience.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#111057 Forward-Port-Of: odoo/enterprise#109252
This update resolves an issue where the attendance Gantt chart incorrectly displayed employees without contracts, leading to inaccurate reporting. The change ensures these employees are not shown in the Gantt view, aligning with the system's requirement that only employed staff can record attendance.
Original PR description
In a recently created database, the attendace gantt chart hides all hours of the day, as an employee with no contract is considered unavailable at all times. This commit will make employees with no contract act as if they were in a flexible calendar (only for the gantt view of course). task-5222648
A technical error preventing a test process (runbot) from correctly evaluating overtime rules was resolved. The update corrected the tour's triggers to align with the current system, ensuring accurate overtime calculations and preventing disruptions to payroll processing.
Original PR description
The tour for the overtime ruleset flow was failing in the runbot because some of the triggers do not exist in the view. Updated the tour to use the correct triggers for each action. Task: 6053589
This update ensures that Sales Orders generated from Field Service timesheets only assign a salesperson to the order when the technician has Sales or Invoicing access. Previously, technicians without these permissions were incorrectly assigned as salespeople, leading to unwanted invoice notifications and follower assignments. This change improves data accuracy and reduces unnecessary communication.
Original PR description
Before this commit: - - With the Field Service and Planning integration, validating a planning shift linked to a Field Service project could generate a Sales Order from timesheets and materials. - The user linked to the resource was always assigned as salesperson on the generated Sales Order. - When that user had no Sales or Invoicing access, they were still set as salesperson, causing them to be added as followers on invoices and receive billing-related notifications. After this commit: - - The salesperson is assigned on the generated Sales Order only when the assigned user has Sales or Invoicing access. - If the user lacks these access rights, the salesperson field is left empty, preventing technicians from being added as invoice followers or receiving billing-related notifications. task-5023095
This update resolves issues with timesheet reminder emails displaying incorrect week dates and failing to open the correct grid view. The fix ensures that reminder emails accurately reflect the correct week and that clicking the email directs users to the appropriate timesheet grid.
Original PR description
Issues: - Reminder emails were showing the wrong week dates. - Opening a timesheet from the reminder email did not go to the correct grid view(scale). All the above issues are fixed in this commit. task-3624610
Features or functions removed from Odoo
This update streamlines the return process by removing a complex wizard and now automatically opens a draft picking form for returns. Users must now confirm the return picking to enable exchanges, improving efficiency and clarity. This change impacts the stock and helpdesk modules.
Original PR description
This commit removes the return wizard `stock.return.picking` and now returning a picking opens a picking form in draft state so the user can assign the quantities to return. Also, in order to make an exchange you need to confirm or validate the return picking first to be able to make an exchange. There is still a wizard used in helpdesk modules to accommodate choosing a picking first on the ticket to make the return. Related community PR: https://github.com/odoo/odoo/pull/241646 Related upgrade PR: https://github.com/odoo/upgrade/pull/9168 Task-5347991
This update removes user activities from the calendar view within the Point of Sale (POS) system. Previously, user activities were displayed, which was causing performance issues and unnecessary complexity. This change simplifies the POS experience and improves system efficiency.
Original PR description
Following odoo/odoo#244236 user activities can now be displayed in the user calendar. Prevent loading and displaying the user activities in point of sale. Task-5428944
Code cleanup and technical improvements
This update clarifies the names of key fields related to reinvoicing policies, enhancing clarity and consistency. Additionally, the model and view files for the timesheet functionality have been renamed to align with standard Odoo naming conventions, improving code organization and developer readability. This change supports ongoing improvements to reporting.
Original PR description
This PR renames several fields to better reflect their purpose and follow naming guidelines. Fields: * `expense_policy` → `reinvoice_policy` * `visible_expense_policy` → `visible_reinvoice_policy` Files: * `models/hr_timesheet.py` → `models/account_analytic_line.py` * `views/hr_timesheet_views.xml` → `views/account_analytic_line_views.xml` `expense_policy` and `visible_expense_policy` are renamed because these fields are no longer specific to expenses and now represent the generic reinvoicing behavior. `hr_timesheet` model and view files are renamed to `account_analytic_line` since We generally avoid functional naming for model or view files, and having the code for the `account.analytic.line` model inside a file named `hr_timesheet` does not add much clarity to devs. follow up of task-5490517 See Also: - https://github.com/odoo/odoo/pull/252144 - https://github.com/odoo/upgrade/pull/9609
This update streamlines access control for spreadsheet cells within Odoo Enterprise. The changes consolidate existing permission rules, eliminating redundant checks and improving the overall efficiency of the system. This ensures consistent and reliable access to spreadsheet data.
Original PR description
Use access rules defined and don't create additional permission checks.
This pull request integrates the 'l10n_be_intervat' module into the 'l1n_be_reports' module. This update enhances the reporting capabilities within Odoo Enterprise for Belgian Intervat tax returns, streamlining the process for businesses to accurately track and report VAT obligations.
Original PR description
This PR merges 'l10n_be_intervat' module into 'l10n_be_reports'. upgrade PR: https://github.com/odoo/upgrade/pull/9073 task-5090001
This update prepares Odoo for OWL3 by automatically adding `.this` to template variables that reference component data. This change is necessary because OWL3 requires a specific syntax for accessing component variables within templates, ensuring compatibility with the new OWL3 environment. The changes impact several Odoo modules, primarily within the web_studio environment.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Community PR: https://github.com/odoo/odoo/pull/254637 Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables