Daily updates from Odoo
Friday, March 22, 2024
67 changes
5 changes
Resolved issues and error corrections
Posting messages in Discuss channels now avoids sending a duplicate update when the channel activity timestamp has not changed. This reduces race-condition errors and makes chat and live chat behavior more stable for users.
Original PR description
Currently, posting a message to discuss channels is done in two steps: first writing the last_interest_dt to the channel, then creating the message, second triggering the notify_thread to send the message to the followers. In the first step, the last_interest_dt will be directly sent to the client if it differs from the old value. So there is no need to send the message to the client if the last_interest_dt has not changed in the second step. Also, this can lead to a racing condition in the testing files. This commit removes the notif in the second step. Also, adapting the mock_models to the new behavior as the follow-up of https://github.com/odoo/odoo/pull/155569 https://github.com/odoo/enterprise/pull/59130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The calendar year view now keeps month header backgrounds visible when users scroll. This prevents overlapping text and makes the calendar easier to read, especially in smaller browser windows.
Original PR description
In Odoo in the custom `year` FullCalendar view we embed twelve custom `month` FullCalendar views, and it has the option `height` set to `auto`. In FullCalendar (V6), when the `dayGrid` FullCalendar…
In Odoo in the custom `year` FullCalendar view we embed twelve custom `month` FullCalendar views, and it has the option `height` set to `auto`.
In FullCalendar (V6), when the `dayGrid` FullCalendar view as the option `height`/`viewHeight` equals to `auto` it is the same to have the option `stickyHeaderDates` set to `true`.
When the option `stickyHeaderDates` is enabled, the class `fc-scrollgrid-section-sticky` is added to the header of the FullCalendar view. This class as the following rule:
```css
.fc .fc-scrollgrid-section-sticky > * {
background: var(--fc-page-bg-color);
position: sticky;
z-index: 3;
}
```
And since the upgrade of FullCalendar to version 6[1], we have added the following CSS rule.
```css
.o_calendar_widget {
--fc-page-bg-color: none;
}
```
As we have set the `color` to `none`, the `background-color` of the element is `transparent` and so the text overlaps the text behind.
This commit simplifies the CSS rules and fixes the issue.
PS: the old override of the `--fc-page-bg-color` color was to support the dark theme.
From FullCalendar doc[2]
> stickyHeaderDates
> Whether to fix the date-headers at the top of the calendar to the
> viewport while scrolling.
Steps to reproduce:
* Open the Calendar App
* Select the "Year" FullCalendar view
* Resize the window to have a vertical scrollbar if needed
* Scroll down => BUG some day headers have `position` `sticky` with no background.
[1]: odoo/odoo@90f85a19deaea33cd747c969762ff20f1d59ef4c
[2]: https://fullcalendar.io/docs/stickyHeaderDates
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe manufacturing Bill of Materials overview now works correctly when Odoo is used in debug mode. This prevents an error that could interrupt troubleshooting or advanced configuration work, and adds coverage to ensure the overview appears properly in guided tests.
Original PR description
In this [commit](https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR569-R577), the updateResId has been added to the action props. This did not trigger any error as the props are not validated, except if in debug mode. Adding the standardActionServiceProps solves this problem. This bug highlighted another problem: the component does not appear in a tour. opw-3822623 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 fixes an issue where creating a planned task from the Gantt view could miss allocated hours when Timesheets was not installed. The task form now includes the needed field so planning calculations run reliably for Project users.
Original PR description
Before this commit, when only project and project_enterprise are instaleld and we try to plan a new task in the gantt view. The compute allocated_hours is not triggered during the onchange because the field is not defined in the form view used by the gantt view. This commit makes sure the allocated_hours field of `project.task` is defined even if `hr_timesheet` is not installed to be sure the compute of that field is triggered during the onchange when we create a task. runbot-58150
Spreadsheet users now receive a more helpful error message when a pivot formula uses an invalid measure. The message shows the available measures, making it easier to correct the formula without extra troubleshooting.
Original PR description
Before this commit, applying a pivot formula with an invalid measure returns an error message without showing possible measures. This commit fixed that Task 3754942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update resolves an issue preventing sale reports from generating correctly when multiple bank accounts were used for a payment. The previous system required a single account payment, which is now corrected. This ensures accurate reporting for all sales transactions, regardless of payment method.
Original PR description
Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
This update fixes a default setting in the restaurant POS module that was incorrectly configured for US customers in the SaaS environment. Previously, the system automatically enabled tipping after payment, regardless of the user's country. This change ensures a better experience for all users by removing the US-specific default.
Original PR description
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore. Forward-Port-Of: odoo/odoo#149542
3 changes
Resolved issues and error corrections
This update rewrites complex reporting queries in a safer internal format so automated checks can handle them reliably. It helps reduce false alarms and maintenance risk in accounting and localization reports without changing day-to-day user workflows.
Original PR description
After some improvements the SQL checker now sees those queries, and can't cope with their complexity. Also deprecate `AccountReport._query_get`, literally all it does is unwrap `_get_table_expression` making things harder to check.
Users can now duplicate read-only Sign templates without encountering an error. This makes it easier to reuse existing templates and continue document workflows without interruption.
Original PR description
Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206
The Helpdesk team setup screen now displays the Team Members label correctly when automatic assignment is enabled. This small visual fix makes the configuration form look cleaner and easier to read for administrators.
Original PR description
Steps to reproduce: - install helpdesk - under configuration, click on helpdesk teams - In helpdesk teams form view enable automatic assignment Issue: - under automatic assignment, the 'team members' label is not centered Solution: - By giving d-flex to the div tag of label the issue will be solved. task-3683976
57 changes
Resolved issues and error corrections
Fixed an issue in the Journal Report where certain columns, particularly the Invoice Date column, were not appearing in the report after upgrading to version 17.0. The fix reorganizes how columns are arranged so that all columns display properly in the correct order.
Original PR description
This PR addresses an issue with the Journal Report where columns positioned after 'additional_col_1' or 'additional_col_2' were not being displayed. Furthermore, in databases migrated to version…
This PR addresses an issue with the Journal Report where columns positioned after 'additional_col_1' or 'additional_col_2' were not being displayed. Furthermore, in databases migrated to version 17.0, a new record 'invoice_date' is inserted into the account_report_column table, but the corresponding 'Invoice Date' column is not visible in the journal report.
### Current situation:
account_report_column
```
aksi_test=# select id, name, sequence , report_id, expression_label from account_report_column where report_id = 17 order by id;
id | name | sequence | report_id | expression_label
----+---------------------------+----------+-----------+------------------
63 | {"en_US": "Account"} | | 17 | account
64 | {"en_US": "Label"} | | 17 | label
65 | {"en_US": "Debit"} | | 17 | debit
66 | {"en_US": "Credit"} | | 17 | credit
67 | {"en_US": ""} | | 17 | additional_col_1
68 | {"en_US": ""} | | 17 | additional_col_2
85 | {"en_US": "Invoice Date"} | | 17 | invoice_date
(7 rows)
```
### After Fix:
Journal Report
Users can now successfully export custom composite reports to Excel format. The fix resolves an issue where exporting would fail due to inconsistent data handling in company options. The system now ensures all company data is properly formatted and passed through the export process.
Original PR description
The aim of this commit is to allow the user to make xslx export with custom composite report. Context: The customer made a custom report in which he is calling some other reports. Before this commit:…
The aim of this commit is to allow the user to make xslx export with custom composite report. Context: The customer made a custom report in which he is calling some other reports. Before this commit: Exporting the report would results in a traceback. This happenned because a keyError is raise when trying to access the `companies` key which isn't present in the dictionnary. The initializers for the `companies` key weren't consistent with each other. In some initializer, the `currency_id` key was set. In other, it wasn't. In method `_add_options_xlsx_sheet` only the exact same options were kept before pursuing the operations. As the `currency_id` wasn't set for all the options, it was ignored. After this commit: The file can be exported with success. To solve the `currency_id` key difference issue and prevent it to happen again, we centralize the place where the dictionnaries are created to be sure the exact same keys are set for the `companies` options regardless of how those companies are chosen. opw-3802602
The Swedish tax report has been updated with new values for specific report sections (blocks F and G). This change updates the corresponding test cases to ensure they accurately validate the new report calculations. This ensures the tax reporting functionality continues to work correctly with the updated report structure.
Original PR description
The values of blocks F and G have been changed on the sweedish tax report on the `l10n_se` module. This commit adapt the tests accordingly. Forward-Port-Of: odoo/enterprise#58870 Forward-Port-Of: odoo/enterprise#58508
This update refreshes the X (formerly Twitter) logo and branding colors throughout the social media integration module. The changes ensure that Odoo's social media features display the current X branding, keeping the platform aligned with the rebranded service.
Original PR description
*: website_twitter_wall This commit involves adjustments to a few images and SVG files to incorporate the new X (previously called Twitter) logo. related to: https://github.com/odoo/odoo/pull/148126 task-3463530 Forward-Port-Of: odoo/enterprise#59056 Forward-Port-Of: odoo/enterprise#53644
Fixed an issue where spreadsheets could be renamed to blank spaces. Now, if a user attempts to rename a spreadsheet with only spaces, the system automatically reverts to the original name or a default "Untitled" name. This ensures spreadsheets always have valid, readable names.
Original PR description
Before: Spreadsheet can be renamed to blank spaces. After: If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name. Task: 3559704 Forward-Port-Of: odoo/enterprise#59055 Forward-Port-Of: odoo/enterprise#51550
This fix prevents employee departments from being incorrectly changed when signing contracts that use parent department templates. Since contract templates are typically defined at the company or parent department level, the system now preserves the employee's current department assignment instead of overwriting it with the template's parent department.
Original PR description
If the departement of the contract template is a parent of the employee's current department, we shouldn't update that value, since contract templates are mostly defined on the super department task-3818437
This fix ensures that indirect managers (managers of managers) can now edit validated timesheets for their team members, just like direct managers can. Previously, only direct managers could edit validated timesheets even though indirect managers could validate them. This resolves an inconsistency in permission handling across the management hierarchy.
Original PR description
In such a hierarchy: Clara -> Maxime -> Gregory Before this revision: Maxime and Gregory can validate Clara's timesheets, but only Maxime can edit fields of Clara's validated timesheets thanks to the fact he is the direct manager of Clara. Gregory is the manager of Clara by recursivity, and the recursivity was correctly handled in the validation check, but not in the edition of validated timesheets. After this revision: Maxime and Gregory can validate Clara's timesheets, Maxime and Gregory can edit fields of Clara's validated timesheets. opw-3613473 Forward-Port-Of: odoo/enterprise#58874 Forward-Port-Of: odoo/enterprise#58782
This update corrects the placement of the currency field in electronic documents for Ecuador, specifically for invoices, liquidations, and credit notes. A previous change added the currency tag in the wrong location, which has now been fixed and the related tests have been updated to ensure proper document generation.
Original PR description
- In PR #54687, a currency tag label "moneda" was added for all electronic documents and in the wrong position. - Fix the position to add the "moneda" tag for invoices, liquidations, credit notes and fix the tests for this electronic documents. Forward-Port-Of: odoo/enterprise#58932
When creating approval requests with products, the description column was incorrectly showing the product name instead of the actual purchase description from the product details. This fix ensures the correct product description from the purchase tab is now displayed in approval line items, providing users with accurate product information during the approval process.
Original PR description
In Approvals, you can create Approval Request where you select Products (in demo data : Create RFQ). When you do that, on the request creation itself, you'll be able to pick products and add it in lines. There's a column description, but that column is not populated correctly, it's just a copy of the name. It should be the description from the product, purchase tab. TaskID: 3794627 Forward-Port-Of: odoo/enterprise#58909 Forward-Port-Of: odoo/enterprise#58492
This update fixes two issues in the US 1099 tax form wizard. First, when users change the date range, the wizard now properly clears old lines instead of accumulating them from multiple years. Second, when adding new lines, the wizard now automatically filters to show only items within the selected date range, eliminating the need for manual filtering and improving the user experience.
Original PR description
### Commit 1 [FIX] l10n_us_1099: clear lines when start or end date is changed Before this, setting the date fields to 2023 would show all 2023 lines in the wizard. Changing the date range to 2022 would add 2022 lines while keeping the 2023 lines. After this commit only 2022 lines remain in the wizard. opw-3774654 ### Commit 2 [FIX] l10n_us_1099: filter on date by default when adding new lines Typically a user clicks "Add a new line" on the lines_to_export o2m when they want to add lines in the selected date range from other accounts. Currently the user is presented with all journal items and will have to manually filter on the right date. Improve usability by filtering on the right date range by default. opw-3774654 Forward-Port-Of: odoo/enterprise#59180
This fix addresses a test that was failing unpredictably in the Mexican POS invoicing feature. The test was relying on demo data that could vary depending on what other modules were installed, causing inconsistent results. The fix uses a dedicated test partner and removes unnecessary configuration steps to ensure the test runs reliably every time.
Original PR description
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have…
Since 39a0542b6505e18e3fdfbefba4210d8ba87bae3c, the value of `l10n_mx_edi_cfdi_to_public` depends on the partner linked to the pos_order. For instance, a mexican partner without VAT will have `l10n_mx_edi_cfdi_to_public` to True by default.
The tour `test_mx_pos_invoice_previous_order` is failing undeterministically. The tour proceeds as follows:
- create an order without partner, and validate it
- later, go the list of paid orders, select the last one and invoice it
- the list of partners opens to allow setting one
- then, a dialog opens to set the `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public`
Currently, we simply select the first partner in the list ("(AR) Exento" if l10n_ar is installed...). When selecting this partner, we trigger the compute which will set a value on `l10n_mx_edi_cfdi_to_public`. Then, we can input `l10n_mx_edi_usage` and `l10n_mx_edi_cfdi_to_public` in the dialog. But the values filled in that dialog are not always saved to the database before ending the tour.
This fix uses a new partner to no longer depends on demo data. In addition, we leave the default values in the dialog to make sure the test will not fail no matter if the dialog's values are saved or not in the database (in a proper subsequent fix, we should ensure that we always end the tour after the dialog's values are saved).
runbot build error 60671This fix restores sugar tax groups that were missing from the Colombian localization module due to changes in how chart templates are managed. The tax groups are now properly configured in the system, ensuring accurate tax calculations for Colombian businesses.
Original PR description
Sugar tax groups were not present in saas-16.2+ fw-port, due to the new way Chart Templates are handled. https://github.com/odoo/enterprise/pull/50366/files Adding them back now. Old PR for saas-16.2: odoo/enterprise#53209 Task link: http://www.odoo.com/web#id=3569752&model=project.task task-3569752 Forward-Port-Of: odoo/enterprise#58802
This fix corrects how products are sorted by category in the barcode picking view. Previously, the system tried to sort by category ID (which wasn't even available), causing incorrect sorting. Now it properly sorts by the actual category name, making the picking process more intuitive for warehouse staff.
Original PR description
Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.)…
Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.) This would sort by the ID, not the name, which is probably not expected behavior. 2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place. This fix adds `product_category_name` as a field to be read from the `stock.move.line` within the `_get_stock_barcode_data` method of `stock_barcode/models/stock_picking.py`. It also changes `categ_id` to `product_category_name` with the `_sortingMethod` method of `stock_barcode/static/src/models/barcode_model.js` As a final note, I am unsure if `categ_id` should be removed from the [`_get_fields_stock_barcode` method in `stock_barcode/models/product_product.py`](https://github.com/odoo/enterprise/blob/5b2fb8d0f3baf4fdc13e9399061110e06e3c76da/stock_barcode/models/product_product.py#L19). In this context it should be removed, however I'm unsure if other code may use it, and for compatibility sake it would be best to leave it there. opw-3693232 Forward-Port-Of: odoo/enterprise#59054 Forward-Port-Of: odoo/enterprise#56633
Fixed three critical issues with Estonian tax reports (KMD INF and VD/EC Sales) that were preventing file acceptance by tax authorities. The fixes address incorrect XML formatting, number format requirements, and missing credit note data in tax calculations.
Original PR description
There were a few problems reported with the KMD INF and VD reports. 1. The namespace of the VD (EC Sales) XML export was incorrect, causing the file not to be accepted on the autorities platform. This was fixed. 2. In the VD XML export, the numbers were floats, while they had to be integers for the platform to accept the file. This was fixed. 3. Customer credit notes were not taken into account in the KMD INF report. This was a small issue in the SQL query, were we only considered lines with a tax balance > 0, where for credit notes it is < 0. opw-3758841 Forward-Port-Of: odoo/enterprise#58897
This fix corrects how blacklisted email providers are handled in the recruitment module. Previously, blacklisted email addresses were being checked but then still used when sending emails. The fix now properly removes blacklisted emails from the message, ensuring that blocked providers cannot send recruitment-related communications.
Original PR description
In https://github.com/odoo/odoo/pull/126065 we introduced the feature, that blacklists providers. The issue with it, is that even if we only provide email_from once we check it's not blacklisted [1], when we call the super method, email_from is still filled in [2] In order to correct it, we also delete blacklisted mail from msg_dict [1] - https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/hr_recruitment/models/hr_applicant.py#L615-L616 [2] -https://github.com/odoo/odoo/blob/aed0e74462b15085c09d9ab5ff029810f1238aeb/addons/mail/models/mail_thread.py#L1388-L1390 task-3793345
This fix resolves an issue where automated actions could be triggered twice when they depend on computed fields during record creation. The problem occurred because the system wasn't properly tracking which automated actions had already run when evaluating field values. By sharing tracking information between field evaluation and action processing, automated actions now run only once as intended.
Original PR description
Imagine the following situation: an automated action A is triggered when some stored computed field F has a certain value. When a record is created and no value is given for field F, then the automated action A may be run twice: once when evaluating A's domain forces the computation of F, and once again because A's domain is satisfied. The implementation already uses context flags to reflect which automated actions have already been run, in order to avoid automated actions to be run recursively. The fix consists in enabling those context flags to be shared among the evaluation of the domain and processing of the automated actions. opw-[3731182]
This fix resolves a technical error that occurred when users tried to add tasks to a contact and assign those tasks to a project linked to a sales order. The issue has been corrected so users can now complete this workflow without encountering errors.
Original PR description
## Issue: - When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object…
## Issue:
- When adding tasks to a contact using Studio and attempting to set a task's project to a project linked to a Sales Order (SO), we encounter the following error: "TypeError: 'NewId' object is not iterable."
## Steps To Reproduce:
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
## Solution:
- The issue arises in the search domain of [_get_last_sol_of_customer](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/addons/sale_timesheet/models/project.py#L603), where the domain is ('order_partner_id', 'child_of', self.partner_id.commercial_partner_id.id), and the type of `self.partner_id.commercial_partner_id.id` is `NewId` since the partner is being edited to add a task.
- This action triggers the [parse](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L805) and [to_ids](https://github.com/odoo/odoo/blob/2209021a3b77109824b572bb38c6c5d05554d753/odoo/osv/expression.py#L847) methods with a value type of `NewId`. thus the error.
- The operator child_of deals with a list of ids, and the ids property refer to the record's origin ids. to resolve this, replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an issue where Razorpay POS online payments were incorrectly rejecting valid phone numbers, preventing customers from completing transactions. The system now allows customers to enter their phone number directly on the Razorpay checkout page when needed, improving the payment experience.
Original PR description
Before this commit: In POS online payment the usually the user is either the logged in user/public user which ends up raising error `The phone number is invalid` even when the customer is selected After this commit: Razorpay doesn't raise the error instead we send no phone number due to which user has to enter his/her phone number manually on the razorpay checkout page task-3786679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update broke the ability to generate sales reports when a point of sale session used multiple bank payment methods. This fix restores report generation functionality by resolving a technical error that occurred when processing sessions with more than one payment account. Users can now successfully generate sales reports regardless of how many payment methods were used.
Original PR description
Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426
Fixed an issue where invoices with the same filename could not be imported for different companies in the same Odoo database. The system now properly tracks which company each invoice attachment belongs to, allowing Company A and Company B to both import invoices with identical filenames without conflicts.
Original PR description
As we imported invoices from the IAP proxy we refused files when the same filename was already present in the database. Import invoices sent by Company A to Company B on the same Odoo database was therefore impeded. The CRON would try to import the Company B's vendor bill with the same attachment's filename as the Company A's invoice and reject the file. Now we fill in the `company_id` field on the attachment and we search for attachments which belong to the company we're importing for, so the case is covered. An import test has been added. Ticket [link](https://www.odoo.com/web#model=project.task&id=3673508) opw-3673508
This fix resolves a critical memory consumption problem in the POS self-order kiosk when displaying products with images. By switching from processing large image files to checking smaller, pre-stored image versions, the system now uses 55 times less memory—reducing usage from over 1.6 GB to just 30 MB. This prevents server crashes when loading kiosks with many product images.
Original PR description
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128`…
Description of the issue/feature this PR addresses: For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key). Previously, the field `image_1920` was used which has two issues: 1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used. 2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so: a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157 b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550 So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead. Memory benchmarks for allocations by `_get_self_order_data`: Done on customer DB with 1340 product.products, with a total of 776 images between them. Before commit: 1638.4 MiB + server memory limit reached After commit: 29.7 MiB total Total improvement of 55x less memory usage Current behavior before PR: Server memory limit reached when loading pos kiosk with many product images in filestore Desired behavior after PR is merged: Use much less memory. opw-3809503
Users in Saudi Arabia encountered an error when trying to reverse journal entries because the required "Reason" field was not visible in the reversal dialog. This fix makes the reason field visible for Saudi Arabian companies, allowing users to complete the reversal process as required by local regulations.
Original PR description
With a SA company setup Open a jounrnal entry Hit 'Reverse Entry' > Reverse Error: "For Credit/Debit notes issued in Saudi Arabia, you need to specify a Reason" This occurs because with SA localization we need to provide a reason for move reversal but by default the reason field is invisible for journal entries opw-3789732
This update fixes translation problems in the Favorite Field component that wasn't displaying translated text properly. Additionally, Italian language translations were corrected to use more accurate and commonly-used terminology for business identifiers and mobile phone references. Users will now see properly translated interface elements and more appropriate Italian business terminology.
Original PR description
`BooleanFavoriteField` wasn't translated as the component was using an untranslated variable instead of relying on the translation of the template. Some other translation fixing: - ID Azienda is very generic, the correct name is Numero REA: See: https://www.registroimprese.it/codice-fiscale-p.iva-rea - No one calls a mobile phone "Dispositivo mobile", we already translate it as the more common "Cellulare" even in the same file Task [link](https://www.odoo.com/web#model=project.task&id=3263708) task-3263708
This fix resolves a problem where removing a background image from a text snippet would cause the save operation to fail. When background image options were being applied immediately upon modification, they weren't being properly cleaned up when the background was removed, leading to save errors. This update ensures that all associated options are cleared when a background image is removed.
Original PR description
Since [1] when options on background images have been applied as soon as they were modified instead of on save, those options were not reset when the background was removed. This commit removes those options when the background image is removed. Steps to reproduce: - Drop a Text snippet. - Add a background image. - Remove the background image. - Save. => Save failed. [1]: https://github.com/odoo/odoo/commit/4a797f51ec9d3d378fc30033e4fda2bc1e73586c task-3794812 Forward-Port-Of: odoo/odoo#157414
This fix resolves an error that occurred when viewing project updates after creating a purchase order with multiple analytic distributions. The system was looking for analytic account information in the wrong format, causing the project profitability view to crash. The fix updates how the system retrieves this information to match the current data structure.
Original PR description
### Steps to reproduce issue: 1. Create a Project with an Analytic Account and ensure it is Billable 2. Create a Purchase Order and add a Product 3. Add an Analytic Distribution to the Product with,…
### Steps to reproduce issue: 1. Create a Project with an Analytic Account and ensure it is Billable 2. Create a Purchase Order and add a Product 3. Add an Analytic Distribution to the Product with, on one line, the Project Account and an Account from another Plan 4. Confirm the Purchase Order 5. Open the Project's Updates 6. You get the error : > analytic_contribution = pol_read['analytic_distribution'][str(self.analytic_account_id.id)] / 100. > KeyError: '[int]' ### Explanation: This issue is related to odoo@73fa88c44ae64b2fc93ef1233f1ab8f8dbe2b0cc: the IDs are now stored in a csv string instead of separate values to allow for cross-analytics. In this case, `self.analytic_account_id.id` is not a key but part of a key. The line causing the issue was overlooked during the resolution of the previous one. ### Suggested fix: Similar lines have been fixed in the previous commit. Applying the same correction solves the issue. https://github.com/odoo/odoo/commit/73fa88c44ae64b2fc93ef1233f1ab8f8dbe2b0cc#diff-7af98465d7e344b935b9f2327a30b2da17a4df73d64bfee5b9b7a497362083e7L48-R59 https://github.com/odoo/odoo/commit/73fa88c44ae64b2fc93ef1233f1ab8f8dbe2b0cc#diff-2f1670bdaecbb290806818cc80aff338e2f956d89f3a71f6c2ed1b9805795fd3L575-R600 opw-3773509
This fix resolves an issue where tables would incorrectly expand adjacent rows or columns when cells were resized and then deleted. Tables now properly adjust their dimensions without preserving unnecessary height and width constraints, providing a more intuitive editing experience when working with table layouts.
Original PR description
**Current behavior before PR:** When you increase the height or width of cells in a table and subsequently delete a row or column, the adjacent rows or columns experience an increase in their height or width. This happens because the table preserves its overall dimensions even after resizing individual cells. **Desired behavior after PR is merged:** Now, the table no longer preserves its height or width. When resizing the table, the height or width of its rows or columns does not increase. task-3636212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146091
This fix corrects incorrect negative values appearing in Blocks F and G of the Swedish tax report. When creating vendor bills with Swedish input tax (Ingående moms), the reported amounts were showing as negative. The issue has been resolved by correcting the tax calculation formulas to properly reflect the intended values.
Original PR description
Steps to repreduce: - with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` tax - Reporting > Tax report **The values of Block F and G…
Steps to repreduce: - with SE Company: - Accounting > Vendor > Bills - Create and confirm a vendor bill with any of the `Ingående moms` tax - Reporting > Tax report **The values of Block F and G appears in negative** Cause of the issue: - The erroneous values come from the `se_48` formula of the `account_tax_report_data` which provides minus the value it should: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_report_data.xml#L374 This is due to the fact that the `plus_report_expression_ids` and the `minus_report_expression_ids` refering to the `tax_report_line_48_tag` are swapped on all purchase taxes, as suggested by the other report expressions in that file e.g. https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/l10n_se/data/account_tax_template.xml#L361-L366 Fix: - We swap back these references for all tax tags on puchases taxes. opw-3750771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158097 Forward-Port-Of: odoo/odoo#155744
This fix resolves translation problems where account names and journal names were not properly translated when installing localizations or switching languages. Previously, these records would only display in the language that was active during installation. Now, translations are correctly applied across all active languages, ensuring users see account and journal names in their preferred language.
Original PR description
There are currently translation issues related to the chart template. Due to this the names of some records do not receive the necessary / intended translations when installing a localization or new…
There are currently translation issues related to the chart template.
Due to this the names of some records do not receive the necessary
/ intended translations when installing a localization or new language.
When installing a new localization / chart some records have the following
problem with the values of their translatabe fields:
They are only installed in the language that was active when the localization / chart was installed.
Thus when switching languages (or using a different user with a different language)
the names are displayed in the "installation language".
Translations for all active languages should be installed (for all relevant records).
The same problem happens when installing a new language
(the same records do not receive a translation for the new language).
The translation issue concerns for example (some) accounts and journals;
see the (incomplete) list at the end of this message.
This commit tries to fix the translation issue for the translatable
fields of all relevant models.
Note!
=====
* The translation mechanism only works for records with xmlid.
If a module creates a record without xmlid it will not be translated.
* The problem is only fixed for records with xmlid for which at least 1 of the
following conditions holds:
* The record (and the translatable field value) is defined in
the body of the function decorated with 'https://github.com/template'
* The translation of the value of the translatable field can
be found in the module 'account' or in the module that
is associated with the record (by 'ir.model.data')
I.e. the problem is not solved for demo data: It is technically
difficult to determine the module they originate from.
This makes it difficult to load the right code translation (the
module information is needed for this).
* The translation mechanism is not necessarily triggered
if the record is (in principal) part of the chart template
but not installed as part of the chart template.
This can i.e. happen if a module is installed after the
localization / chart.
* Example: account.journal "Salaries" from hr_payroll_account
* We also want to "translate" / localize some untranslatable fields
(like account journal codes). For these fields the terms will be
installed in the language of the partner of the company for which
the chart will be installed (fallback to lang / user lang from the
env in case there is none set)
* Currently there is no language set for many (all?) demo comany.
Thus the values will remain in English for them (when the
respective module is installed).
Examples / Details
==================
**Reproduce**:
1. Switch to the French language (install if needed)
(Settings App > General Settings > Languages)
2. Install a localisation (e.g. l10n_fr).
3. Check the French translations of the localization
* Comptabilité > Configuration (Menu) > Journaux
(Accounting > Configuration (Menu) > Journals)
* Here the journal names are in French
* Comptabilité > Configuration (Menu) > Plan comptable
(Accounting > Configuration (Menu) > Chart of Accounts)
* All the account names are in French
4. Switch to English on the current user (or some other language)
via the user profile on the top right.
5. Check the names of the localization again
* Accounting
* The journal names are still in French
* Accounting > Configuration (Menu) > Chart of Accounts
* Some of the account names are still in French
* E.g. "Compte d'attente de la banque" ("Bank Suspense Account")
Other things to test:
* "Salaries" journal from enterprise module 'hr_payroll_account'
* Not demo data; it will (partly) work after this commit (see "Note" above)
* "IFRS Automatic transfers" journal from enterprise module
'account_auto_transfer' (installed when installing l10n_fr)
* Demo data; the problem remains after this commit
**Technically** the main problems are the following:
1. The information of some of the created records is only defined in
the code. Thus their translations have to be taken from the
translation of the code.
But at the point of translation it is not clear from which
module the data came from. This is needed to load the right translation.
* This was fixed for data from 'https://github.com/template' functions
2. Some records are created without an xmlid and thus
cannot be translated with the current translation mechanism at all.
* This was fixed for the relevant records from module 'account'
Example Records
---------------
Some affected **accounts**:
* from module 'account'
* Bank utility accounts
* Bank Suspense Account
* Outstanding Receipts
* Outstanding Payments
* Cash Discount Loss
* Cash Discount Gain
* Cash Difference Loss
* Cash Difference Gain
* Liquidity Transfer
* Bank / Cash journal default accounts
* Bank
* Cash
* Unaffected earnings account
* Undistributed Profits/Losses
Some affected **journals**
* from module 'account'
* Customer Invoices
* Vendor Bills
* Miscellaneuos Operations
* Exchange Difference
* Cash Basis Taxes
* Bank
* Cash
* from module 'account_auto_transfer' (enterprise)
* IFRS Automatic Transfers
* The problem will remain since it is demo data
* from module 'hr_payroll_account' (enterprise)
* Salaries
* The translation is only loaded if the module is installed
before the localization / chart
task info
=========
task-3414329
Forward-Port-Of: odoo/odoo#158174
Forward-Port-Of: odoo/odoo#137592Fixed an issue where users with timesheet access but no HR permissions would encounter errors when searching for employees in the dashboard. The system now properly displays the public employee search view for users without full HR access rights, preventing crashes and improving user experience.
Original PR description
Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this…
Purpose of this commit: Currently, people having access to different dashboards without any access rights would end up with a traceback when trying to search more employees. Steps to reproduce this issue: - have a user with timesheet officer rights and no hr rights - log in with that user account - go on the dashboard app and select "Timesheets" - go on employee filter and click on "search more" Current behaviour: A traceback is displayed because the user has no access to the view Expected behaviour: The public employee search view should be displayed How the issue was fixed: The method called `_get_views` has been overriden in the `hr.employee` model to return the `hr.employee.public` views instead if the user doesn't have the appropriate access rights. As there was no way through the dashboard to define a relation, the method explicitely takes the result for the public employee and sets it as result of the private one as well. Forward-Port-Of: odoo/odoo#158096 Forward-Port-Of: odoo/odoo#155739
This update adjusts how the system logs certain asset-related issues. Instead of marking them as errors, the system now logs them as warnings, which better reflects that these are not actual problems with the codebase but rather expected situations that should be tracked differently. This helps reduce noise in error monitoring systems and provides clearer visibility into actual system problems.
Original PR description
Currently, log level error mesage occur when`ValueError` is catched by line [1]. This commit changes 'logger.error' to 'logger.warning' with filename to log message instead of error since this is not an actual error of the codebase. [1]-https://github.com/odoo/odoo/blob/3932c46f914c40be4b0629771d1981cdf289df26/addons/web/controllers/binary.py#L131 sentry-4657682601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the system from getting stuck in an infinite loop when a scheduled task (cron job) is configured with an invalid interval setting of 0. The system now disables the problematic task and shows a warning message to users, preventing system hangs and improving stability.
Original PR description
Create a cron with an `interval_number` of 0 and change its nextcall so that it is called soon. When the cron gets executed, the cron worker enters an infinite loop during the computation of the next nextcall. The cron now gets disabled with an error message. On the form view, users now get a warning when `interval_number` is invalid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158122 Forward-Port-Of: odoo/odoo#144717
This fix resolves an issue where text in project views was being translated twice, resulting in incorrect language display. For example, in Dutch, "Tasks" was being translated to "Taken" by the system, then incorrectly translated again to "Genomen". The fix prevents this double translation by disabling the translation layer in the view template, since the text is already translated when the view loads.
Original PR description
Steps to reproduce ================== In 17: - Install hr_holidays,project - Switch the language to dutch - Go to project > three dots > Projectupdates We can see `x/y Genomen`, it should be `x/y Taken` Cause of the issue ================== The original term is Tasks. When loading the views, python translates them and changes Tasks to Taken. Owl then translates the template and transforms Taken to Genomen. Solution ======== Since the views are already translated, we don't need to translate them with owl. We can simply set the attribute t-translation to off on the view root node. opw-3787336 Forward-Port-Of: odoo/odoo#158444 Forward-Port-Of: odoo/odoo#158278
This update prevents users from accidentally deleting critical accounting PDF reports that are essential for the system's basic financial operations. By protecting these master data files, the change ensures that accounting workflows continue to function properly and reduces support issues caused by users removing reports they shouldn't delete.
Original PR description
Those master data would break the basic accounting pdf generation flow as those are widely used and it is not expected from end users to delete them. Example of support ticket from that issue: 3790875 TaskID: 3802440 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#158403 Forward-Port-Of: odoo/odoo#158080
This fix prevents users from accidentally deleting the Deliveries product category, which is essential for all shipping carriers. When this category was deleted, users couldn't install or use any delivery carriers, causing significant operational issues. The system now protects this critical category from deletion.
Original PR description
Purpose ======= Lots of tickets are issues when the end user deleted this product category, leading to the impossibility to install another carrier as this category is referenced by all the specific carriers products Ticket example: 3789116 TaskID: 3802440 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#158420 Forward-Port-Of: odoo/odoo#158084
A translation error in the Norwegian language file was preventing sales email templates from being rendered properly. This fix corrects the mistranslated code portion in the Norwegian translation, restoring the ability to send sales emails to customers.
Original PR description
Issue ----- The sale mail template is not rendered because a part of code is translated. **opw-3809578**
This update corrects tax classifications in the German accounting system (SKR03 and SKR04 charts of accounts). Several taxes were incorrectly assigned to the wrong tax groups, which has now been fixed to ensure proper tax categorization and compliance with German accounting standards.
Original PR description
Some taxes of skr03 and skr04 were not set for the appropriate tax group. This was fixed, and each tax was set to its appropriate tax group. Taxes should not be set with wrong tax groups. task-3800915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158555 Forward-Port-Of: odoo/odoo#158034
This fix resolves an issue where the Company ID field was appearing twice or disappearing entirely when both Czech and Slovak localization modules were installed in a multi-company setup. The fix ensures the Company ID field displays correctly regardless of which country's localization is active, improving the consistency and usability of the Contacts form across different company locations.
Original PR description
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which…
Current state: - Company ID field in the Contacts form view is introduced by the base module and it is put into the Purchase tab. - l10n_cz module adds an invisibility attribute to that field which hides it if the current company is not based in CZ. It also adds another instance of the field into the main tab but also adds the same invisibility attribute for the field. - If l10n_sk module is installed next (e.g. in a multicompany setup) it adds another instance of the field into the main tab but changes the visibility attribute of all the instances suit SK-based companies. However this means the field becomes hidden for CZ-based companies (current company). Plus the field is doubled if the current company is a SK-based one. - A similar problem happens if the l10n_sk is installed first and l10n_cz comes after it. Fix: - Remove the invisible attribute so that the Company ID field on the main tab and on Sales and Purchase tab remains untouched and visible whatever the current company's country is.
This update refreshes the X/Twitter logo throughout the Odoo platform to reflect the new design. The change affects visual elements in the web interface, website builder, and mass mailing features, ensuring consistent branding across all user-facing components.
Original PR description
*: website, website_twitter This commit introduces an update to the Font Awesome library, specifically replacing the X/Twitter icon with its new design. It also involves adjustments to a few images and SVG files to incorporate the updated X/Twitter logo. Technical note: It updates an existing file, originally modified for the addition of the TikTok icon, which was not available in Font Awesome 4. Related to: https://github.com/odoo/enterprise/pull/53644 task-3463530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158454 Forward-Port-Of: odoo/odoo#148126
Fixed a bug that caused the system to crash when users entered a valid VAT number while creating a new contact. The issue occurred because the system was looking for address information in the wrong location. This fix improves the reliability of the contact creation process when using VAT number validation.
Original PR description
This issue is occurring when the user tries to add a `VAT` number, while creating a new contact To reproduce this issue: 1) Install `contacts` and `partner_autocomplete` 2) Create a new contact from…
This issue is occurring when the user tries to add a `VAT` number,
while creating a new contact
To reproduce this issue:
1) Install `contacts` and `partner_autocomplete`
2) Create a new contact from `Contacts`
3) Give a valid `VAT` number e.g:- `SK2120312645`(got it from sentry)
4) Traceback occurs in the terminal
Error:-
```
IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/partner_autocomplete/models/res_partner.py", line 158, in read_by_vat
'city': zip_city[1],
```
In some cases, the expected `zip_city` value is not at the last of the address list ,
which leads to above traceback. As `zip_city` must contain both zip and city values.
https://github.com/odoo/odoo/blob/382b64c2f14073cfff1a8ef9290b5c7834d52188/addons/partner_autocomplete/models/res_partner.py#L143-L156
After applying this commit will resolve this issue by searching `zip_city` based on regex.
sentry-5058467547
Forward-Port-Of: odoo/odoo#158368
Forward-Port-Of: odoo/odoo#157697This update fixes several issues with the website header menu on tablet-sized screens. The header now correctly treats tablet screens (MD breakpoint) as mobile devices, which prevents menus from getting stuck open when resizing, restores page scrolling functionality, and ensures consistent menu behavior across all screen sizes. This resolves user experience problems where menus would malfunction or become unresponsive on tablet devices.
Original PR description
Before this commit, the header was considered as mobile at the `SM` screen breakpoint, while it is already displayed as in mobile view at `MD`. This made some of the header behaviors inconsistent and…
Before this commit, the header was considered as mobile at the `SM`
screen breakpoint, while it is already displayed as in mobile view at
`MD`. This made some of the header behaviors inconsistent and caused
some issues:
1) A menu open at `MD` is not closed when resizing the screen:
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
- Resize back at `MD`.
=> The menu was not closed. It is when we start resizing at `SM`, which
is inconsistent as they are both displayed like in mobile view.
2) Because of the first issue, we cannot scroll the page anymore after
opening the menu at `MD`:
- In edit mode, drop enough snippets to have a scrollbar and then save.
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
=> There is no scrollbar anymore and we cannot scroll.
This happens since PR [1], which redesigned the headers and changed the
"hambuger" menus so they open on the side (= offcanvas), and commit [2]
that prevented the `#wrapwrap` to scroll when these menus are open, to
prevent a bug on Safari. The issue happens because since the menu does
not close when resized, the class preventing the `#wrapwrap` to scroll
is never removed.
3) The menus are hoverable at `MD` but not at `SM`:
- Add sub-menus and mega menus with the menu editor.
- In edit mode, set the menus as hoverable (set the "Sub Menus" option
to "On Hover") and save.
- Hover the menus:
- above `LG` (= desktop view) => they open.
- under `SM` (= mobile view) => they do not open because we need to
click to open them on mobile view.
- between `SM` and `LG` => they open even though it is displayed like
in mobile view, so the behaviors are inconsistent.
4) Because of the third issue, there is sometimes a traceback when
hovering mega menus if the screen is at `MD`:
- Resize the screen at `MD`.
- Refresh.
- Open the menu and hover a mega menu dropdown.
=> There is a traceback sometimes.
Since commit [3], in order to avoid mega menu synchronization issues
between the desktop and mobile headers, the mega menus are not
duplicated anymore and they are moved from one navbar to the other when
opening them, so when hovering them if the menus are hoverable. A race
condition can happen in that case because the `hoverableDropdown` widget
tries to open the mega menu before the menu has been moved in its
dropdown, which causes a traceback. This seems to happen only when the
widgets start with the screen at `MD`, therefore, preventing the menus
to open on hover under `LG` prevents this race condition.
This commit considers the header as mobile under the `LG` screen
breakpoint, to fix these issues and to uniformize the behaviors of the
mobile header.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/389856bcd94d459d72f46c2a517afb3f6d976e38
task-3801970
Forward-Port-Of: odoo/odoo#158334
Forward-Port-Of: odoo/odoo#157601This fix resolves an access error that occurred when users of branch companies tried to create products. The system was incorrectly attempting to access default tax settings from the parent company, which the user didn't have permission to view. Now the system properly respects company access restrictions when retrieving tax information for products.
Original PR description
Steps to reproduce: - Install Invoicing (and Sales for product creation rights) - From a company, create a Branch company - Switch to parent company - In Invoicing settings of parent company, set default taxes - Switch to branch company - In Invoicing settings of branch company, set no default taxes - Create a user with only the branch company as allowed companies - Give the user the right to create a product (e.g. Sales: Administrator) - Connect with the created user - Try to create a product Issue: An Access Error is raised due to "company rule employee" rule because the system tries to fetch the default taxes from the parent company, which is not activated in the company selector. opw-3790360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157565
This fix corrects an issue where credit notes (refunds) in the purchase portal were incorrectly showing a "Waiting Payment" status badge instead of "Paid". When a full refund is issued through the "Add credit note" feature, the payment status now displays correctly as paid, improving clarity for users reviewing their purchase transactions.
Original PR description
- Create PO - Confirm, delivery and create bill - Confirm and create reverse move via "Add credit note" (Full Refund) - Open portal view of the PO Issue: The credit note payment status display `Waiting Payment` badge instead of `Paid` opw-3806514 Forward-Port-Of: odoo/odoo#158405 Forward-Port-Of: odoo/odoo#158108
This update fixes how the system handles errors when a participant is not ready on the Peppol network. Previously, users would see confusing error messages when trying to send invoices through an inactive participant account. The fix also improves test reliability by properly mocking external Peppol network requests, ensuring all tests run correctly instead of being skipped.
Original PR description
### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages. ### [FIX] account_peppol: mock external request Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154926
Fixed an issue where pressing Ctrl+Z in the code editor would incorrectly undo the initial content that was loaded, even though no actual changes were made. The fix ensures that the initial value is properly preserved and only real user edits can be undone, improving the user experience when working with code fields.
Original PR description
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor. Press Ctrl+Z. Before this commit, the value disappears -- is undone -- even…
Open the code editor (wrapper around aceEditor) with an initial value -- in Odoo, that is any instance of the code editor. Press Ctrl+Z.
Before this commit, the value disappears -- is undone -- even though no real change happened. This was because we used editor.setValue, instead of editor.session.setValue. The latter resetting the undo history.
This behavior is "documented" [here: Common Operations](https://ace.c9.io/#nav=howto) () with:
```js
//Set and get content:
editor.setValue("the new text here");
editor.setValue("text2", -1); // set value and move cursor to the start of the text
editor.session.setValue("the new text here"); // set value and reset undo history
editor.getValue(); // or session.getValue
```
After this commit, the initial value is not undoable.
opw-3793546
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#158417
Forward-Port-Of: odoo/odoo#158279This fix corrects how UTM tracking cookies are classified in the website cookie settings. Previously, UTM cookies were incorrectly marked as required, causing them to be set even when users selected "Only Essentials" in the cookie banner. Now they are properly treated as optional, respecting user privacy preferences and ensuring content visibility rules work correctly based on actual user consent.
Original PR description
Those are optional, commit [1] mimicked the python code in JS but with a mistake: "required" instead of "optional". Steps to reproduce: - Enable cookies setting on website - Drag & drop a snippet - Modify that snippet conditional visibility to "Utm Campaign: Sale" - Visit in incognito /?utm_campaign=Sale, you don't see the snippet, which is good - Now click on "Only Essentials" in the cookies banner - The snippet will be shown, because when accepting the essentials cookies, the utm ones were set, since they were marked as required. [1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eec Forward-Port-Of: odoo/odoo#158590
This update fixes an issue where major Brazilian banks (Itaú, Santander, and Caixa) were unable to process Pix payment codes that lacked a reference field. The system now automatically adds a dummy reference ("***") when none is provided, matching the standard behavior of Santander bank and ensuring compatibility across all supported financial institutions.
Original PR description
Many banks (Itaú, Santander, Caixa) don't support Pix codes without a reference. To fix set a dummy reference of "***" when none is set (this is what Santander bank does when generating Pix codes without a reference). Again thanks to INGO for testing. opw-3818534
This fix ensures that the city field (city_id) is properly synchronized from parent contacts to child contacts, just like other address fields. This is important for businesses in Colombia and Mexico that rely on the city_id field to generate electronic invoices from child contact records.
Original PR description
Steps to reproduce: - Install contacts and base_address_extended - Install a module adding "res.city" records (e.g. l10n_co_edi) - Go to Contacts and create a new one: * Name: [any] * Country:…
Steps to reproduce:
- Install contacts and base_address_extended
- Install a module adding "res.city" records (e.g. l10n_co_edi)
- Go to Contacts and create a new one:
* Name: [any]
* Country: Colombia
* City (city_id): [any]
- Create a "child" contact of "Contact" type
- Save the contact
Issue:
"city_id" field of the child contact is False.
It is not possible to set the address of a contact-type contact manually. Some address fields ('street', 'street2', 'zip', 'city', 'state_id', 'country_id') are synchronized with the parent contact.
"city_id" is not and is not settable at all for contact-type contact. It could be an issue for Colombian or Mexican localizations if a child contact is used for an invoice as some data have to be retrieved from "city_id" field to generate the electronic invoice.
Solution:
Add "city_id" in the list of address fields to sync.
opw-3747296
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156922This fix resolves an issue where users encountered an error when trying to customize the Community page in an event. The problem was caused by a missing function that was removed in a previous update. The fix updates the code to retrieve necessary data in a way that's consistent with how other parts of the system work, allowing users to successfully customize their event community pages again.
Original PR description
**Steps to reproduce:** - Open an event and go to the Community page - Try to customize it => traceback on clicking the 'Customize' tab. **Cause:** The `_getRpcData` function called by '_computeWidgetState' method does not exist anymore since https://github.com/odoo/odoo/commit/03c5526 **Fix:** This PR eliminates the call to the `_getRpcData` function and alters the code of 'options.js' to get rpcData for the 'allow room creation' checkbox, through an implementation similar to that of 'website menu'. Task: [3805901](https://www.odoo.com/web#id=3805901&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#157831
This fix resolves an issue where the helpdesk module was causing blog performance tests to fail in the enterprise version. The helpdesk module adds a menu with a special URL format that disables website menu caching, which then causes blog performance tests to run slower than expected. This change prevents the helpdesk module from negatively impacting blog performance measurements.
Original PR description
Commit [1] was introduced to fix an issue where the website menu cache is incompatible with having a slug url in one of its menu. But in the enterprise build, since the website_helpdesk module is adding one menu containing a slug url, it would disable the menu cache. Unfortunately, the website_blog perf tests (at_install) are executed after website_helpdesk is installed, meaning that in enterprise, the perf test of website_blog would fail since it would require some more SQL Queries (1 or 2 depending of the test) to render a blog post as it would have to query the website.menu table. It's still unclear how commit [1] was merged in the codebase since the enterprise staging should have failed. runbot-60466 runbot-60467 [1]: https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20 Forward-Port-Of: odoo/odoo#158533
This fix resolves an issue where canceling a sales order line with multi-step warehouse routes and the "cancel next move" feature enabled would unexpectedly create additional pickings. The fix prevents cancellation from propagating to related stock moves when they are being merged, ensuring the order fulfillment process works correctly without creating duplicate or erroneous shipments.
Original PR description
If the 'cancel next move' feature is enabled, canceling a SOL could lead to unexpected picking creation To reproduce the issue: (Debug mode enabled) 1. In Settings, enable "Multi-Step Routes" 2. Edit…
If the 'cancel next move' feature is enabled, canceling a SOL could
lead to unexpected picking creation
To reproduce the issue:
(Debug mode enabled)
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Outgoing shipments: 2 steps
3. Edit the delivery route:
- For each rule:
- Cancel next move: True
4. Confirm a SO with one product
5. Set the SOL quantity to 0
Error: A third picking is created, from customer to output location
Step 4, it creates two SM:
\- SM_SO: from Stock to Ouput
\- SM_OC: from Output to Customer
Step 5, thanks to the procurement process, we create a stock move:
\- SM_OC_neg, from Output to Customer with a negative qty.
While confirming this SM, and thanks to the same process, we then
create a second stock move :
\- SM_SO_neg, from Stock to Output, with a negative qty.
Both negative SM are linked. While confirming SM_SO_neg, we merge it
with SM_SO. Therefore:
\- Dest moves of SM_SO_neg are given to SM_SO
\- SM_SO_neg is deleted (fully absorbed by SM_SO)
\- SM_SO has now a zero demand, so we cancel it:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1024-L1025
However, because of step 3, we also cancel its dest moves:
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1740-L1745
i.e., we cancel SM_OC *and* SM_OC_neg. This leads to an inconsistency:
Back to the confirmation of SM_SO_neg. As explained, this SM has
been canceled during the procurement process. Still, we keep
processing its confirmation (we overwrite its state, we assign it to a
picking, and so on). Hence the error.
In `_merge_moves`, when deleting a stock move, we first clean it
(for instance, we disable the cancel propagation):
https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1018-L1020
We should do the same with SMs we are going to cancel. That way, we
fix the root cause of the issue: when cancelling SM_SO, we don't
cancel neither SM_OC neither SM_OC_neg, so we don't have any
inconsistency when going back to the confirmation of SM_SO_neg, and
everything will work correctly.
OPW-3753453
Forward-Port-Of: odoo/odoo#158562This fix corrects an issue where canceling an invoice would incorrectly reassign its sequence number instead of keeping it unchanged. When an invoice is canceled, it now properly retains its original sequence number, ensuring accurate financial record tracking and preventing gaps or duplicates in invoice numbering.
Original PR description
Steps to reproduce:
```
| Step | Move | Action | Date | Name |
| ---- | ---- | ----------- | ---------- | ----------- |
| 1 | `A` | Add | 2023-02-01 | `2023/02/0001` |
| 2 | `B` | Add | 2023-02-02 | `/` |
| 3 | `B` | Post | 2023-02-02 | `2023/02/0002` |
| 4 | `A` | Cancel | 2023-02-01 | `2023/02/0003` | -> Wrong
```
Issue:
The first invoice should keep its sequence to 1
opw-3757022
Forward-Port-Of: odoo/odoo#158435
Forward-Port-Of: odoo/odoo#156865This update corrects translation references in the Italian EDI website sales module that were broken after a previous fix was merged. The changes ensure that translated terms display correctly for Italian users in the e-commerce system.
Original PR description
After the fw-port of the fix in [1], it seems some references had changed, breaking the translations again. This commit fixes that. [1] 9d2f7f312c5d699b937bd5546085fc151a149a8f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158557
This fix addresses an issue where purchase orders created through manual replenishment would show a price of 0 when the product's pricelist had expired. Now the system will use the product's standard price as a fallback when no valid pricelist is available, ensuring accurate pricing on purchase orders.
Original PR description
Steps to reproduce: - Create pricelist with an end date in the past for a stored product - Click on manual replenishement - The created PO will have a price of 0 Bug: if no valid pricelist is found unit price is set to 0 product standard price is a better fallback opw-3692985 Forward-Port-Of: odoo/odoo#158205 Forward-Port-Of: odoo/odoo#157023
This update removes unnecessary warning alerts that appeared when viewing posted invoices or bills with archived currencies. The alert will now only display for draft documents, preventing confusion when reviewing finalized transactions that cannot be edited.
Original PR description
Steps to reproduce: * Activate multi-currency (Company currency `USD`, another currency activated 'EUR') * Create invoice/bill in `EUR` and post it * Archive `EUR` * Open Invoice/Bill Issue: * Alert for inactivated currency is always displayed Fix: * Alert for inactivated currency should be displayed in draft state only 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#158639 Forward-Port-Of: odoo/odoo#98341
This fix corrects how product valuation costs are calculated when processing partial kit orders with backorders. Previously, the system was incorrectly calculating costs based on the full order quantity instead of just the confirmed quantity, resulting in inflated valuation totals. The fix ensures costs are calculated based on actual component quantities received.
Original PR description
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca Issue: ====== valuation unit cost is wrong when we do backorder with real time unit…
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca Issue: ====== valuation unit cost is wrong when we do backorder with real time unit price computation Steps to reproduce the issue: ============================= - Create a kit with 2 components with product quntity to produce = 3 - Put qty = 2 for the first component and qty = 1 for the second component - Assign product category to the kit product and the components as fifo one with automatec price computation - Create a purchase order with 30 quantity of the kit and price unit = 90 - confirm order and go to receipt - Confirm 4 qty for the first component and 2 qty for the second. - Create backorder - Go to the confirmed receipt and go to valuation - You will see that the total sum corresponds to the price of all the products and not only the confirmed ones. Solution: ========= We need to use the bom quantities and not the order line to get the unit_cost of each component. opw-3790132 Forward-Port-Of: odoo/odoo#158592 Forward-Port-Of: odoo/odoo#158072
This update fixes an issue where tax information was wrapping onto multiple lines on PDF documents like invoices, purchase orders, and expense reports. The fix prevents text wrapping for tax amounts when they are short enough to fit on one line, improving the readability and professional appearance of printed documents.
Original PR description
Before this commit, it happens that the taxes display on the pdf were wrap, specially when the description in the pdf were too long. This commit will add a text-nowrap on the taxes when the len of the taxes is shorter than 10 characters. task: 3754824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158576 Forward-Port-Of: odoo/odoo#154709
A recent update to the picking types system accidentally skipped connecting the print label feature to its field. This fix restores the automatic print label setting so that picking types will correctly display and apply label printing preferences as intended.
Original PR description
In a1f32fafa85b300e2d656a57797b8dbde6e3f065, various onchanges from the picking types were changed into computes. However, the compute for the `print_label` field was forgotten and never linked to its field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr