Daily updates from Odoo
Thursday, April 2, 2026
61 changes · master
Enhancements to existing features
This commit restores a previous design style (M3.1) for various Odoo modules, focusing on consistent box styling across views. It reverts changes made for a previous update and adapts the templates as needed. Further work is needed to ensure icons are consistently visible.
Original PR description
In some view outside the groups we want the boxes anyway so we introduce the o_outlined class. This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * clipboard: more refactoring needed in some case icons are not visible * M3: some class are still present task-6054024 Co-authored-by: Adrien Dieudonné <adr@odoo.com> Co-authored-by: Romain Estievenart <res@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures each job position is linked to only one company, simplifying job management and reducing potential confusion. When a job position is created, the current company is automatically set. Additionally, demo data has been updated to consistently use 'My Company (San Francisco)' for empty company records.
Original PR description
Purpose A job position cannot be linked to multiple company. 1 JP = 1 company Specifications Remove the "Visible to all" possibility On Jon position At creation set the current company Adapt runbot data: All empty company must be My Company (San Fransisco) Task-6064945
This update optimizes the way the system checks user group memberships, speeding up the attendance process. By running these checks concurrently, the system responds faster and reduces potential delays. This change improves the overall user experience.
Original PR description
In AttendanceActionHelper, replaced two sequential user.hasGroup() calls with Promise.all() so both requests fire simultaneously, reducing the time window during which the component is vulnerable to destruction. **Task: 5972786** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores a previous design style (M3.1) for certain views, focusing on a more consistent look and feel across Odoo. It reverts changes made for a previous feature and adapts the template as needed. Further work is needed to ensure icons are consistently visible.
Original PR description
In some view outside the groups we want the boxes anyway so we introduce the o_outlined class. This commit reverts the changes made for M3 to the arch, and bring back the previous template with some adaptation when needed. Note: * clipboard: more refactoring needed in some case icons are not visible * M3: some class are still present task-6054024 Co-authored-by: Romain Estievenart <res@odoo.com>
This update standardizes the formatting of key reports related to French tax filings (2033C and 2033D). Specifically, section titles have been adjusted to align with a preferred style, enhancing clarity and consistency for reporting. This ensures accurate and streamlined tax reporting.
Original PR description
This commit updates the section titles for the 2033D report to make them consistent with the 2033C. The preferred format is to use a dash. No task ID
Task: 5973879
Original PR description
Task: 5973879
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Original PR description
part of task-5242369 community: https://github.com/odoo/odoo/pull/256079/
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
Original PR description
Added the parameter sort_by_relevance to autocomplete. This parameter is used in the autocomplete function in community. for this community PR: odoo/odoo#240437 task-5366564
task-6020137
Original PR description
task-6020137
No description available.
Resolved issues and error corrections
This update fixes a visual issue in the title form by adding a grey background to readonly fields. Previously, these fields lacked this background, making them harder to distinguish from editable fields. This change improves the overall clarity and usability of the title form for users.
Original PR description
Before this commit, fields in title forms were missing the grey background. 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 resolves an issue where the 'text-muted' styling in the mass mailing builder was inconsistently applied, depending on the background color. The fix ensures a consistent muted color is always used, improving the visual appearance and usability of mass mailing templates.
Original PR description
This commit fixes an issue with the `text-muted` class that gives a specific color to the text based on a background-color. Since the mass_mailing builder is a special case for background colors. The class now gives a specific color no matter what the background color is set when used inside the mass_mailing builder. task-5993139 Forward-Port-Of: odoo/odoo#252419
This update corrects a visual issue where the table row menu was misaligned in RTL (Right-to-Left) website layouts. The fix ensures the menu's position is accurately calculated by passing the correct 'direction' parameter during editor initialization. This improves the user experience for Arabic and other RTL language users.
Original PR description
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the…
Problem: In RTL websites, the table row menu is not placed correctly. Cause: The `inlineStartOffset` calculation in `table_menu` depends on the `direction` parameter, which was not passed during the editor initialization. Solution: Ensure the `direction` parameter is properly passed during editor initialization so the `inlineStartOffset` is computed correctly in RTL layouts. Before: <img width="1091" height="682" alt="image" src="https://github.com/user-attachments/assets/964903b2-d33b-48aa-86c2-632cc5adac9a" /> After: <img width="1093" height="658" alt="image" src="https://github.com/user-attachments/assets/846fd39c-1114-408d-a1f4-75b27218b9b0" /> Steps to reproduce: - Change website language to Arabic. - Add a text block and insert a table inside. - Hover over the first table row. - Observe the row menu is misplaced. opw-6049260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256045
This update fixes a problem that prevented users from sending follow-up reports by post when they lacked sufficient permissions to access company information. The fix grants elevated access (sudo) to the IAP account, ensuring reports can be processed correctly. This resolves a previous access error impacting report delivery.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to read from res.company model Fix: Access the IAP account as sudo opw-6050041 Forward-Port-Of: odoo/odoo#255959 Forward-Port-Of: odoo/odoo#255431
This update clarifies the website editor's handling of map snippets, specifically addressing a confusing error that occurred when users created custom snippets. The fix ensures that custom snippets are only loaded if the original base snippet is available, preventing errors and improving the user experience. This resolves a potential point of confusion for website editors.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#256847 Forward-Port-Of: odoo/odoo#250236
This update corrects an issue where line breaks added to quotation template section titles were being removed. The fix ensures that section titles display correctly as single lines, aligning with the intended design. Users should now create new sections instead of using line breaks within existing ones.
Original PR description
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with…
Steps to produce: --- - Install `Sales` module. - Go to `Sales > Configuration > Sales Orders > Quotation Templates`. - Create a new template and add a section. - In the section name, add text with line breaks using `Shift + Enter`. - Go to sale orders > Create new SO > Set quotation template created above. Issue: --- - Line breaks entered in the quotation template section lines are stripped when the template is applied to a sale order. These intentional sections are meant to be single-line titles; users should create a new section instead of using line breaks within one. Root cause: --- - At [1], the `name` field is defined without the `section_and_note_text` widget. This widget is responsible for rendering section lines as a `CharField` instead of a `TextField`, as seen at [2]. Solution: --- - Add `widget="section_and_note_text"` to the `name` field. This ensures section lines consistently use `CharField`, preventing line breaks from being entered. [1]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/sale_management/views/sale_order_template_views.xml#L96 [2]https://github.com/odoo/odoo/blob/951b44c0ed5ffb90cff6fa2934ca2664d2faa59d/addons/account/static/src/components/section_and_note_fields_backend/section_and_note_fields_backend.js#L79-L86 opw-6034255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256058
This update resolves an issue where colored links would revert to the default color after using the website editor. The fix ensures that link colors remain consistent regardless of whether the editor is open or closed, improving the visual appearance of website content. This change improves the user experience and maintains brand consistency.
Original PR description
Problem: Colored links revert to the default link color after saving and closing the website editor. Cause: The rule forcing links to inherit color from their parent `<font>` element is defined in the `html_editor` module, whose stylesheet is unloaded when the editor is closed, so the rule no longer applies on the frontend. Solution: Add the rule to `website_common.scss` so it applies on the frontend regardless of whether the editor is loaded. Steps to reproduce: 1. Open the website editor. 2. Apply Color to selection. 3. Apply link to the subset of the selection. 4. Save and close the editor. 5. Observe the link reverts to its default color. task-5980854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256630 Forward-Port-Of: odoo/odoo#253301
This update fixes an issue where the projected margin list view incorrectly displayed the standard sales report instead of a custom view. The change ensures the correct, tailored list view is shown, providing more accurate and relevant margin information for users. This improves the clarity and usability of the margin reporting feature.
Original PR description
Specify the custom list view for the projected margin action window instead of showing the default `sale.report` list view in saas-19.2 --- task-6084014 Forward-Port-Of: odoo/odoo#256822
This update fixes an issue where product images didn't update correctly when hovering over attributes on the shop page. The fix removes a technical element that was causing the browser to prioritize a static image over the dynamically updated image source. This ensures customers always see the correct product variant image.
Original PR description
Steps to reproduce: - Go to the shop page. - Hover over any attribute on a product tile that displays attributes. Issue: - The variant image does not update on attribute hover. Cause: - The `srcset` attribute was introduced for website images in https://github.com/odoo/odoo/commit/36e680feca4884940e020119de6a13cd7f927516. - Only the `src` attribute of the image is updated on hover, while the `srcset` remains unchanged. - Since browsers prioritize `srcset` over `src`, the displayed image does not change. Fix: - Remove the `srcset` when hovering over an attribute to ensure the updated `src` is used. - Restore the original `srcset` when the hover ends. opw-6030289 Forward-Port-Of: odoo/odoo#254606
This update fixes a potential issue where the same work entry type code could be used in multiple countries, leading to data inconsistencies. The change ensures that each country has a unique work entry type code, improving data accuracy and reliability within the HR system. This resolves a previous bug related to error handling.
Original PR description
It was previously possible to create two work entry types with the same code in the same country. It was due to a missing `raise` before the `UserError`. The condition to raise the exception was not correct either. So it has been changed to prevent having two work entry type codes covering the same country. task-6037156 Forward-Port-Of: odoo/odoo#254811
This update fixes a technical issue that prevented RTL languages (like Arabic or Hebrew) from displaying correctly in Odoo forms. The fix ensures proper formatting and layout for RTL languages, improving the user experience for a wider range of customers. This change is a routine fix to enhance usability.
Original PR description
RTLCSS automatically adds '-1 *' when in RTL but only in calc, so we wrap the variable with 'calc'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue preventing webhooks from functioning correctly. Recent changes to access controls inadvertently blocked webhook calls, resulting in a 403 Forbidden error. The fix ensures webhooks can now reliably process invoice data.
Original PR description
- Register your user (on a db that allows webhook). - On another registered account, send an invoice to the first one. => A webhook call has been made, resulting into a 403 Forbidden. Following some changes on access rights checks, the webhook don't work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256607
This update fixes an issue preventing users from sorting invoices based on their deferred dates within the accounting module. The previous code design unintentionally excluded date fields from sorting, now the system correctly handles date-based sorting in grouped lists. This ensures accurate reporting and filtering of invoices.
Original PR description
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view,…
Steps to reproduce 1. Open Accounting > Customers > Invoices and create an invoice with deferred dates. 2. Open the invoice and click the Deferred Entries smart button. 3. In the grouped list view, click the Date column header to sort. 4. Nothing happens. Issue The [IMP] web: Grouped kanban/list in a single RPC (https://github.com/odoo-dev/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf) refactor introduced a regression. _get_read_group_order() [1] iterated over the provided aggregates list to build the ORDER BY clause. Fields with an aggregator attribute that are not included in the aggregates list (e.g. date fields, which getAggregateSpecifications() excludes) were silently dropped from ORDER BY. [1] https://github.com/odoo/odoo/blob/26c37c9c070107f8bd753cb8a6d8343384fdd7bf/addons/web/models/models.py#L496-L514 Solution Add a fallback in _get_read_group_order() so that when fname is neither a groupby field nor present in the provided aggregates list, the method checks field.aggregator directly and appends `fname:aggregator direction` (e.g. `date:min ASC`) to the ORDER BY string. The ORM's _read_group_orderby() already accepts such specs in ORDER BY even without them being in SELECT. opw-6044059 Forward-Port-Of: odoo/odoo#256592
This update corrects a display issue in the PEPPOL configuration settings for branch companies. Previously, branches using their parent company's VAT for PEPPOL registration saw a default 'Sending and receiving' role displayed. This has been fixed to ensure branches can only manage sending, improving the system's usability and aligning with business requirements.
Original PR description
In v19.0 -> master, if a branch company used the VAT of the parent company to register for peppol, the peppol participation role would be shown in the configuration settings, with a default value being "Sending and receiving", And since branches in this case should be able to ONLY send, the setting shouldnt be visibile to the user. task-none Forward-Port-Of: odoo/odoo#256820
This update resolves a technical issue where the Bluetooth caliper driver was sending measurement data without a confirmation status. This caused the frontend to incorrectly display a fake disconnection warning. The fix ensures the frontend receives complete measurement data with a status flag, eliminating the warning and improving the user experience.
Original PR description
When a measurement was successfully read via Bluetooth, the driver broadcasted the `value` without the `status` flag. The frontend JavaScript received the `value` but rejected the payload because the `status` was not explicitly marked as successful, leading to a fake disconnection warning. opw-5473691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256860
This update fixes a previous issue where tax names were displayed in English for Spanish users. Now, all tax names are correctly shown in Spanish, improving the user experience for Spanish-speaking customers and ensuring compliance with local regulations. This change was made as part of a standard maintenance update.
Original PR description
It was a previous dev in which the fw-port failed. Here is the old [PR](https://github.com/odoo/odoo/pull/238857) The tax names were displayed in English, and it's confusing for the Spanish users. Now, the taxes are displayed in spanish task-6041023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256706 Forward-Port-Of: odoo/odoo#255074
This update resolves an issue where the meeting panel appeared unreadable in light themes due to an unintended color inversion. The PR removed a conflicting style class, restoring the panel's original design and ensuring optimal visibility for users.
Original PR description
Before this PR, .o-simulateDarkTheme is applied to the panel in meeting mode. This class inverts the text color, making it white on white. This PR removes the class, which seems to have been applied by mistake. task-6054300 Before: <img width="776" height="1009" alt="image" src="https://github.com/user-attachments/assets/6d7ad6c3-6593-43ba-9101-c8960f3e649f" /> After: <img width="766" height="994" alt="image" src="https://github.com/user-attachments/assets/0cf6b3b6-388c-44bc-b697-760132c06ede" /> Forward-Port-Of: odoo/odoo#255284
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived. Forward-Port-Of: odoo/odoo#256112
This update fixes a technical issue where syncing cancelled events from Microsoft Calendar would sometimes cause an error. Now, when a cancelled event is synced, Odoo correctly handles it, preventing errors and ensuring accurate event synchronization. This improves the reliability of our calendar integration.
Original PR description
Before this commit, when syncing events from Microsoft, if there was a cancelled event that was not yet synchronized with Odoo, calling browse on event.odoo_id would raise an error as it would be None. opw-5917677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256827
This update resolves an issue where Odoo displayed a misleading warning message to users when a password wasn't provided during file uploads. Now, the system correctly checks for a password during saving, eliminating the unnecessary warning and improving the user experience. This ensures consistent behavior and prevents confusion for users.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256759 Forward-Port-Of: odoo/odoo#253834
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use cases causing this issue. 1. Install *Sales* (`sale_management`) 2. In Settings > Technical > Sequences, select the `sale.order` sequence - Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`) - Enable *Use subsequences per date_range* (`ir.sequence.use_d
Original PR description
## Issue When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number. ## Steps to reproduce This is one example among other use…
## Issue
When using date_range in a `ir.sequence`, the placeholders `%(...)s` would be based on a different date than the sequence number.
## Steps to reproduce
This is one example among other use cases causing this issue.
1. Install *Sales* (`sale_management`)
2. In Settings > Technical > Sequences, select the `sale.order` sequence
- Set the Prefix to something containing the current month (e.g. `S%(y)s/%(month)s/`)
- Enable *Use subsequences per date_range* (`ir.sequence.use_date_range`)
- Add a row for the current month, with *Next Number* set to 1
- Add a row for the next month, with *Next Number* set to 5
3. Create a Sales Order:
- Any Customer
- Any Product
- Set the *Quotation Date* to next month
- Confirm
4. **The resulting Sales Order uses the sequence from next month (= its name ends with 5), but replace the `%(month)s` placeholder by the current month.**
<img width="541" height="130" alt="image" src="https://github.com/user-attachments/assets/6ace81f9-1ce2-4401-a9ba-383673a20981" />
The original issue reported by ticket 5950028 showed a similar issue with dropshipped Purchase Orders, which would use the date of delivery for the sequence number, and the current month for the placeholder in the prefix/suffix.
## Cause
When interpolating the prefix/suffix of a sequence, the date used by default is `datetime.now(self.env.tz)`. If provided, the context keys `ir_sequence_date` and `ir_sequence_date_range` are used instead.
https://github.com/odoo/odoo/blob/877289cf4d9725e12b355f482308150fe170e816/odoo/addons/base/models/ir_sequence.py#L211-L216
In the `IrSequence._next` method, the correct `ir.sequence.date_range` is chosen, based on the sequence date provided (which is the *Quotation Date* in our steps to reproduce) and the `ir_sequence_date_range` is passed as a context key to be used in the `_interpolation_dict` function later.
https://github.com/odoo/odoo/blob/98e6e929bf8e0c34ec77fb9d07ef253e0abf681c/odoo/addons/base/models/ir_sequence.py#L261-L270
**The `ir_sequence_date` is not passed as a context key, which will make `_interpolation_dict` use `datetime.now(...)` to interpolate the placeholders in the prefix/suffix.**
opw-5950028
Forward-Port-Of: odoo/odoo#256449
Forward-Port-Of: odoo/odoo#256320This update corrects a technical issue that prevented the system from properly receiving data from serial scales. The team refactored a key method, and a subsequent change inadvertently removed a necessary connection parameter. This fix ensures accurate data collection from serial scales, improving data reliability.
Original PR description
The `_get_raw_response` method was refactored to be static, but a fw port broke its use by missing to provide the serial connection object as parameter. Forward-Port-Of: odoo/odoo#256816
This update resolves a visual glitch that appeared when formatting tables within the To-Do module. Specifically, applying formatting like bold would create unexpected blank lines above the table. The fix prevents styling of system nodes, ensuring a consistent and correct table layout.
Original PR description
Steps to Reproduce - Go to To-Do - Add a table - Type content inside the table - Select all using Ctrl + A - Apply formatting (e.g., Bold) Description of the issue: An empty line appears above the table and the layout shifts unexpectedly after applying formatting. Cause: `data-selection-placeholder` nodes exist before and after the table. These nodes normally have zero height. When selecting all content, these placeholder nodes are also included in the selection. Applying formatting styles them as well, which changes their height from zero. As a result, they become visible and appear as newly added blank lines, even though no new line was actually inserted. Solution Exclude system nodes, such as selection placeholder elements, from formatting operations. This prevents them from being styled and avoids unintended layout shifts. task-5976361 Forward-Port-Of: odoo/odoo#256235 Forward-Port-Of: odoo/odoo#252416
This update enhances the user experience by adding a zoom feature to product images within the Product, Expenses, and Point of Sale modules. Previously, users couldn't easily examine detailed product information. This change provides a better visual inspection experience for products, particularly in the Point of Sale and Expense tracking workflows.
Original PR description
This PR enables the zoom feature for product images across the **Product**, **Expenses**, and **Point of Sale** modules. Currently, some product views display images without the zoom capability. This makes it difficult for users to inspect smaller details of a product. Enabling the `zoom` option on the `image_1920` widget provides a more consistent UI. ### **Changes** Added zoom to the following modules: **hr_expense** (product variant), **point_of_sale** (product view), and **product** (template and variant views). **Task ID: 6003499** Forward-Port-Of: odoo/odoo#255568
This update resolves an issue where journal codes were overlapping in certain languages, like Hebrew, leading to installation problems. The change increases the journal code length to 7 characters, preventing conflicts and ensuring consistent accounting functionality across all supported languages. This improves the stability and reliability of the accounting module.
Original PR description
When generating journals with some languages, such as Hebrew, codes overlap violating the constraint _code_company_uniq. This commit will prevent that from happening by increasing the 5 character constraint to 7. Also removed the "magic number" to be used dynamically. Reproduction steps: - Create a fresh database - Set company language to Hebrew - Attempt to install accounting Enterprise PR: odoo/enterprise#110710 Ticket [link](https://www.odoo.com/odoo/project.task/6001568) opw-6001568
This update ensures that stored field values in Odoo are consistent and don't rely on contextual information. Previously, these values could be unreliable due to caching issues, particularly with related 'x2m' fields. This change improves data accuracy and stability, especially after recent updates to the x2m field caching system.
Original PR description
Stored values cannot depend on the context because they have a single stored value. We have a few exceptions: - "lang" for translated fields - "company" for company-dependent fields task-2903826 Fix x2m related fields after the cache pollution fix odoo/odoo#254944: the related x2m fields need to be computed in sudo to fill the cache with all values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refactors internal code references (t-ref) to align with the upcoming Owl 3 migration. The changes ensure compatibility with the new system semantics and address previously overlooked or recently added references within several Odoo Enterprise modules. This is a necessary step to ensure a smooth transition to the next version.
Original PR description
To prepare the owl 3 migration, we need to open the t-ref directive to the new semantics. This commit fixes a few t-ref that were forgotten or recently added in Odoo Enterprise.
This update resolves a validation error that occurred when generating offers due to a recent change requiring a 'version_id' field. The fix ensures that this 'version_id' is now correctly passed during the salary simulation process, allowing offer generation to proceed smoothly.
Original PR description
-**ISSUE**: Since the "version_id" field in hr.payslip.worked.days model became a required field, the validation error exists. -**FIX**: "version_id" is passed inside the salary simulation payslip. Forward-Port-Of: odoo/enterprise#112602
This update ensures that XML export tests correctly validate tax reports for Italy (l10n_it). A recent change in testing procedures now requires the inclusion of a tax code, which this commit adds to the test setup. This resolves a validation failure and ensures accurate report generation.
Original PR description
Description of the issue this commit addresses: Previously, the testing of the xml exports was only done by generating the file and checking its content against a hardcoded one but a fix[^1] changed that so the tests use the real export flow during which an xsd validation is done. As the tests did not expect to go trough the validation, some mandatory values were not present and it now results in a failing validation (caught in except). [^1]: https://github.com/odoo/enterprise/pull/108548 Desired behavior after this commit is merged: The tests set the l10n_it_codice_fiscale field from which are populated the mandatory CodiceFiscaleDichiarante, CodiceFiscale and CFDichiarante for the xsd validation. opw-5707544 Forward-Port-Of: odoo/enterprise#112629
This update restores the user-friendly display of VoIP call durations, showing times like '9m 12s' instead of numeric values. A previous change attempted a different formatting approach but caused issues, leading to a revert. A new test tour has been added to ensure the duration format remains consistent across views.
Original PR description
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using…
Commit [1] recently updated VoIP duration format on all screens (views and the softphone UI) to be "human readable", going from something like 00:09:12 to 9m 12s. For the softphone UI, it meant using the framework util. For the views, the framework field options using that framework util was not possible to use to have the desired format. Instead, the existing "duration_human_readable" field, computed from "duration", which existed already as it is needed in some python text, was used. Commit [2] broke the views format a few days later. That commit refactored the framework util and field options. Doing so, the softphone UI computation was adapted, correctly. However, the views was switched back to using the default "duration" field with the numeric option, probably because of an ignored conflict. This commit restores the use of "duration_human_readable", as the field util still does not allow to have the wanted format. Indeed, switching off the "numeric" option would show 2m 3s as 0h 2m 3s, which we do not want. We could solve that by changing our DB field to be in seconds instead of hours though, but that would be a bigger change to decide. Still, using "duration_human_readable" which is needed either way makes a lot of sense. This commit adds a tour that checks the format does not change in views whatever field is used. [1]: https://github.com/odoo/enterprise/commit/52e24578700fffde05d9d8f767258aea5f185e8d [2]: https://github.com/odoo/enterprise/commit/fa9329a08eb78c6a9cacfd31a9a1f4bc9e9b6030 Related to task-5951753
This pull request reverts a previous change that was causing issues with email notifications related to contract salaries within the Enterprise module. The change was rolled back to restore the original functionality and prevent disruptions to payroll processes. This ensures accurate and timely salary communications.
Original PR description
Revert https://github.com/odoo/enterprise/pull/111815 Forward-Port-Of: odoo/enterprise#112632
This update clarifies how the annual leave provision is calculated in the payroll system. Previously, it triggered prematurely and displayed confusing rates. Now, it’s applied only to employees after their first year and uses a clear monthly working days calculation, ensuring accurate reporting.
Original PR description
## Before: - Annual Leave Provision showed a confusing rate value. - It could be triggered too early around the first-year period. - “Excluded from Net” was checked. ## After: - Annual Leave Provision is applied only for active employees after one year. - The amount is based on monthly working days, while the displayed rate stays clear at 100%. - “Excluded from Net” is unchecked. Task-6033568 Forward-Port-Of: odoo/enterprise#111225
This update resolves an issue where sales orders with upsells lacking recurring products couldn't be previewed. The change allows this functionality, aligning with existing constraints within the system. This ensures a smoother sales process for users.
Original PR description
When you have an upsell that does not have recurring products, you cannot preview the SO, so we've allow it in this specific case as it is allowed by the constraint on the model Forward-Port-Of: odoo/enterprise#112453
A bug was preventing demo accounts from fully connecting within the Odoo Enterprise system. This fix temporarily resolves the issue by allowing users to set the business type to 'individual' as a workaround. This ensures users can now properly test the demo feature until a permanent solution is implemented.
Original PR description
Step to reproduce: - Click on Connect (demo) - The accounts stay Restricted (even after 5m) This is due to the requirement `company.verification.document` which is present as a pending_verification even when no document is given. Giving it a document such as `file_identity_document_success` which should "marks that document requirement as satisfied" also doesn't work. A work-around is to set the business type to individual since they dont have this requirement. This is a temporary fix, as we want to keep a flow similar to what would have been done in reality. But this is preventing users from testing the feature in 19.0 up to master. Forward-Port-Of: odoo/enterprise#112612
This update resolves an issue where products were incorrectly being deleted from the website generator when a product template only had one associated product. The fix ensures that product records are only removed when intended, maintaining data integrity and preventing potential data loss.
Original PR description
product.product records were being removed when they should not have been in the case that the product.template only has one product.product record. This commit fixes this issue by accounting for the case where there is only one product.product record. Forward-Port-Of: odoo/enterprise#112519
This update resolves a crash that occurred when printing DIAN support documents. The fix prevents a system error by ensuring that report sections are only generated when a valid DIAN attachment exists, improving the printing process for users. This ensures accurate and reliable printing of these important documents.
Original PR description
**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#109912 Forward-Port-Of: odoo/enterprise#108645
This update resolves a technical issue related to how binary data is handled in the l10n_be_reports module, specifically impacting Belgian VAT reporting. The change ensures accurate processing of financial data by aligning with a recent update in Odoo's data handling system. This fix improves the reliability of VAT reports for our Belgian clients.
Original PR description
update the intervat code to fit with the new BinaryValue, see https://github.com/odoo/enterprise/pull/104714 no-task
This update resolves an issue that prevented users from creating contracts when a working schedule had zero hours assigned. The fix prevents a division-by-zero error during hourly wage calculation, ensuring contract creation can proceed smoothly. This improves the reliability of the payroll module for Australian companies.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#112450 Forward-Port-Of: odoo/enterprise#111629
This update resolves a technical issue related to the EU IoT scale driver. As part of the fix, the checksum associated with the scale certification process has been updated to ensure data integrity and compliance. This change is a routine maintenance task.
Original PR description
As we fixed the scale driver, we need to update the checksum. see odoo/odoo#256816 Forward-Port-Of: odoo/enterprise#112594
This update resolves an issue where the attendance step in the payrun flow wasn't correctly displaying on smaller screens. The change ensures the attendance step view adjusts properly when the screen size changes, improving the user experience and preventing errors during payrun creation.
Original PR description
. Fix Attendance step view on the payrun flow task-6085093
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu p
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#111240 Forward-Port-Of: odoo/enterprise#109012
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Original PR description
On mobile, when how_to_call_on_mobile is set to ask, dismissing the call method selection dialog still triggers an outgoing call. Task-[6060319](https://www.odoo.com/odoo/5778/tasks/6060319)
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a s
Original PR description
Why: In the Belgian localization, creating a new version of an employee with the fixed_term flag enabled triggers a search for anterior_versions within the last two years. During the creation of a new version, the contract_date_start field may temporarily be False or unset. Attempting to compare a stored version's start date against a null value (v.contract_date_start <= self.contract_date_start) results in a server-side traceback, blocking the versioning process entirely. What: - Added a safety check to the fixed_term conditional logic. - The filtering of anterior_versions is now only executed if both fixed_term is True AND contract_date_start is populated. task-6060255
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added
Original PR description
- Steps to reproduce: install payroll and attendance, then in employee go on Anita Oliver's form and click on the warning "View Pay Runs". The payrun page sould open and traceback appear. - Reason: the action triggered by the warning does not specify a view id, wich defaults to hr.payrun.attendance.kanban.card (if payroll and attendance installed) or hr.payrun.blank.kanban.card (if payroll only). - Solution: explicitely specify id of the right payrun view (hr.payslip.run.kanban) - Test added in hr_payroll_attendance Task: 6036545
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.re
Original PR description
**Steps to Reproduce:** 1. Open the Attendance app (Make sure hr_payroll module is installed). 2. Immediately create a custom filter which does not produce results (Eg: IP Address = 1) 3. Observe the OwlError: Component is destroyed in the Traceback. **Bug Cause:** When AttendanceGanttController is wrapped by PayRunMixin, the Layout component is replaced by PayRunLayout. PayRunMixin's onRendered hook unconditionally triggered updatePayRun() on every render, which incremented state.revId and forced the Record component (t-key="state.revId") to be destroyed and recreated. This caused a re-render cascade that destroyed AttendanceActionHelper mid-onWillStart, while its async calls (hasGroup, orm.call) were still in flight. **Solution:** In PayRunMixin, guard updatePayRun() so it only fires when payRunId actually changes, instead of on every render. This prevents unnecessary re-render cascades that were destroying AttendanceActionHelper. **Task: 5972786**
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
Original PR description
This commit uses an effect to update the global discount when changing the order. Fix the refound in when global discount since it was handeling only on discoud line where there could be various (one discount line per tax). Task-5421479 Forward-Port-Of: odoo/enterprise#109647 Forward-Port-Of: odoo/enterprise#109481
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uni
Original PR description
When doing a fresh install of accounting with your company language set to Hebrew, you will receive an error violating a constraint on the account_journal table due to the code column being Varchar(5) and the Hebrew translations of "INV" and "BILL" having the same first 5 characters. This commit will allow users to install Accounting when their language is set to Hebrew or switch to the l10n_il with no journals in their database and their language set to Hebrew. Reproduction steps: - Uninstall Accounting + Invoice - Set company language to Hebrew - Install accounting (which will install Invoice) Community PR: odoo/odoo#253737 Ticket [link](https://www.odoo.com/odoo/project.task/6001568) opw-6001568
Features or functions removed from Odoo
This update removes restrictions on which PEPPOL numbers can be used for registration. Previously, only numbers from the PEPPOL list were accepted. Now, businesses can register with a wider range of PEPPOL numbers, increasing flexibility and potential reach for international transactions.
Original PR description
Before this commit, only numbers on the peppol list were able to be registered. Now is possible to add numbers from other countries. Task-6033336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254373
Code cleanup and technical improvements
This update optimizes how Odoo handles the rollback of cron jobs, specifically related to progress tracking. The changes improve the efficiency of these background processes, reducing potential delays and ensuring smoother operation of key business features like order processing and subscription management. This is a routine maintenance update focused on internal performance.
Original PR description
https://github.com/odoo/odoo/pull/257066
Miscellaneous changes
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also ad
Original PR description
The goal of this PR is to move the code from the bridge modules introduced in the CSRD/VSME reporting feature that was deployed in stable versions (see https://github.com/odoo/enterprise/pull/96759). So that the codebase will be cleaner and easier to maintain. Modules change: esg_csrd -> esg esg_csrd_hr -> esg_hr esg_csrd_hr_fleet -> esg_hr_fleet esg_csrd_ai -> ai_esg Where we will move the fields, views, menu items, data, files, etc. Nothing should change functionally. We also add some tests related to the data injected in the VSME/CSRD PDF report. task-5882219