Daily updates from Odoo
Navigate
Branch
Wednesday, February 21, 2024
77 changes
17 changes
Enhancements to existing features
This update clarifies the descriptions for key functions within the spreadsheet account module – specifically `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. These improvements enhance clarity and usability for users, ensuring accurate data input and processing within the spreadsheet.
Original PR description
Improve the wording of the argument descriptions for the functions `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. Task: [3680374](https://www.odoo.com/web#id=3680374&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 Forward-Port-Of: odoo/odoo#154668 Forward-Port-Of: odoo/odoo#153177
Resolved issues and error corrections
This update resolves a bug where users could see multiple quiz versions when quickly clicking the 'Done' button in the eLearning app. The fix ensures only one quiz is displayed, improving the user experience and preventing potential confusion. This change also addresses a similar issue with video content.
Original PR description
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed…
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed if your connection is slow or you click fast enough. The fix ensures that only one quiz is displayed. We do the same change for video to prevent such problem with them. Technical note: when clicking on the "green tick" of the quiz, the method _toggleSlideCompleted is called which cause a _renderSlide. That method clears the content div (o_wslides_fs_content) and appends a new Quiz widget to that div. The problem is that the "append" is asynchronous (it call the "willStart" of Quiz widget that fetch the quiz) so if you click multiple time, the content div is cleared multiple times and then after each quiz created is ready (after having fetched the data), they are appended to the content div, resulting in multiple quiz displayed. We solve the problem by avoiding concurrent execution of the _renderSlide method: the body of the method is skipped when the rendering is ongoing (for example while waiting the quiz from the server). As the method is inserting the slide at the same place, its behavior was anyway unpredictable because depending on the response time of each request. By skipping the method body while already running we make it a bit more predictable, avoid the content duplication on the page, and we avoid unnecessary call to the server. Task-3412847 Forward-Port-Of: odoo/odoo#154069 Forward-Port-Of: odoo/odoo#143743
This update resolves an issue where users couldn't edit content after undoing a column command in the web editor. The fix ensures that the editor correctly recalculates and re-establishes the unique identifier (ouid) for elements after reverting changes, allowing for seamless editing.
Original PR description
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add…
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add columns - Do ctrl+z - Try to write anything Origin of the issue: ==================== When we apply a columns operations , it will use the current block and insert it under the first column so the `ouid` of the block will change to the `oid` of the div (the column) so will will have 2 mutations : one to remove the block from the root and one to add the block under the column. Reverting history will do the operations in reverse order, so it will remove the block from under the column and the add it under the root but the `block.ouid` is already set to `oid` of the column which is different from the actual `ouid` which is `root` so adding any text to the block will first add a textnode with `getOuid(node,true) = block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will mark `this._toRollBack` as true and the operation is rolled back that's why we can't add anything anymore. Soltuion: ========= Mark the `ouid` of the removed elements as undefined so when we insert them again we can recalculate it correctly. task-3693076 Forward-Port-Of: odoo/odoo#150431
This update addresses a potential issue where new modules automatically grant the Default Template User's permissions to existing employees. Now, administrators can disable this automatic propagation through a simple setting, giving companies greater control over user access rights. This prevents unintended escalation of permissions and aligns with company security policies.
Original PR description
When installing a new module, the access of the Default Template User is propagated to any existing employee (introduced at aefb05eb497a8a16a). This can be problematic in companies that don't want all their employees to become manager by default. Allow to disable this behaviour in a settings. This is the version of the patch targetting stable version that is not configurable through the interface, manually creating an ICP base_setup.default_user_rights_minimal=True as the way to change the behaviour. Closes odoo/odoo#149224 Task-id 3685856 Forward-Port-Of: odoo/odoo#150391
This update fixes an issue where the stock move date in the traceability reports incorrectly displayed the scheduled production date instead of the actual completion date. The fix ensures that the reports accurately reflect the date the production was finished, improving inventory reporting accuracy. This resolves a discrepancy impacting inventory valuation and reporting.
Original PR description
Issue: ===== The stock move date is the scheduled date of the production and not the date the production is done. Steps to reproduce the issue: ============================= - Create a manufacturing order with any product (large desk) - Assign a date in the past for scheduled date (5 days before) - Confirm the order. - Added quantity produced and mark as done - Go to traceability , you will see the date here is the scheduled date and not the production date. - You can see also the inventory at date in inventory/reporting/locations will have the product they after the scheduled date. Solution: ========= Use the value of `date_finished` in `date_planned_finished` because it's responsible for calculation of `date` of `move_finished_ids`. opw-3640708 Forward-Port-Of: odoo/odoo#154745 Forward-Port-Of: odoo/odoo#149358
This update addresses a technical issue within Odoo's core functionality related to how it processes read groups. While the underlying change might seem minor, it ensures a more robust and reliable system, preventing potential errors. This fix prioritizes stability and proper error handling.
Original PR description
Use read_group with groupby=['id'] raise a Exception:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 2386, in _read_group_format_result
m2x_records = self.env[field.comodel_name].browse(ids).union()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 521, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/Documents/dev/odoo/odoo/modules/registry.py", line 190, in __getitem__
return self.models[model_name]
KeyError: None
```
While if it doesn't make much sense to do this (it's mostly equivalent to search_read), it's preferable to handle the case properly.
Forward-Port-Of: odoo/odoo#154748
Forward-Port-Of: odoo/odoo#153505This update fixes a conflict between the 'Cancel' button and its shortcut key (z) within the activity scheduling feature. The hotkey has been changed to 'x' to avoid confusion and ensure users can easily cancel scheduled activities. This improves the user experience and prevents accidental actions.
Original PR description
Since 17.0, the `Cancel` button in the `mail_activity_schedule_view_form` uses the hotkey `z`, which conflicts with the other button. Change the hotkey into `x`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154727
This update resolves an issue where Odoo forms crashed when adding new records linked through inherited relationships (using _inherits). The fix ensures that parent record updates only occur when the related one2many field has a valid value, preventing initialization errors and improving stability.
Original PR description
Consider models A and B such that B inherits from A (with `_inherits`), and a form view of A with a one2many field that inverses the many2one "delegate" field from B to A. When adding a new record in the one2many, `onchange()` crashes while trying to update the cache of an empty parent record. The situation is caused by how `onchange()` initializes the new record of model B, and the fact that the form provides a value for the delegate field. The new record is actually initialized with an empty value for the delegate field, which causes the code to crash. The fix simply consists in updating the parent record only if is nonempty. opw-3744514 Forward-Port-Of: odoo/odoo#154735
This update fixes an issue where HR emails sent when applicants are rejected were being automatically deleted. This prevented HR from seeing communication and gaining a complete record of applicant interactions. The change ensures that all emails related to rejected applicants are retained, providing a more accurate and complete history.
Original PR description
When HR refuses applicants in batch and sends mails, the mails are removed, because auto_delete_keep_log is set to false. It gives to HR wrong understanding that mails have not been send. Expected behavior; Don't remove refused mails, when sent in batch Forward-Port-Of: odoo/odoo#154720
This update adds a "Cancel" button to the activity plan wizard, which was missing in the recent v17 release. Users can now easily cancel their activity plan creation, reverting to the previous state without needing to use the "X" button. This improves user experience and simplifies the process of managing activity plans.
Original PR description
Restore the "Cancel" button when selecting a plan from the activity wizard. When we introduced the plan feature in v17, the "Cancel" button was forgotten. The only way for users to cancel the action is to click on the "X" button at the top right. task-3754897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154678
This change temporarily disables a failing test in the website's link tools to address persistent issues. The test has consistently failed due to underlying race conditions, and this action allows the test to run successfully on the automated system. A permanent fix is planned for a future commit.
Original PR description
runbot-57204 Forward-Port-Of: odoo/odoo#154679 Forward-Port-Of: odoo/odoo#154244
This update removes a confusing 'No documents to display' message from the customer portal. Because users always have access to their addresses and security/connection cards, this message was unnecessary. This change improves the overall user experience and reduces potential frustration for customers.
Original PR description
Remove `No documents to display` as there will always be at least the addresses and security/connection cards. task-id: 3629038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146197
This update corrects a minor issue where users were incorrectly redirected to general settings when clicking the Google and Outlook calendar sync buttons. Now, clicking these buttons will correctly direct users to the calendar settings, improving the user experience and ensuring seamless calendar synchronization. This resolves a previous navigation problem.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. Configure Google and Outlook Calendar and navigate to the calendar app. 2. Click on the Google and Outlook sync button, redirecting to the general settings. **Issue:** Users are now redirected to the general settings by using the Google and Outlook sync button. **Solution:** Update the `doAction` so, users will be redirected to the calendar settings. task-3731652 <hr/> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153581
This update fixes an issue where 'mandatory' days in the holiday calendar were displaying with an inconsistent color, causing visual problems. The changes now ensure 'mandatory' days render correctly with the calendar's background colors, providing a cleaner and more professional look. This improves the user experience when scheduling and viewing holidays.
Original PR description
"Mandatory" days use a random text color and they don't render well with the colored background colors of `.fc-today` and hovered days. The text-color has been removed on hovered mandatory days and mandatory days happening "today". The background of "fc-today" now uses the color of mandatory days when that day is mandatory. The SCSS has been cleaned up so as to not create repetitions. task-3617334 part of task-3575827 | Before | After | |----|-----| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144236
This update ensures that payment method configurations are correctly applied, allowing overriding modules to control payment method availability. Additionally, the system now automatically archives payment tokens when a payment method is disabled or no longer supports tokenization, preventing future payments through outdated tokens.
Original PR description
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method,…
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method, preventing overriding modules from controlling which payment method should be available depending on the kwargs. task-3640488 --- [FIX] payment: archive tokens of payment methods blocking tokenization When a payment method was updated in a way that prevented creating tokens with it, that is, by either disabling it, unchecking the "Tokenization Supported" field, or unlinking it from providers, only the latter would automatically archive the related tokens after showing a warning to the user. The two first actions prevented the creation of future tokens with that payment method, but existing tokens could still be used. This commit fixes that behavior by adding the warning and the automatic archiving of related tokens where they were missing. Preventing further tokenization with a payment method now consistently blocks payments through existing tokens, too. --- See also: - https://github.com/odoo/enterprise/pull/54700 Forward-Port-Of: odoo/odoo#150120
This update fixes an issue where the Peppol endpoint could not handle special characters, ensuring data integrity. It also updates the system to always check the commercial partner ID for Peppol verification, resolving a previous limitation that prevented users from sending invoices to specific contacts. This enhancement improves the reliability of Peppol invoice processing.
Original PR description
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not…
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not filled in, we already throw an error when creating an edi user, so that should be fine. task-3718573 ### [FIX] account_peppol: check commercial partner instead of partner When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration. Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant. opw-3748720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154823 Forward-Port-Of: odoo/odoo#152654
Code cleanup and technical improvements
This update streamlines how currency information is loaded for spreadsheets, reducing the number of requests needed to format monetary values. By combining currency data with the main list data, the process is faster and more efficient, leading to quicker spreadsheet calculations. This change also lays the groundwork for future improvements in data loading reliability.
Original PR description
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request,…
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request, instead of 2 RPCs. Pros: - less code - one evaluation saved - one network request saved - easier future refactoring (see below) Cons: - overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped, to fetch a list of 20K crm leads). Before this commit, here is what it looked like: 1. the list data is fetch (with the currency_field) 2. the cells are evaluated with the new data 3. we realize we want to format a currency amount. We already have the currency name but not the symbol, etc. So we fetch the currency data 4. evaluate the cells again with the new currency format Now: 1. fetch the list data with everything we need for the currency 2. evaluate the cells This commit also serves another goal for a future refactoring: in the hope of avoiding throwing "loading errors", I'd like to have an easy way to know if a data source is fully loaded or not (the data and the format). With this commit, everything is centralized in the list data source with a single RPC. The goal is therefore achieved with this commit. Task: 3730232 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 Forward-Port-Of: odoo/odoo#153434
35 changes
Enhancements to existing features
This update improves the reliability of automated checks for the Documents Spreadsheet side panel. It ensures the panel is fully loaded before tests run, reducing false failures and helping maintain product quality.
Original PR description
This commit is the counterpart of https://github.com/odoo/odoo/pull/154837. This commit adds a nextTick to ensure that the side panel is correctly rendered.
The Documents app search panel has been updated to work better on mobile devices and stay aligned with recent platform changes. This should make browsing and filtering documents on smaller screens smoother and more consistent for users.
Original PR description
This commit adapts the documents customization of the search panel to follow changes made in https://github.com/odoo/odoo/pull/149246 task-3644159
This update adds support for e-commerce operator reporting in India’s GSTR-1 process, including the relevant Table 14 information. It helps businesses prepare more complete GST filings and includes cleanup to make the reporting logic easier to maintain.
Original PR description
Related PR-https://github.com/odoo/odoo/pull/153070 task-3672448
Luxembourg payroll rules and related parameters have been adjusted to reflect changes that apply in 2024. This helps ensure employee salary calculations remain accurate and aligned with current local requirements.
Point of Sale test tours now start through a shared mechanism that reduces duplicated code and checks component setup more thoroughly. This helps catch configuration issues earlier during testing, improving reliability without changing day-to-day user workflows.
Original PR description
In this commit we remove the startOwl function from pos and replace it's uses with the mountComponent from web. This has the advantage that we repeat code less. In addition, the `mountComponent` function also makes it such that the prop declarations of the components are checked during tours. This provides great benefits in terms of type checking. In order to be able to make this change, all the prop declarations that were wrong had to be corrected. In addition, we also implement a generic mechanism for starting pos tours. This allows for less code repetition. Task 3756376 https://github.com/odoo/odoo/pull/152243
Spreadsheets can now use the company’s custom branding colors directly from the color picker. This makes it easier for users to create reports and documents that match the company identity without manually recreating colors.
Original PR description
With this commit, the company custom colors (for the documents/reports layout, and emails) now appears in the spreadsheet color picker as custom colors. It allows to easily create spreadsheets with the company identity. Task: 3707769
Project-related features now identify completed tasks using a shared “closed” status rather than specific task state values. This makes task filtering more consistent across field service, planning, holidays, sales forecasting, and enterprise project features, reducing mismatches in reports and workflows.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/149805 Task-3681837
Planning settings now separate two mutually exclusive options: employees can either switch shifts with colleagues or unassign themselves from shifts. This makes the available scheduling behavior clearer for administrators and keeps the default behavior focused on shift switching.
Original PR description
Before this commit, it was not clear to users that the 'switch shifts' feature existed, and that is it mutually exclusive with the 'allow unassignment' option in the Planning settings. To make things clear, this commit splits the 'allowing unassignment' setting in two: - The 'switch shifts with other employees' option which corresponds to the current behavior when the 'allow unassignment' feature is disabled. It is the default value. - The 'unassignment themselves from shifts' option which corresponds to the current behavior when the 'allow unassignment' feature is enabled. task-3703648
Planning users now see a clear pop-up when changing the time, date, or recurrence settings of a recurring shift from the calendar. This helps them choose how the change should apply, reducing accidental updates across multiple planned shifts.
Original PR description
In this PR, when trying to modify the time, date, or recurrence settings for a planned shift from the calendar view, a pop-up dialog will be displayed. Within this dialog, you can choose the desired options for the shifts task-3502065
Users with access to multiple companies can now choose and change the company on approval requests, making requests easier to manage across organizations. Approval lists also show company and approver information more clearly, and the approve button is easier to interpret depending on whether documents are attached.
Original PR description
This commit adds the possibility for user to select the company for which he wants to create an approval request if they have the multi company access rights. Also, the company field is added in the approval request form view and it's now writable to make the user able to change the company of the approval request if needed. the company field is also added in the approval request tree view for better visibility. In addition to that, this commit adds a small ux improvement for the approve button to make it more visible or less visible depending if a document has been attached to the approval request or not. For the tree view, the approvers are now displayed to be visible for the user. task-3632010
Resolved issues and error corrections
The cohort view now applies the same muted sample-data styling to its horizontal scrollbar when sample data is shown. This keeps the interface visually consistent and prevents the scrollbar from standing out unnecessarily.
Original PR description
This commit fixes an issue where the eventual horizontal scrollbar in cohort table would not receive sample data styling when needed. This would make it far too apparent due to https://github.com/odoo/odoo/pull/148138 OPW-3733829
The barcode batch transfer screen now hides the Confirm button when users open the action/settings menu where that action is not relevant. This reduces confusion and prevents users from seeing an option that does not make sense in the current view.
Original PR description
…e list views To reproduce issue: .go to barcode app .click on batch transfers .click on new .click on engine icon Expected result: confirm button hide Actual result: confirm button is not hide I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr When a user navigate from batch transfer and click on a engine icon the confirm button still showing, it's no makes sense for the current view. Now, when the user click on it, the confirm button will be hide and apear when close that menu. spec: https://drive.google.com/file/d/1UR-PtoM5CjfEi3X4p7LEpitl1_sspF-h/view task-3525776
Miscellaneous changes
Versions: --------- - saas-17.1 Issue: ------ The test tour is failing. Cause: ------ The 'allocated_hours' step was added in the test tour, even though the 'View Task' form view does not have this field until timesheet is enabled. Solution: --------- Removing this step as the 'allocated_hours' field is not present in the view. task-3750478 Forward-Port-Of: odoo/enterprise#56772
Original PR description
Versions: --------- - saas-17.1 Issue: ------ The test tour is failing. Cause: ------ The 'allocated_hours' step was added in the test tour, even though the 'View Task' form view does not have this field until timesheet is enabled. Solution: --------- Removing this step as the 'allocated_hours' field is not present in the view. task-3750478 Forward-Port-Of: odoo/enterprise#56772
From: { "merchant_category_code": None, "creditor": { "postal_address": None, "organisation_id": None, "private_id": None, "creditor_account": None, "creditor_agent": None, }, "debtor": { "name": None, "postal_address": None, "organisation_id": None, "private_id": None, }, "debtor_account": { "iban": "BE84103080286059", "other": None, "debtor_agent": None,
Original PR description
From: { "merchant_category_code": None, "creditor": { "postal_address": None, "organisation_id": None, "private_id": None, "creditor_account": None, "creditor_agent": None, }, "debtor": { "name":…
From:
{
"merchant_category_code": None,
"creditor": {
"postal_address": None,
"organisation_id": None,
"private_id": None,
"creditor_account": None,
"creditor_agent": None,
},
"debtor": {
"name": None,
"postal_address": None,
"organisation_id": None,
"private_id": None,
},
"debtor_account": {
"iban": "BE84103080286059",
"other": None,
"debtor_agent": None,
"bank_transaction_code": None,
"credit_debit_indicator": "DBIT",
"status": "BOOK",
"value_date": "2022-12-29",
"transaction_date": None,
"balance_after_transaction": None,
"reference_number": None,
"debtor_account_additional_identification": None,
"creditor_account_additional_identification": None,
"exchange_rate": None,
"note": None,
},
}
to:
debtor_account:
iban: BE84103080286059
credit_debit_indicator: DBIT
status: BOOK
value_date: 2022-12-29
Forward-Port-Of: odoo/enterprise#56701
Forward-Port-Of: odoo/enterprise#54592The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit
Original PR description
The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit renames the problematic variable and adds a test to avoid regression on that front. Forward-Port-Of: odoo/enterprise#43917
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.`
Original PR description
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.` By not specifying the field on the domain, we query on multiple field from res_partner Solution: Specify the field that intereses us when defining the domain opw-3712980 Forward-Port-Of: odoo/enterprise#56980 Forward-Port-Of: odoo/enterprise#56516
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print t
Original PR description
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print the worksheet - Notice It'll space to the next page if there's too many lines instead of it adjusting to two pages accordingly Solution: - Adjust the worksheet template by removing the 'div class="table-responsive-sm"' it seems removing the class, or having "table" seems to fix the issue it would be better to remove the class since the direct child is already a .table opw-3701917 Forward-Port-Of: odoo/enterprise#56363
When we unselect the mandatory benefit, the dependent benefit should be unset and disabled. But before this commit this is not a case. The explanation of an issue: The issue only happens if dependent benefit has value different from 0, so the value should be unset first before disabling the dependent benefit. When the dependent benefit should be unset, it calls the asynchronous function, which prevents the lines that disable the dependent benefit to be reached. task-3749171 Forward-
Original PR description
When we unselect the mandatory benefit, the dependent benefit should be unset and disabled. But before this commit this is not a case. The explanation of an issue: The issue only happens if dependent benefit has value different from 0, so the value should be unset first before disabling the dependent benefit. When the dependent benefit should be unset, it calls the asynchronous function, which prevents the lines that disable the dependent benefit to be reached. task-3749171 Forward-Port-Of: odoo/enterprise#56886 Forward-Port-Of: odoo/enterprise#56714
This commit adds an override of the `payment.method::_get_compatible_payment_methods` method to force payment methods to support tokenization when paying for a subscription. task-3640488 See also: - https://github.com/odoo/odoo/pull/150120 Forward-Port-Of: odoo/enterprise#54700
Original PR description
This commit adds an override of the `payment.method::_get_compatible_payment_methods` method to force payment methods to support tokenization when paying for a subscription. task-3640488 See also: - https://github.com/odoo/odoo/pull/150120 Forward-Port-Of: odoo/enterprise#54700
…ies in some case In a few rare cases, an issue with the provider can cause the transactions to be duplicated within the same call to fetch transactions. This commit fixes the issue by ignoring entries within the same call that would happen to have the same transaction_identifier. Forward-Port-Of: odoo/enterprise#56995 Forward-Port-Of: odoo/enterprise#56165
Original PR description
…ies in some case In a few rare cases, an issue with the provider can cause the transactions to be duplicated within the same call to fetch transactions. This commit fixes the issue by ignoring entries within the same call that would happen to have the same transaction_identifier. Forward-Port-Of: odoo/enterprise#56995 Forward-Port-Of: odoo/enterprise#56165
…me method Have two models that have a method with the same name. Create multiple rules for model 1 and 1 one rule for model 2 Before this commit, the rule on model 2 will interfere with model 1. This was because some domains missed to filter on the model of the rule After this commit, rules are not colliding between models. opw-3734028 Forward-Port-Of: odoo/enterprise#56945
Original PR description
…me method Have two models that have a method with the same name. Create multiple rules for model 1 and 1 one rule for model 2 Before this commit, the rule on model 2 will interfere with model 1. This was because some domains missed to filter on the model of the rule After this commit, rules are not colliding between models. opw-3734028 Forward-Port-Of: odoo/enterprise#56945
Accountants were able to see account.journal of parent companies, but not online accounts and links. This commit sets the same visibility for the 3 objects ticket-3748174 Forward-Port-Of: odoo/enterprise#57034
Original PR description
Accountants were able to see account.journal of parent companies, but not online accounts and links. This commit sets the same visibility for the 3 objects ticket-3748174 Forward-Port-Of: odoo/enterprise#57034
To reproduce ============ - Create a subscription with a monthly period - Send it to client and pay it on portal (by strip for example) - Wait for the next renewal date (change date to future) - execute manually the crons : - Sale Subscription: generate recurring invoices and payments - payment: post-process transactions - The invoice is created but not sent to the customer or posted in chatter Problem ======= the condition `not invoice.is_move_sent` is true in this use-case which wil
Original PR description
To reproduce ============ - Create a subscription with a monthly period - Send it to client and pay it on portal (by strip for example) - Wait for the next renewal date (change date to future) - execute manually the crons : - Sale Subscription: generate recurring invoices and payments - payment: post-process transactions - The invoice is created but not sent to the customer or posted in chatter Problem ======= the condition `not invoice.is_move_sent` is true in this use-case which will block sending the invoice, in this context this condition does not make sense as we want to send the unsent invoice so it's removed in this commit opw-3691557 Forward-Port-Of: odoo/enterprise#56416
This commit is aimed at avoiding the reloading of the webclient assets when the cron is run. This is done by removing files from the _get_data_files_to_update method. task-3607711 Forward-Port-Of: odoo/enterprise#54120
Original PR description
This commit is aimed at avoiding the reloading of the webclient assets when the cron is run. This is done by removing files from the _get_data_files_to_update method. task-3607711 Forward-Port-Of: odoo/enterprise#54120
Forward-Port-Of: odoo/enterprise#57011
Original PR description
Forward-Port-Of: odoo/enterprise#57011
Current behavior: When the websocket connection is lost, the webworker will attempt to reconnect. However, the messages that were sent in the meantime are lost. The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. To solve this, we listen to the reconnect event and retrieve the orders that were sent in the meantime. opw-3701020 Forward-Port-Of: odoo/enterprise#56640 Forward-Port-Of: odoo/enterprise#56163
Original PR description
Current behavior: When the websocket connection is lost, the webworker will attempt to reconnect. However, the messages that were sent in the meantime are lost. The fix: The websocket webworker attempts reconnection indefinetely, so we do know that at some point it will indeed reconnect. To solve this, we listen to the reconnect event and retrieve the orders that were sent in the meantime. opw-3701020 Forward-Port-Of: odoo/enterprise#56640 Forward-Port-Of: odoo/enterprise#56163
**Steps to reproduce:** 1- Install Field Service module 2- Create new task and click on products smart button 3- Hover over a product and click on the dropdown menu 4- Click on edit in the dropdown menu 5- Get back to the products page and check the quantity for the product you edited **Current behavior before PR:** When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user
Original PR description
**Steps to reproduce:** 1- Install Field Service module 2- Create new task and click on products smart button 3- Hover over a product and click on the dropdown menu 4- Click on edit in the dropdown menu 5- Get back to the products page and check the quantity for the product you edited **Current behavior before PR:** When the user clicks on edit in the dropdown menu of any product the quantity gets increased by 1. This is happening because of the global click event so when the user clicks anywhere inside the kanban box the quantity gets updated. **Desired behavior after PR is merged:** This behavior has been adjusted by checking the target where the user click if it is inside the dropdown menu it will not update the product's quantity. opw-3689864 Forward-Port-Of: odoo/enterprise#56885 Forward-Port-Of: odoo/enterprise#54645
Steps to reproduce: - In Sequences > Sale order: change the prefix with `%(year)s` - create a SO; mark quotation as sent - create a bank statement with the same label as the SO's name - try to match Issue: No "sale orders" tab will ne displayed Cause: ``` > [x.lower() for x in text_tokens if x.lower().startswith(sequence_prefix)] [] ``` Since `sequence_prefix` would be `%(year)s` and the the label `202400022` Solution: Simplify everything with an orm search opw-3663266 Fo
Original PR description
Steps to reproduce: - In Sequences > Sale order: change the prefix with `%(year)s` - create a SO; mark quotation as sent - create a bank statement with the same label as the SO's name - try to match Issue: No "sale orders" tab will ne displayed Cause: ``` > [x.lower() for x in text_tokens if x.lower().startswith(sequence_prefix)] [] ``` Since `sequence_prefix` would be `%(year)s` and the the label `202400022` Solution: Simplify everything with an orm search opw-3663266 Forward-Port-Of: odoo/enterprise#56904 Forward-Port-Of: odoo/enterprise#55450
After the conversion of the user service to a simple module, a traceback started happening when trying to resend a document. This was due to the missing conversion of the user service paradigm to the module one for that specific flow. This commit fixes this by using the user module instead of the user service. task-3710633 Forward-Port-Of: odoo/enterprise#55468
Original PR description
After the conversion of the user service to a simple module, a traceback started happening when trying to resend a document. This was due to the missing conversion of the user service paradigm to the module one for that specific flow. This commit fixes this by using the user module instead of the user service. task-3710633 Forward-Port-Of: odoo/enterprise#55468
Several improvements and issues correction on switzerland payroll : name correction, column alignment task : 3644541 Forward-Port-Of: odoo/enterprise#56919 Forward-Port-Of: odoo/enterprise#53551
Original PR description
Several improvements and issues correction on switzerland payroll : name correction, column alignment task : 3644541 Forward-Port-Of: odoo/enterprise#56919 Forward-Port-Of: odoo/enterprise#53551
According the SRI documentation, we should consider the accounting date (field date) on the search filters Forward-Port-Of: odoo/enterprise#55547
Original PR description
According the SRI documentation, we should consider the accounting date (field date) on the search filters Forward-Port-Of: odoo/enterprise#55547
Fix the appointment type kanban view ungrouped display on all screen sizes. Task-3617435 Forward-Port-Of: odoo/enterprise#56610
Original PR description
Fix the appointment type kanban view ungrouped display on all screen sizes. Task-3617435 Forward-Port-Of: odoo/enterprise#56610
The aim of this commit is making sure that we only have inbound moves in `Dispatch` category and outbound moves in `Arrival` category. no task id Forward-Port-Of: odoo/enterprise#56887 Forward-Port-Of: odoo/enterprise#56747
Original PR description
The aim of this commit is making sure that we only have inbound moves in `Dispatch` category and outbound moves in `Arrival` category. no task id Forward-Port-Of: odoo/enterprise#56887 Forward-Port-Of: odoo/enterprise#56747
During a forward port (https://github.com/odoo/enterprise/commit/bb67df2f37a65acd9f62a28d8a52fbd335ef903e), we introduced a bug because the old warning system was in conflict with the new one. The aim of this commit is removing the old one (that are not working) for the new one. In the same time, we make sure that we use the right key when getting ids that have an issue. opw-3741287 opw-3741721 opw-3741658 Forward-Port-Of: odoo/enterprise#56683
Original PR description
During a forward port (https://github.com/odoo/enterprise/commit/bb67df2f37a65acd9f62a28d8a52fbd335ef903e), we introduced a bug because the old warning system was in conflict with the new one. The aim of this commit is removing the old one (that are not working) for the new one. In the same time, we make sure that we use the right key when getting ids that have an issue. opw-3741287 opw-3741721 opw-3741658 Forward-Port-Of: odoo/enterprise#56683
The aim of this commit was originally adding a test to verify that we could unfold the report. After some investigations, we discovered that we have several fields in `account_intrastat` that are using `one2many` fields in related fields (causing an issue in our test). Thus, this commit is changing related fields to computed one. We decided arbitrary that we'll take the first value of the `one2many` field for each computed ones. no task id Forward-Port-Of: odoo/enterprise#56699 Forward-
Original PR description
The aim of this commit was originally adding a test to verify that we could unfold the report. After some investigations, we discovered that we have several fields in `account_intrastat` that are using `one2many` fields in related fields (causing an issue in our test). Thus, this commit is changing related fields to computed one. We decided arbitrary that we'll take the first value of the `one2many` field for each computed ones. no task id Forward-Port-Of: odoo/enterprise#56699 Forward-Port-Of: odoo/enterprise#56525
25 changes
New functionality added to Odoo
A CODEOWNERS file has been added to the repository to establish clear ownership and responsibility for different parts of the codebase. This helps streamline code review processes by automatically assigning the appropriate team members to review changes in their areas of responsibility.
Original PR description
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
Enhancements to existing features
This update ensures that financial reports in Chile use the correct local terminology for "Untaxed Amount" (translated as "Monto neto" instead of the Spain/LATAM standard). The change applies across multiple sales and accounting modules to maintain consistent and accurate financial reporting for Chilean customers. Unnecessary untranslated entries have also been removed to improve file clarity.
Original PR description
In Chile, "Untaxed Amount" has its own special term that isn't used in Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [as for v17 since customer changed their mind]. Therefore everywhere that it appears (in a .pot file), we ensure that the es_CL localization uses this term. Also untranslated terms from the es_CL.po files that were edited have been removed since they add no benefit and make it harder to read the file (we expect to only add terms to the file, not translate every term for Chile). opw-3670297 Forward-Port-Of: odoo/enterprise#54939 Forward-Port-Of: odoo/enterprise#54712
This update improves the Belgian payroll system's performance by preventing unnecessary reloading of web interface files when automated payroll tasks run. The change removes certain files from the update process, allowing payroll operations to complete more quickly without disrupting the user experience.
Original PR description
This commit is aimed at avoiding the reloading of the webclient assets when the cron is run. This is done by removing files from the _get_data_files_to_update method. task-3607711 Forward-Port-Of: odoo/enterprise#54120
This update improves how bank transaction information is displayed in the accounting module by removing unnecessary empty fields and showing only relevant transaction details. Users will now see a cleaner, more focused view of transaction information like account numbers, transaction status, and dates without cluttered empty data fields.
Original PR description
From: { "merchant_category_code": None, "creditor": { "postal_address": None, "organisation_id": None, "private_id": None, "creditor_account": None, "creditor_agent": None, }, "debtor": { "name":…
From:
{
"merchant_category_code": None,
"creditor": {
"postal_address": None,
"organisation_id": None,
"private_id": None,
"creditor_account": None,
"creditor_agent": None,
},
"debtor": {
"name": None,
"postal_address": None,
"organisation_id": None,
"private_id": None,
},
"debtor_account": {
"iban": "BE84103080286059",
"other": None,
"debtor_agent": None,
"bank_transaction_code": None,
"credit_debit_indicator": "DBIT",
"status": "BOOK",
"value_date": "2022-12-29",
"transaction_date": None,
"balance_after_transaction": None,
"reference_number": None,
"debtor_account_additional_identification": None,
"creditor_account_additional_identification": None,
"exchange_rate": None,
"note": None,
},
}
to:
debtor_account:
iban: BE84103080286059
credit_debit_indicator: DBIT
status: BOOK
value_date: 2022-12-29
Forward-Port-Of: odoo/enterprise#56701
Forward-Port-Of: odoo/enterprise#54592This update ensures that the "Untaxed Amount" field displays the correct Chilean Spanish term "Monto neto" across multiple financial and operational modules. The change improves localization accuracy for Chilean users by using region-specific terminology that differs from standard Spanish. Unnecessary untranslated entries were also removed from Chilean translation files to improve clarity.
Original PR description
In Chile, "Untaxed Amount" has its own special term that isn't used in Spain/LATAM spanish: ~~"Total neto"~~ "Monto neto" [as for v17 since customer changed their mind]. Therefore everywhere that it appears (in a .pot file), we ensure that the es_CL localization uses this term. Also untranslated terms from the es_CL.po files that were edited have been removed since they add no benefit and make it harder to read the file (we expect to only add terms to the file, not translate every term for Chile). opw-3670297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150683 Forward-Port-Of: odoo/odoo#150141
This update allows companies to prevent automatic propagation of manager-level access rights to all employees when installing new modules. Previously, all existing employees would automatically receive the same access rights as the Default Template User. Now administrators can disable this behavior by setting a configuration option, giving companies more control over user permissions and security.
Original PR description
When installing a new module, the access of the Default Template User is propagated to any existing employee (introduced at aefb05eb497a8a16a). This can be problematic in companies that don't want all their employees to become manager by default. Allow to disable this behaviour in a settings. This is the version of the patch targetting stable version that is not configurable through the interface, manually creating an ICP base_setup.default_user_rights_minimal=True as the way to change the behaviour. Closes odoo/odoo#149224 Task-id 3685856 Forward-Port-Of: odoo/odoo#150391
Resolved issues and error corrections
This update corrects an inaccurate help message in the Amazon sales integration module. The fix ensures users see the correct guidance when working with Amazon account settings, improving clarity and reducing confusion during setup and configuration.
Original PR description
Forward-Port-Of: odoo/enterprise#57011
Fixed an issue in the Partner Ledger report where searching for a partner by email would incorrectly display unrelated partners in the PDF output. The search filter was matching against multiple partner fields instead of just the partner name, causing incorrect results. This fix ensures that only the intended partner appears in filtered reports.
Original PR description
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.` By not specifying the field on the domain, we query on multiple field from res_partner Solution: Specify the field that intereses us when defining the domain opw-3712980 Forward-Port-Of: odoo/enterprise#56910 Forward-Port-Of: odoo/enterprise#56516
A variable naming issue in the cohort analysis feature was causing incorrect data to be displayed in reports. The problematic variable was being reused in multiple places, contaminating the calculations. This fix renames the variable to prevent the collision and adds tests to ensure the issue doesn't happen again.
Original PR description
The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit renames the problematic variable and adds a test to avoid regression on that front. Forward-Port-Of: odoo/enterprise#43917
This update fixes the Belgian HR payroll 281.10 tax declaration form to comply with 2023 regulations. Changes include updating car exemption rules, ensuring bike travel kilometers and amounts are properly declared even when below taxable thresholds, and adding mandatory information fields required by Belgian tax authorities.
Fixed a formatting issue in the Field Service worksheet report where tables with multiple products and assignees were incorrectly breaking across pages, causing table headers and content to overlap. The fix removes an unnecessary CSS class that was preventing proper page layout, allowing reports to display correctly across multiple pages when needed.
Original PR description
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print the worksheet - Notice It'll space to the next page if there's too many lines instead of it adjusting to two pages accordingly Solution: - Adjust the worksheet template by removing the 'div class="table-responsive-sm"' it seems removing the class, or having "table" seems to fix the issue it would be better to remove the class since the direct child is already a .table opw-3701917 Forward-Port-Of: odoo/enterprise#56363
Fixed an issue in Colombia's withholding tax reports where empty line items (with zero tax base amounts) were incorrectly appearing in the Certificado de Retención en IVA report and being included in totals. The fix ensures that only transactions with actual amounts are reported, making tax documents cleaner and more accurate.
Original PR description
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odoo/enterprise#56308
This update fixes scrollbar behavior problems in the online store's product category filters that were caused by recent browser updates. The scrollbar now displays and functions correctly across different browsers (Chrome, Firefox) and devices, including better support for touchscreen devices where the hover effect is now disabled.
Original PR description
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium…
In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium updated the way ::webkit-scrollbar works breaking the behavior on recent browser. On firefox the margin was applied without the change of height on the scrollbar creating a visual glitch on hover. On chromium >121 the `scrollbar` property takes priority over the `::webkit`-x to keep the scrollbar styling with height change on webkit browser we have to apply the `scrollbar` property only on Firefox. The mixin was used only on `website_sale` filter offcanvas and category horizontal scrollbar, this commit removes the mixin and customization on the offcanvas vertical scroll to make it consistent with the other offcanvas across website. This PR also disables the scrollbar hover effect on touchscreens. The transform was causing an issue on some devices displaying the scrollbar behind the items, thus it's now applied on the container. Note: We use not `.o_wsale_filmstip_fancy_disabled` to avoid the `scrollbar` property being set when the Javascript is not loaded yet. Otherwise the scrollbar would be invisible until a hover from the user. task-3718501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the VAT code in the Saudi Arabia electronic invoicing demo data to match the current requirements from ZATCA's Sandbox environment. This fix ensures that test submissions through the Sandbox portal will work properly for users testing the Saudi Arabia invoicing functionality.
Original PR description
Description of the issue/feature this PR addresses: ZATCA changed the VAT code used for submissions on Sandobx. The vat number in the l10n_sa_edi's demo data need to be updated to reflect this change. Current behavior before PR: Submissions through Sandbox do not work as the VAT code set on the demo Saudi company is different from the one the Sandbox portal expects. Desired behavior after PR is merged: Sandbox submissions should work properly once the demo data is updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153851
This fix ensures that automatically generated invoices link to the correct website where the original sales order was placed, rather than defaulting to the primary website. Previously, invoice preview links would always open the main website regardless of which website the customer used to make their purchase, creating a confusing experience in multi-website setups.
Original PR description
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings**…
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings** > **Website** and set the domain for: - My Website -we'll refer to it as **website_1**- as http://[IP_address]:[port] such as http://127.0.0.1:8069 - My Website 2 -we'll refer to it as **website_2**- as http://[IP_address]:[port] such as http://127.0.0.2:8069 - Create a new product with **Invoicing Policy** as **Ordered quantities** - Go to **website_2** and add the new product to the cart and checkout - With Debug mode on, Check the Emails sent via **Settings** > **Technical** > **Email** > **Emails** ### Current Behavior Two emails are automatically sent: - An SO email that opens **website_2** when clicking on **View Sales Order** button which is correct as we purchased the product through **website_2** - An Invoice email that opens **website_1** when clicking one **View Invoice** button which is **_WRONG_** as it should follow its originating SO and opens **website_2** as well ### Expected Behavior Both SO and invoice emails should refer to the website where the SO was created -**website_2** in our use case- ### Observations The automatic invoice always refer to **website_1** regardless of the website where the SO was originally created. ### Investigation The `website_id` of the invoice is decided by the corresponding field https://github.com/odoo/odoo/blob/322889ea0a24c5eff2e3289502a2f606cb4048d0/addons/website_sale/models/account_move.py#L10-L13 - As noticed it's a related field to the `partner_id.website_id` which is **False** - That's why the invoice `website_id` is also **False** leading to the preview button to fall back to **website_1** - The `partner_id.website_id` is always False unless you manually added the field to the view and then set the `website_id`. Our case will work correctly if you set the `website_id` for the user/customer to **website_2** - I also tried to sign up at **website_2** to see if the website_id will be set accordingly but it stayed as **False** ### Proposed Solution make the invoice `website_id` relates to the **_originating_** SO instead of the partner ### Drawbacks 1. I am not sure if depending on the `website_id` of the partner is crucial other parts! 2. In case the invoice has more than one SO associated with, the `website_id` relates to the website_id of the most recent SO. However, I don't think it will lead to a bug as the automatic invoice -to my knowledge- will always relate to one SO. ### Other solutions I thought of 1. Always set the website_id to the website_id sending the request via a default attribute. 2. Set the `website_id` to the website_id sending the request if the automatic invoice option is active other wise set to False. -Same as 1 but more conservative- 3. Enhance the current solution by adding a **default** and a **compute** attribute to set the `website_id` to **False** if the invoice has more than one SO and at least one SO has a different `website_id` than the rest. - Not sure if it worths the complexity tho- opw-3685742 Forward-Port-Of: odoo/odoo#153691 Forward-Port-Of: odoo/odoo#151070
When setting up Stripe payment processing for multiple companies, the system was incorrectly copying website information from one company's configuration to another, causing errors or misconfigurations. This fix ensures that website settings are properly cleared when creating a new Stripe payment provider for a different company, allowing smooth multi-company payment setup without conflicts.
Original PR description
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you…
Description: In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()` to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending on the version. On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider. On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the wrong company, preventing the record from being created. In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly for the new record. Desired behavior after PR is merged: The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method opw-3683338 Forward-Port-Of: odoo/odoo#154280
This update significantly improves the speed of filtering operations in Odoo forms, particularly when working with large lists of items. For example, when adding automated actions and filtering available models, the system now processes these changes in milliseconds instead of several seconds, making the user experience much smoother.
Original PR description
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule…
Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule form view, click on "Add an action", and in the dialog form view, select a "mail" type, e.g. "Add followers". In that form view there's a many2many field "available_model_ids" which contains at first almost all models of the database (LINK commands). Switching to a "mail" model restricts those models to the ones inheriting from the thread mixin, i.e. it generates a lot of UNLINK commands. On runbot, in represents 1000+ LINK and UNLINK commands. This could take several seconds. With this commit, we no longer iterate over all commands when applying a DELETE or UNLINK command. Instead, we simply push the command, store somewhere the information that we applied such a command, and after having processed all commands, we iterate (once) over this._commands, this.records and this._currentIds to do the necessary cleanups. task 3599674 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 fix resolves a problem where formatted numbers in shared spreadsheets were displaying incorrectly. When users shared a spreadsheet containing formatted large numbers (like 1.23 million), the shared link would show incorrect values (like 123 million). The fix ensures that the actual numeric values are exported correctly instead of relying on formatted text that could be misinterpreted.
Original PR description
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 Forward-Port-Of: odoo/odoo#153912 Forward-Port-Of: odoo/odoo#153704
This fix resolves an issue where users couldn't type or edit text after using the undo function (Ctrl+Z) on column layout changes in the web editor. The problem occurred because the system wasn't properly recalculating text block positions when reverting column operations. Now the system correctly resets block references during undo, allowing users to continue editing normally.
Original PR description
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add…
Issue: ===== When you undo a column command, you won't be able to write on that line anymore. Steps to reproduce the issue: ============================= - Go knowledge - Use column command to add columns - Do ctrl+z - Try to write anything Origin of the issue: ==================== When we apply a columns operations , it will use the current block and insert it under the first column so the `ouid` of the block will change to the `oid` of the div (the column) so will will have 2 mutations : one to remove the block from the root and one to add the block under the column. Reverting history will do the operations in reverse order, so it will remove the block from under the column and the add it under the root but the `block.ouid` is already set to `oid` of the column which is different from the actual `ouid` which is `root` so adding any text to the block will first add a textnode with `getOuid(node,true) = block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will mark `this._toRollBack` as true and the operation is rolled back that's why we can't add anything anymore. Soltuion: ========= Mark the `ouid` of the removed elements as undefined so when we insert them again we can recalculate it correctly. task-3693076 Forward-Port-Of: odoo/odoo#150431
This update fixes two issues with Peppol electronic invoice sending. First, it adds validation to prevent special characters in Peppol endpoints, ensuring data integrity. Second, it corrects how the system identifies valid invoice recipients by checking the main company partner instead of individual contacts, allowing users to send invoices to specific contacts of a partner when the company has active Peppol registration.
Original PR description
### [FIX] account_peppol: add endpoint constraint The Peppol endpoint must not contain special characters. This commit adds a constraint, where the input is being sanitized. If the endpoint is not filled in, we already throw an error when creating an edi user, so that should be fine. task-3718573 ### [FIX] account_peppol: check commercial partner instead of partner When checking a partner's validity on Peppol network, we should always check the `commercial_partner_id` to get the right eas & endpoint. Also, the Peppol verification check should not occur if the current company does not have an active peppol registration. Currently, if a user wants to send an invoice to a specific contact of a partner, they cannot as `_need_ubl_cii_xml` evaluates to False because the contact is not a valid Peppol participant. opw-3748720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152654
Fixed an issue where manufacturing orders were showing the originally scheduled date instead of the actual date when production was completed. This ensures that product traceability records and inventory reports accurately reflect when items were actually produced, not when they were planned to be produced.
Original PR description
Issue: ===== The stock move date is the scheduled date of the production and not the date the production is done. Steps to reproduce the issue: ============================= - Create a manufacturing order with any product (large desk) - Assign a date in the past for scheduled date (5 days before) - Confirm the order. - Added quantity produced and mark as done - Go to traceability , you will see the date here is the scheduled date and not the production date. - You can see also the inventory at date in inventory/reporting/locations will have the product they after the scheduled date. Solution: ========= Use the value of `date_finished` in `date_planned_finished` because it's responsible for calculation of `date` of `move_finished_ids`. opw-3640708 Forward-Port-Of: odoo/odoo#154745 Forward-Port-Of: odoo/odoo#149358
This update fixes a bug that caused the system to crash when using the read_group function with groupby=['id']. While this operation is uncommon, the system now handles it gracefully instead of throwing an error, improving overall stability and reliability.
Original PR description
Use read_group with groupby=['id'] raise a Exception:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 2386, in _read_group_format_result
m2x_records = self.env[field.comodel_name].browse(ids).union()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 521, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/Documents/dev/odoo/odoo/modules/registry.py", line 190, in __getitem__
return self.models[model_name]
KeyError: None
```
While if it doesn't make much sense to do this (it's mostly equivalent to search_read), it's preferable to handle the case properly.
Forward-Port-Of: odoo/odoo#154748
Forward-Port-Of: odoo/odoo#153505This update improves the speed of message loading in the mail system by optimizing how instant messaging status is tracked. The change reorganizes how the system calculates status information, reducing message insertion time by approximately 50% (from 60ms to 30ms in testing). Users will experience faster message delivery and loading times when using the messaging features.
Original PR description
Move compute of `imStatusTrackedPersonas` to its inverse field. Doing the compute on the "One" side of the relation prevents from looping and computing all values whenever there is a change in any of them. In practice, this reduces the "compute" time of the message fetch (which also fetch persona as authors of messages), reducing by approximately half the time it takes to insert these messages (depending on the number of persona it had to loop through). For example from 60ms to 30ms on my machine for message insert in "partner_1_125" (populate medium).
Documentation and clarification updates
Buckstop Labs has signed the Contributor License Agreement (CLA) required to contribute to Odoo. This approval document has been added to the repository, allowing the organization to submit code contributions going forward.
Original PR description
Description of the issue/feature this PR addresses: added my agreement Current behavior before PR: did not include my agreement Desired behavior after PR is merged: you can read the .md i added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Asergo has signed the Contributor License Agreement (CLA) required for contributing to Odoo. This legal document confirms their right to submit code contributions to the project and protects both the contributor and Odoo.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr