Daily updates from Odoo
Navigate
Branch
Thursday, February 1, 2024
74 changes
18 changes
Enhancements to existing features
Warehouse teams can now decide whether barcode users may add unreserved products during picking operations. Batch picking can also group similar product lines together, helping pickers work faster when handling batches for the same destination.
Original PR description
This PR adds two fields on `stock.picking.type`: - `barcode_allow_extra_product`: True by default, when it's disabled it prevents to add unreserved product while processing an operation in the Barcode App; - `group_lines_by_product`: False by default, when active batch pickings will group move lines if they have the same product (and source/destination in case multi-locations is enabled), like we already do for tracked product. Task-3650361
Smart scheduling now prioritizes tasks that have deadlines and schedules earlier-deadline tasks first. This helps teams focus on time-sensitive work and creates a more practical schedule without relying on project grouping details.
Original PR description
When smart scheduling, prioritize tasks with a deadline over no deadline, then tasks with a shorter deadline over longer ones. Don't group by project (not possible anymore + not very useful) to get the tz, calendar and company. Rather, take the one of the user, or the project you're in the context of, or the env. task-3349377
The planning calendar now shows more complete information on employee schedule entries, including project, sales order, sales line, and allocated hours where relevant. This makes the calendar easier to read and helps managers understand planned work without opening each entry.
Original PR description
Before this commit: -in title sale line name was showing but sale order name was not -if sale line id and project both available then only sale line show and project was not showing -after time event allocated hours was not showing Imp after this commit: -improved the _planning_get method to enhance the display of employee slots in the calendar view. improved event title by incorporating project and sale information -displaying allocated hours alongside event times in the calendar -created dynamic elements to display allocated hours within event time entries. -these changes aim to improve the overall user experience and readability of the calendar view while providing valuable information task-3502106
A new automated check verifies that document details, such as the document name and customer, are correctly carried over when related tasks are created. This helps reduce the risk of task records missing important context for project teams.
Original PR description
This commit will add a test to check that the name and the partner of the document is propagated to its tasks on creation. task-3231698
Financial reports now format values only after the final visible lines are known, avoiding unnecessary work on large reports and improving load times. Integer rounding is also available more consistently across standard and custom dynamic reports, making report presentation easier to control.
Original PR description
[IMP] account_reports: Delayed formatting of values When displaying a report, all the values need to be formatted in order to display the right number of decimal places, currency symbols, ... So far,…
[IMP] account_reports: Delayed formatting of values
When displaying a report, all the values need to be formatted in order to display the right number of decimal places, currency symbols, ...
So far, this was done line by line, before prefix groups were possibly applied. On very big reports needing to be trimmed by a prefix group setup, this was a bit stupid, since we formatted all the values, then decided whether to show them or not (then replacing them with prefix lines). In extreme cases (a few thousands of lines), this could even end up with the report taking entire seconds to just format values uselessly.
This commit gets rid of this behavior, and instead does the formatting after generating the lines, when we're sure they need to be displayed.
--------------------------------
[IMP] {account,l10n_fr,l10n_nl}_reports: generalize integer rounding to dynamic lines
The integer rounding feature was only available on reports computed from expressions so far, not on custom reports relying on dynamic lines. This was due to the fact this feature had to be introduced in stable, and further refactoring was needed in order to make it work for real.
Now that the formatting of the values has been delayed for all lines (static and dynamic) to the end of the _get_lines, we can add support for integer rounding after the generation of dynamic lines. Since the feature is now available on every report, we also make the integer rounding feature a "real" option, with a field controlling it on the report, and a proper _init_options function.
---------------------------------
Task 3059062Planning shifts are changed to represent the exact working periods rather than broad multi-day blocks that are later adjusted against schedules. This makes planning clearer and overlap checks more reliable, with a new split option to turn long shifts into schedule-based working segments.
Original PR description
Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time.…
Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time. Typically, 40h. In my opinion, a planning app should be used to know exactly when you will be working on what. So, in an overall functional perspective, it doesn't make a lot of sense to have a 168h long shift when you work 40h a week. Now, from a technical perspective, I also think the current state complexifies the code. Say that you want to check if 2 shifts are overlapping (which, obviously, is one of the main questions you ask yourself when planning) -for now, let's forget about `allocated_percentage`. In theory, it should be trivial. However, when the start/end to consider is in fact the start/end of the work interval that is inside the shift (let alone the lunch break), what could have required 1 LOC now requires to search in other tables, asking again, essentially, "when is the resource actually working?". And if you have to do it in a SQL query (see `_compute_overlap_slot_count`), well you just don't because it is too complex, and you end up with an uncorrect result. The same question is asked and answered not very elegantly when trying to assign shifts automatically (see `auto_plan_ids`). My sense is that we should keep it simple and stupid: `allocated_hours = (end_datetime-start_datetime) * allocated_percentage` Now, in order not to force the user to create 10 shifts for a week where is used to only create one of them, I suggest adding a button "scissors" on the from view that instead of saving one big shift, would fragment it once and for all into the 10 desired shifts, taking into account the resource's schedule. Technical downsides: - (Way) more records in DB. Functional downsides: - I think Odoo consultants are used to creating, say, 3 one-week shifts whose sum of percentages is 100%. With this commit, their gantt view will be clogged with 6 shifts per day. But again, my point is: it doesn't sound like the proper way to use a planning app. - If you have a one week shift, and you fall sick on tuesday, we now have to reassign all the following shft, rather than splitting it and reassigning the 2nd part. task-?
Resolved issues and error corrections
Sample data styling is now applied more consistently in cohort and Gantt-style planning views. This prevents visual styling from affecting unrelated buttons and makes empty or sample screens clearer for users.
Original PR description
This commit corrects how the sample data styling is applied to the cohort view by removing a duplicate rule and make it so that the styling only concerns the table and not the view buttons. related to https://github.com/odoo/odoo/pull/148138 task-3650135
Website cards such as appointment or event cards can no longer be edited directly by visitors or editors when they should be locked. This prevents unintended changes to card content and keeps published website pages more stable.
Original PR description
Commit fixes the issue that allows people to write on cards (event card, appointment cards, etc) The class `o_editable` is automatically added to the card styles. In order to fix this I decided to add `o_not_editable` to the card styles, so that it prevents adding `o_editable`. task-3481761
Miscellaneous changes
This commit renames the l10n_dk_edi module name to avoid naming confusion between this module and the other DK edi modules. Forward-Port-Of: odoo/enterprise#55441
Original PR description
This commit renames the l10n_dk_edi module name to avoid naming confusion between this module and the other DK edi modules. Forward-Port-Of: odoo/enterprise#55441
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Add Budget' button - add some budget plan and switch to mobile Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 Forward-Port-Of: odoo/enterprise#55460 Forward-Port-Of: odoo/enterprise#52525
Original PR description
Steps to reproduce: - first install bridge module 'project_account_budget' - open any project and go to project updates - in right side panel you see 'Add Budget' button - add some budget plan and switch to mobile Issues: - heading of table are not vertically centered Solution: - Add style to vertically align center of heading Task: 3633405 Forward-Port-Of: odoo/enterprise#55460 Forward-Port-Of: odoo/enterprise#52525
Issue: ====== When having a product with duration variant and they have different temporal units, it will only display the temporal unit of the first selected variant in ecommerce product page. Steps to reproduce the issue: ============================== - Create a recurring product , add duration variant - Add pricing for each variant using different periods - Go to the product page in website and change the current variant , the temporal unit doesn't change. Origin of the issue: =
Original PR description
Issue: ====== When having a product with duration variant and they have different temporal units, it will only display the temporal unit of the first selected variant in ecommerce product page. Steps to reproduce the issue: ============================== - Create a recurring product , add duration variant - Add pricing for each variant using different periods - Go to the product page in website and change the current variant , the temporal unit doesn't change. Origin of the issue: ==================== It seems that the current code isn't reachable , and the function isn't updated. While debugging , this override of the function is never called but the website_sale_stock one is called. Solution: ========= I copied the same format of code done in website_sale_stock/static/src/js/variant_mixin.js and it solved the issue. opw-3618345 Forward-Port-Of: odoo/enterprise#52154
In the tour, we navigate from the registration form and then go back to it. Steps are done fast and the new registration form does not manage to be loaded (and/or old form is not unmounted) by the time the registration fields are filled from the tour steps. As a result registration form is not properly filled and final 'Check in' button fails. To fix this, we add step_delay when running the tour. Forward-Port-Of: odoo/enterprise#55346
Original PR description
In the tour, we navigate from the registration form and then go back to it. Steps are done fast and the new registration form does not manage to be loaded (and/or old form is not unmounted) by the time the registration fields are filled from the tour steps. As a result registration form is not properly filled and final 'Check in' button fails. To fix this, we add step_delay when running the tour. Forward-Port-Of: odoo/enterprise#55346
"l10n_fr_reports.account_financial_report_line_02_0_6_fr_bilan_passif_balance" doesn't exist for databases in 16.0 or higher, made or migrated after this [change](http://tinyurl.com/yrf8hf2r). Also, in some cases, it is being removed by the upgrade script, https://github.com/odoo/upgrade/pull/5358, which was reverted, but some databases were still able to migrate at that time; same problem for those databases as well. TBG-1042 upg-1247501, 1240637, 1203984, 1250604 Forward-Port-Of: o
Original PR description
"l10n_fr_reports.account_financial_report_line_02_0_6_fr_bilan_passif_balance" doesn't exist for databases in 16.0 or higher, made or migrated after this [change](http://tinyurl.com/yrf8hf2r). Also, in some cases, it is being removed by the upgrade script, https://github.com/odoo/upgrade/pull/5358, which was reverted, but some databases were still able to migrate at that time; same problem for those databases as well. TBG-1042 upg-1247501, 1240637, 1203984, 1250604 Forward-Port-Of: odoo/enterprise#55397
This commit resolves an issue where loading table orders would fail due to a refactor (commit: https://github.com/odoo/odoo/commit/01b3a2e4c24fe24bb7b8bb74fc6d2e2edaa96e87). The "l10n_de_fiskaly_time_start" field was correctly added in the 'export_for_ui' method. opw-3706454 Forward-Port-Of: odoo/enterprise#55423
Original PR description
This commit resolves an issue where loading table orders would fail due to a refactor (commit: https://github.com/odoo/odoo/commit/01b3a2e4c24fe24bb7b8bb74fc6d2e2edaa96e87). The "l10n_de_fiskaly_time_start" field was correctly added in the 'export_for_ui' method. opw-3706454 Forward-Port-Of: odoo/enterprise#55423
This reverts the commit: https://github.com/odoo/enterprise/commit/b67b9e432f2de936ab6c2c68e23cb8f0b2aca76d Purpose ======= The payroll payment file is rejected on Isabel platfrom due to a bank account that was outside of the European Union, because the BIC wasn't mentioned. The commit was originally made to avoid posting 'NOTPROVIDED' as BIC, which was rejected by some banks. Now, we skip if there is not BIC on the bank https://github.com/odoo/enterprise/blob/17.0/account_sepa/mod
Original PR description
This reverts the commit: https://github.com/odoo/enterprise/commit/b67b9e432f2de936ab6c2c68e23cb8f0b2aca76d Purpose ======= The payroll payment file is rejected on Isabel platfrom due to a bank account that was outside of the European Union, because the BIC wasn't mentioned. The commit was originally made to avoid posting 'NOTPROVIDED' as BIC, which was rejected by some banks. Now, we skip if there is not BIC on the bank https://github.com/odoo/enterprise/blob/17.0/account_sepa/models/account_journal.py#L336 It wasn't like that in the original version of that function; only got fixed recently: https://github.com/odoo/enterprise/commit/3c06ce695b80dec0c336ac2133594d9eaa07e3ba So, we can remove the context key in 16.4+. TaskID: 3710072 Forward-Port-Of: odoo/enterprise#55440
Forward-Port-Of: odoo/enterprise#55340
Original PR description
Forward-Port-Of: odoo/enterprise#55340
999001 and 999002 are no longer used for extraordinary income/expenses. This commit removes them from the domains of the corresponding report. Task ID: 3672294 Forward-Port-Of: odoo/enterprise#55081 Forward-Port-Of: odoo/enterprise#54491
Original PR description
999001 and 999002 are no longer used for extraordinary income/expenses. This commit removes them from the domains of the corresponding report. Task ID: 3672294 Forward-Port-Of: odoo/enterprise#55081 Forward-Port-Of: odoo/enterprise#54491
Before this PR: ----------------------------- - It is possible to add a step to an operation in the tablet view if it already has any steps, but it is not possible if it doesn't have any steps initially. After this PR: ----------------------------- - The issue has been resolved by adding a pop-up button that appears upon clicking for worksheet improvement. - If there are no steps initially assigned, the button will prompt the addition of steps. - If steps are already assigned, i
Original PR description
Before this PR: ----------------------------- - It is possible to add a step to an operation in the tablet view if it already has any steps, but it is not possible if it doesn't have any steps initially. After this PR: ----------------------------- - The issue has been resolved by adding a pop-up button that appears upon clicking for worksheet improvement. - If there are no steps initially assigned, the button will prompt the addition of steps. - If steps are already assigned, it will function as before. task_id : 3551582 Forward-Port-Of: odoo/enterprise#53742 Forward-Port-Of: odoo/enterprise#49703
56 changes
Security fixes and vulnerability patches
This update fixes a security vulnerability where HTML code submitted through website contact forms was being rendered as formatted text in emails instead of being treated as plain text. Now all form submissions are properly escaped to display HTML tags as regular text, preventing unintended formatting and potential security issues in received emails and job applications.
Original PR description
Description of the issue/feature this PR addresses: Escape HTML whenever a field is sent through email such as in the contact us form. Current behavior before PR: HTML was supported when an email was sent through the contact us form. Desired behavior after PR is merged: HTML is now escaped. Forward-Port-Of: odoo/odoo#151396 Forward-Port-Of: odoo/odoo#149968
New functionality added to Odoo
A new automated test workflow has been added to verify the manufacturing shopfloor process works correctly. This test validates the complete production order flow including creating orders with multiple operations, assigning workcenters and employees, and handling component management. This ensures the shopfloor functionality remains reliable as the system is updated.
Original PR description
The current flow: - Create a MO with 2 operations - Select the shopfloor workcenters - Use an employee - Do the steps for the first operation - Try the otpion on the second operation (move to another wc, add component) - Close the production order
Enhancements to existing features
This update significantly speeds up the confirmation process for large purchase orders in manufacturing operations. Previously, confirming orders with over 50 lines would take several minutes or timeout; now the same orders complete in seconds. The improvement optimizes how the system processes order data, making it practical for users to work with large orders containing hundreds of line items.
Original PR description
### Current behavior: Confirming a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client, they had PO with more than 200 lines which makes it impossible for them to confirm them. ### Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Try to confirm it - Take a long time or timeout ### Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 1s30 | 1s30 | | 91 | 1min | 16s | | 273 | 4min | 50s | | 405 | 4min30s | 1min6s | ### Fix: Batch more actions and records to reduce the number of queries generated by the ORM. opw-3625892 Forward-Port-Of: odoo/odoo#149383 Forward-Port-Of: odoo/odoo#146442
This update adds a helpful guide next to the visibility field in website pages to clarify how to restrict access by groups. Previously, when users selected "Restricted Groups" as the visibility option, there was no clear indication of where to specify which groups should have access. The improvement directs users to the groups field located in the Access Rights tab, making the feature more intuitive and reducing confusion.
Original PR description
Commit [1] introduced a way to "hide" an ir.ui.view through a new visibility field. That field has multiple possible values to restrict the access. One of those is "Restricted Groups", but when selected it's really hard to figure what to do next because nothing happens on screen: there is no "groups" field where to add the groups. Those groups should actually be added a bit below, in the groups_id field which is "hidden" inside the "Access Rights" second tab. This is because the groups_id field already existed (in base module) before introducing the website visibility feature which just relied on that field when set to "Restricted Groups". Note that another possible value for visibility is "Password", and in this case a password field appear below the visibility field as one would expect. [1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900c 
This update adds a new feature to the Point of Sale system that allows users to show or hide product and category images in the POS interface. Users can now toggle this setting on demand, giving them more control over the display layout and potentially improving performance or reducing visual clutter based on their preferences.
Original PR description
In this commit we add the ability to toggle between showing and not showing product and category images in the pos ui. Because this change is done in stable, we store the user's selection in `ir.config.parameter`. In the forward port, this will be removed and the settings will be stored in `pos.config` Task 3704416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds support for two missing payment statuses from Mercado Pago: "Authorized" (for bundle payments awaiting capture) and "Cancelled" (for payments that expire). These changes prevent confusing payment records and ensure customers can properly manage transactions that would otherwise get stuck in draft status.
Original PR description
Although the lack of these statuses does not block the flow of a transaction, they create confusing records for the user. The new states are: Authorized: it is returned by Mercadopago when it authorizes payments by bundle. It should behave as a pending payment as it's not yet captured and could still be canceled by timeout. Cancelled: It is returned by Mercadopago when a payment is not made within the expected timeframe. This prevents odoo from leaving payment transactions in draft that cannot be cancelled by the customer. adhoc ticket = 68407 Forward-Port-Of: odoo/odoo#151828 Forward-Port-Of: odoo/odoo#150435
This update improves the stock management system by preventing redundant data writes that were triggering unnecessary background processes. The change adds checks to avoid rewriting values that haven't actually changed, resulting in faster and more efficient inventory operations without affecting user-facing functionality.
Original PR description
As long as the framework is not able to avoid rewriting values that are already set, we must add checks to avoid triggering multiple processes linked to that value assignment. Example: https://github.com/odoo/odoo/blob/66c11acdbedf8d1bcae6deb8ec54c5da5a3ae16d/addons/stock/models/product_strategy.py#L111 https://github.com/odoo/odoo/blob/11d81b2145e95c50481101a63d3ad1d244279af4/addons/stock/models/stock_move.py#L302-L341 https://github.com/odoo/odoo/blob/daea3d4e10b8fc2c4840fff30474a1203eff55c2/addons/sale_stock/models/sale_order.py#L402-L418 It may be unusual for a field to compute stored depending on a non-stored, but the reality is this. @Tecnativa TT45883 TT45999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142309
This update adds official Kenyan states to the system based on ISO standards. This enhancement enables the upcoming eTIMS OSCU integration for Kenya, which is a tax compliance feature required for version 17.0.
Original PR description
This is a backport, with the original commit occurring in master: e80f5e3. The motivation for backporting these states is that they're useful in the upcoming eTIMS OSCU integration for Kenya, which targets version 17.0. Added Kenyan states as per https://www.iso.org/obp/ui/#iso:code:3166:KE Task ID: 3665315
The Partner Autocomplete module will no longer automatically install when Odoo is set up. This gives businesses more control over which features are enabled by default, allowing them to choose whether to use this functionality based on their specific needs.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects function signatures in the Bill of Materials (BOM) report to ensure compatibility with the latest system requirements. The fix adds a missing argument to report functions, preventing errors when generating BOM reports and ensuring the reporting feature works as intended.
Original PR description
Added `additional_product_metadata` argument to function overrides in enterprise.
This fix restores the display of customer addresses in field service tasks, which were previously hidden. Now when viewing field service tasks in the portal, customers will see the complete contact information including name, phone, email, and address. This improves the user experience by providing all necessary customer details in one place.
Original PR description
…rvice tasks Steps to Reproduce: - install website, field service module - in website, click on tasks - open field service tasks Issue: - it does not showing the customer's address anymore only (name, phone and email) is visible. Cause: - there is no such condition ,that the address should be visible. solution: - By default the phone and email will be visible for all the tasks, because those two fields mentioned in portal. To make the address visible only for field service tasks we need to give xpath. By giving xpath the issue will be solved task-3683976
This fix resolves an issue where helpdesk automation rules that send emails were failing due to a missing email-to-name parsing function. The system was trying to use a function that was removed in version 17.0, causing errors when processing customer emails. With this fix, emails are now properly converted to contact names and automation rules work as expected.
Original PR description
Steps (from customer DB):
- Setup automation rules that send mail
- Run the rules
No precise steps found, running the existing code in SA is enough too trigger an issue
```
Partner = env['res.partner']
Partner._parse_partner_name('johndoe@example.com')
```
Actual result:
- Traceback due to missing attribute for partner
- _parse_partner_name definition has been removed in 17.0, still exist in 16.4
Expected result:
- no traceback, mail send
- email is parse to name
opw-3693124
task-2612945This fix resolves a critical error that occurred when the website helpdesk module was installed and website menu items lacked URLs. The system was incorrectly processing null URL values, causing 500 internal server errors when accessing the database. The fix ensures only menu items with valid URLs are processed, restoring normal website functionality.
Original PR description
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while…
If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while connecting the database
"500 internal server error" is raised as below.
To resolve this issue, This PR will help to fetch only those records which have
url in website_menu.
```
500: Internal Server Error
[Traceback](https://43.test.upgrade.odoo.com/en#error_traceback)
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1866, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/website/controllers/main.py", line 97, in index
top_menu = request.website.menu_id
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2886, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/website/models/website.py", line 181, in _compute_menu
menus.mapped('is_visible')
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6066, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1280, in mapped
self.__get__(first(remaining), type(remaining))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in _compute_visible
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in <lambda>
helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
TypeError: 'bool' object is not subscriptable
```Fixed an issue in the barcode scanning workflow where the system would attempt to validate a picking before confirming that the form was properly closed after deleting a stock move line. This fix ensures the validation button is only clicked after the form has fully closed, preventing test failures in specific stock scenarios.
Original PR description
The tour ended with a class no always present, meaning it can fail in stock specific cases. This commit replace the last step by a new one searching the notification success to click on.
Fixed an issue where selecting all records in the Data Cleaning deduplication feature would only select the currently visible records instead of all matching records. Users can now properly merge all duplicate records across the entire dataset by using the "Select all" function, improving the efficiency of the data deduplication process.
Original PR description
Steps to reproduce ================== - In date_merge modul, have enough records (such as leads) to be merged - unfolf one record - select all -> only the unfolded record is selected opw-3613615 Forward-Port-Of: odoo/enterprise#55393 Forward-Port-Of: odoo/enterprise#53941
This fix eliminates duplicate display of financial amounts in account reports when the "totals below section" option is enabled. Previously, amounts would appear twice—once on the line itself and again in the total line. Now amounts display only in the total line when this option is active, providing a cleaner and less confusing report view.
Original PR description
When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#52966
A typo in the subscription renewal feature prevented the start date field from being properly protected as read-only. This fix corrects the field name reference so that when users renew a subscription, the start date field is correctly locked from editing, preventing accidental modifications to critical subscription dates.
Original PR description
### Steps to reproduce issue: 1. Create a quotation, set a recurrence and a subscription product 2. Confirm quotation 3. Click on Create Invoice and follow the steps 4. Return to the quotation and click on Renew 5. Start date (Other Info tab) of the renewal quotation is not readonly ### Explanation: Readonly modifier of `start_date` contains a typo, `2_renew` instead of `2_renewal`, causing it not to work properly. https://github.com/odoo/enterprise/blob/b0c34e816c872c4e22c360a2f333009232dc428a/sale_subscription/views/sale_order_views.xml#L172-L175 ### Suggested fix: The modifier works again once the right name is set. opw-3670543 Forward-Port-Of: odoo/enterprise#55482 Forward-Port-Of: odoo/enterprise#55250
This fix resolves a data consistency problem in French financial reports where certain report records were not properly handled during database upgrades. The issue affected databases running version 16.0 or higher, and the fix ensures these records are safely removed if they exist, preventing errors during system updates.
Original PR description
"l10n_fr_reports.account_financial_report_line_02_0_6_fr_bilan_passif_balance" doesn't exist for databases in 16.0 or higher, made or migrated after this [change](http://tinyurl.com/yrf8hf2r). Also, in some cases, it is being removed by the upgrade script, https://github.com/odoo/upgrade/pull/5358, which was reverted, but some databases were still able to migrate at that time; same problem for those databases as well. TBG-1042 upg-1247501, 1240637, 1203984, 1250604 Forward-Port-Of: odoo/enterprise#55397
This update fixes a visibility issue in Odoo Studio where invisible buttons were difficult to read due to poor text contrast. When users enable the "Show invisible elements" feature in the View Editor, primary buttons now display with improved styling that makes the text clearly readable against the background.
Original PR description
Forward-Port-Of: odoo/enterprise#55604 Forward-Port-Of: odoo/enterprise#55217
A bug in the Swiss payroll module's company car benefit calculation has been fixed. The issue involved incorrect data access in the salary rule configuration, which could have caused errors when processing employee compensation related to company car benefits. This fix ensures accurate payroll calculations for Swiss employees.
Original PR description
Fixed wrong dictionary access in salary rule
This fix resolves a critical issue that prevented users from generating return labels when using UPS shipping. The problem occurred because the return label function wasn't properly updated during a previous system upgrade, causing errors when users tried to validate deliveries with the return label option enabled. This fix updates the code to work correctly with the current system.
Original PR description
This commit fixes some issues that prevented the user from generating a return label in UPS REST module. To reproduce: Create a new shipping method with UPS. Enable "generate return label" toggle, and attempt to validate a delivery. There are a few issues as `ups_rest_get_return_label` was not adapted when forward porting from 15 to 16: + `_prepare_shipping_data` is changed, so it does not return `package_names` + `label_binary_data` from `_send_shipping` is changed from a dictionary to a list + as `package_names` no longer is there, the log message needs to be adapted. This PR fixes these issues, so that the return label could be generated. opw-3689861 Forward-Port-Of: odoo/enterprise#55328
This fix restores important accessibility attributes that were accidentally removed from the home menu when it was updated to use the command palette feature. These attributes help users with assistive technologies understand which app is currently selected when they first open the menu, improving the experience for users with disabilities.
Original PR description
When the home menu was modified to use the command palette on 2a518bc6, some ARIA attributes were lost that are still required. Such attributes are intended to indicate what is the focused app when no search is performed, i.e. the command palette has not been opened yet. Forward-Port-Of: odoo/enterprise#52570
This update fixes a performance issue where creating new records was unnecessarily loading large related field data (like user lists with hundreds of thousands of records) even when that data wasn't being used. The system now only loads this data when it's actually needed, significantly improving performance for operations that create new records with large related fields.
Original PR description
In https://github.com/odoo/odoo/commit/e0297bdac4eac165a79680de3b1139c2f554d5f5, the creation of a new record always patches the inverse fields of relational fields in order to make the cache of…
In https://github.com/odoo/odoo/commit/e0297bdac4eac165a79680de3b1139c2f554d5f5, the creation of a new record always patches the inverse fields of relational fields in order to make the cache of those inverse fields consistent.
For instance, when creating a new record like
```py
user = model.new({'group_ids': [Command.link(group.id)]})
```
The inverse of field `group_ids` on the new record having `group` as origin is patched so that its value includes `record`. A side effect of this mechanism is that it fetches `group.user_ids` in order to patch the value of `new_group.user_ids`, where `new_group` is the new record having `group` as origin.
The side effect described above is problematic when that inverse field has huge cardinality, like hundreds of thousands of records, and this performance overhead is unacceptable when the inverse field is actually not used at all.
We address this performance issue by patching the value of x2many fields only when they are used. If the value of the field is not in cache yet, the patch is applied once a value is put in cache. If the field is not used, the patch is simply never applied.This fix resolves an issue where adding new tax repartition lines (used for invoice and refund categorization) during a module upgrade would fail with database errors. The system now correctly handles these updates without losing critical information, ensuring tax configurations remain valid after upgrades.
Original PR description
When repartition_lines are added to an already existing account_tax record, on upgrade, the new repartition lines are inserted with just tags, which results in the insertion of null value in…
When repartition_lines are added to an already existing account_tax record, on upgrade, the new repartition lines are inserted with just tags, which results in the insertion of null value in document_type column.
To reproduce:
- Modify `l10n_fr/__manifest__.py` version to `2.0`
- Create an empty DB
- Start `./odoo-bin -c ../.myodoorc -i l10n_fr` with demo data
- Stop the database (can dump it for convenience)
- Start `./odoo-bin -c ../.myodoorc -u l10n_fr`
- Add a couple of repartition lines (invoice + refund) to an existing tax to `odoo/addons/l10n_fr/data/template/account.tax-fr.csv`
- Modify `l10n_fr/__manifest__.py` version to `2.1`
- Start `./odoo-bin -c ../.myodoorc -u l10n_fr`
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-16.3/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/saas-16.3/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/registry.py", line 90, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 478, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 366, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/loading.py", line 232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-16.3/odoo/modules/migration.py", line 233, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/saas-16.3/addons/l10n_fr/migrations/2.1/post-migrate_update_taxes.py", line 8, in migrate
env['account.chart.template'].try_loading('fr', company)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 142, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 186, in _load
self._load_data(data)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/chart_template.py", line 499, in _load_data
created_vals[model] = self.with_context(lang='en_US').env[model]._load_records(create_vals)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4663, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4594, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/saas-16.3/addons/account/models/account_tax.py", line 362, in write
return super().write(self._sanitize_vals(vals))
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4033, in write
field.write(self, value)
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4240, in write
self.write_batch([(records, value)])
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4261, in write_batch
self.write_real(records_commands_list, create)
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4441, in write_real
flush()
File "/home/odoo/src/odoo/saas-16.3/odoo/fields.py", line 4397, in flush
comodel.create(to_create)
File "<decorator-gen-119>", line 2, in create
File "/home/odoo/src/odoo/saas-16.3/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/tmp/tmp90kuz8ug/migrations/util/orm.py", line 210, in wrapper
return f(*args, **kwargs)
File "/tmp/tmp90kuz8ug/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
return super().create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "/home/odoo/src/odoo/saas-16.3/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4231, in create
records = self._create(data_list)
File "/home/odoo/src/odoo/saas-16.3/odoo/models.py", line 4434, in _create
cr.execute(
File "/home/odoo/src/odoo/saas-16.3/odoo/sql_db.py", line 319, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "document_type" of relation "account_tax_repartition_line" violates not-null constraint
DETAIL: Failing row contains (305, null, 1, 1, 1, 1, tax, f, 2023-10-17 19:52:56.357571, 2023-10-17 19:52:56.357571, 100, 6, null).
```
Forward-Port-Of: odoo/odoo#148643This update significantly speeds up the job kanban view in the recruitment module by optimizing how application counts are calculated. The improvement reduces loading time from 800 milliseconds to just 6 milliseconds, making the recruitment interface much more responsive for users managing job applications.
Original PR description
Purpose ======= From 800ms to 6ms to execute _compute_new_application_count on odoo.com 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 an issue where the website editor incorrectly prompts users to discard changes when editing content after upgrading to version 17.0. Previously removed CTA buttons were reappearing and causing false "unsaved changes" warnings that couldn't be properly dismissed. This fix ensures the editor correctly tracks actual changes and prevents unnecessary discard dialogs.
Original PR description
After upgrading (specifically following this [upgrade PR]), when editing an element, the editor may be tricked into considering that the page isn't correct even though it is. It causes the "discard" dialog to open. Steps to reproduce after the [upgrade PR]: - Remove the CTA in 16.0 with the bin icon (on the button itself, or from the edit panel, next to the "Block" section). - Upgrade to 17.0. - The button is back. Edit the header and click to hide it. => a dialog opens "Are you sure you want to discard your changes?". - Click either "yes" or "cancel". => either way, nothing is discarded nor cancelled. [upgrade PR]: https://github.com/odoo/upgrade/pull/5500 Related to opw-3644220
Fixed an issue where selecting multiple invoices from the same customer and sending them by email would only send one email instead of all selected documents. The system now correctly sends all selected records to the recipient as intended.
Original PR description
### Steps - Go to Invoicing, list view. - Select two records with the same partner. - Send receipt by mail. ### Issue Just one mail is sent. ### Reason ``mailing_document_based`` parameter which is used to enable sending multiple records to the same recipient is not passed in the context. opw-3552562 Forward-Port-Of: odoo/odoo#143754
This fix resolves a bug that caused the system to crash when grouping products by many-to-many fields (like categories) that contain empty values. The issue occurred because of a typo in the code that checks data types, preventing proper handling of groups with no assigned values. This fix ensures users can successfully view and filter grouped data without encountering errors.
Original PR description
Since https://github.com/odoo/odoo/issues/1432 To reproduce the problem, you need to ensure that a read_group returns several groups, with the first element being a group with no value if you choose…
Since https://github.com/odoo/odoo/issues/1432 To reproduce the problem, you need to ensure that a read_group returns several groups, with the first element being a group with no value if you choose to group on a many2many (see test). Here's an example to reproduce in website_sale: - Install `website_sale` without demo-data - Go to `eCommerce/Products` - Create a new product - Go to `Sales` tab in the product form view - Set a new `eCommerce shop/Categories` like `Sales` - Save - Return to `eCommerce/Products` - Remove default filters - Group by `Website Product Categories` - There are two group: `None` and Sales` - Click on None - Traceback In this case, the orderby is website_sequence:sum ASC, and will therefore return as first group None containing `Delivery Product` and as second group `Sales` containing the newly created product. What happens is that `read_group` will build `rows_dict` thanks to `_read_group`. https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2724 this `rows_dict` will be ordered according to `orderby`and then passed as an argument to the `_read_group_format_result` function https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2759 For each row, this function will convert `row[group]` (group in this case is the many2many field) into a tuple containing (id, displayname) in case the value (`row[group]`) is found which will be used to build the domain `[(field_name, =, value)]`. So, for example, replacing ```py rows_dict = [ groupbyField': odoo.model(1), groupbyField': odoo.model(4), ] ``` with ```py rows_dict = [ groupbyField': (1, 'First record'), groupbyField': (4, 'Fourth record'), ] ``` https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2460-L2462 If the value is False, we'll use the 'not in' operator instead. To do this, we need to retrieve the ids of all the other groups to include in this one all the records that aren't in any group, either by retrieving the id if it's a model, or by retrieving the first element of the tuple if it's already been modified, or by directly retrieving the value of the field if it's not a many2x. Except that if the first element is directly a group without a value, it won't be able to retrieve the values of the other groups, because the condition for checking that it's a `BaseModel` instance contained a typo https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2465-L2467
This update fixes two critical issues in the web editor's mega menu functionality. First, it corrects a cursor positioning bug that occurred when changing HTML tags, which was causing errors. Second, it improves how the editor handles link selection in complex menu structures, allowing users to properly edit individual elements within mega menus without toolbar conflicts.
Original PR description
Current behavior before PR: - Commit [[1]](https://github.com/odoo-dev/odoo/commit/d04e32c6f9da2b2e8709985648786df6f7eb6091) introduces an approach to preserve the cursor in `setTag` when new node is…
Current behavior before PR:
- Commit [[1]](https://github.com/odoo-dev/odoo/commit/d04e32c6f9da2b2e8709985648786df6f7eb6091) introduces an approach to preserve the cursor in `setTag` when new node is inserted. It used `setStart` at `firstLeaf` of `startContainer` and used offset of the `startContainer` similarly for `endContainer` which is incorrect and would throw traceback regarding no child at that offset.
- `destroyLinkTools` function sets the selection to entire link. However, in case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be updated correctly, also one could not change the a tag of a single element within the link.
Desired behavior after PR is merged:
- Fixed it by getting the correct `startContainer` and `endContainer` when new node is created.
- `destroyLinkTools` selects the `anchorNode` and the `focusnode` of the selection instead of entire link.
task-3245819
Forward-Port-Of: odoo/odoo#151713
Forward-Port-Of: odoo/odoo#145925This update corrects the alignment of input fields in the project settings form when viewed on mobile devices. Specifically, the Alias Domain field in Custom Email Servers now displays properly below its label instead of appearing inline, improving the mobile user experience.
Original PR description
Steps: - In mobile install project - Project.project form view - Go to the project settings - In Alias Domain(Custom Email Servers) - The input alignment is not good Issue: - The input should go under the alias domain in project.project form view in mobile Cause: - Here they adding extra bootstrap class so that's why it will be showing in correctly Fix: - By removing the bootstrap class of 'oe_inline' the problem will be solved task-3550702 Forward-Port-Of: odoo/odoo#151404 Forward-Port-Of: odoo/odoo#140923
This fix resolves a crash that occurred when users tried to scroll through messages containing tables while using right-to-left (RTL) languages. The issue happened because the system was trying to access table information that was no longer available after the message was saved. The fix simply skips this operation when the table element is no longer present, preventing the error.
Original PR description
Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df Issue: ====== Adding a table in a long chatter message with scroll raise a traceback Steps to reproduce the issue: ============================= - Switch to RTL lang - Go to any form view and open the editor composer to create a log note - Write a lot of lines so that the scrollbar appears - Add a table - Log the note - Try to scroll -> traceback Origin of the issue: ==================== The `_onScroll` method is called and it has `this._rowUiTarget` as the row from the composer dialog which is not in the ui anymore so `closestElement(row, 'table')` will return `null`. Solution: ========= We just do nothing when the element is not connected. task-3707808
This fix resolves an issue where module website links were displaying incorrectly with "/False" at the end. The problem occurred because the module name field was missing when generating website URLs. By adding the module name to the data retrieval method, website links now display properly and users can access module information correctly.
Original PR description
Before this commit, the website of the industry module ends with `/False`. This is because the website of the module requires the name of the module. It is therefore added in the `_get_modules_from_apps` method.
Fixed a bug where searching for amounts with comma decimal separators (common in many countries) would cause an error in the Journal Items view. The system now correctly converts the user's input before processing the search, allowing users in regions that use commas as decimal separators to search for amounts without encountering errors.
Original PR description
In Language settings, change decimal separator to ',' Go to Journal Items In the search bar input '4,50' and search for 'Amount' Error: ValueError: could not convert string to float: '4,50' This occurs becuase when the search model assemble the domain for the orm we use the original string '4,50' and not the parsed value '4.5' opw-3700578
A typo in the mail notification templates has been corrected where the HTML HEAD tag was incorrectly written as HEADER. This fix ensures that email metadata, particularly the Content-Type tag, is properly recognized and processed when mail templates are displayed.
Original PR description
**Typo in HEAD tag of mail notification template** Impacted versions: - 16.0 - 17.0 Steps to reproduce: The `<HEAD>` tag in the mail notification templates was typo'd as `<HEADER>`. Current behavior before PR: No specific errors observed, but the `meta` tag for `Content-Type` may have been ignored. Desired behavior after PR is merged: The mail template displays as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148889
This update fixes a technical issue that caused the system to crash when users switched to mobile view while working with project workspace dialogs. The problem occurred because certain functions weren't properly initialized for mobile devices. Now these functions are always prepared, preventing the crash regardless of which view mode is active.
Original PR description
**Steps to reproduce:** 1. Configuration > Projects 2. Open any project 3. Setting tab 4. Document field 5. Create and edit a new workspace. 6. Inspect mobile view 7. Save it or discard it -> traceback occurs **Technical Reason** The dialog values are prepared based on the desktop view, which results in the scrollToOrigin function is not being prepared when the condition is not met. Consequently, when the view is switched to mobile and inside the onWillDestroy, the scrollToOrigin is called but it is not prepared so traceback occurs. **After this PR** Now the function will be prepared even if we are not in the mobile view and traceback will not occur. Task-3573747 Forward-Port-Of: odoo/odoo#151954 Forward-Port-Of: odoo/odoo#142457
This update fixes a problem where images in mass mailing campaigns were being converted to attachments multiple times, creating unnecessary duplicates and wasting database space. The fix ensures images are properly converted to attachments only once and reused correctly, while also improving how attachment names are generated and when they are created during the mailing record lifecycle.
Original PR description
[FIX] mass_mailing: multiple attachments for same image [FIX] mass_mailing: duplicate call to saveModifiedImages task-3479586 Forward-Port-Of: odoo/odoo#151172 Forward-Port-Of: odoo/odoo#138563
The reCAPTCHA security feature was using an invalid default score of 0.5, which doesn't comply with Google's requirements. This fix updates the score to use one of Google's approved values (0.1, 0.3, 0.7, or 0.9) to ensure proper security validation and compliance with Google's reCAPTCHA Enterprise standards.
Original PR description
The reCaptcha score was set by default on 0.5. According to [Google's documentation], that score isn't valid by default. It should be one of 0.1, 0.3, 0.7, 0.9. To use other values you must first go through a security review from reCaptcha. [Google's documentation]: https://cloud.google.com/recaptcha-enterprise/docs/interpret-assessment-website#before_you_begin task-3585213 Forward-Port-Of: odoo/odoo#151929 Forward-Port-Of: odoo/odoo#150208
This fix resolves an issue where customers could not complete Razorpay payments at the point of sale due to a missing phone number field. The payment system now correctly includes the phone number information, allowing customers to successfully process their transactions through Razorpay.
Original PR description
Current behavior: When you try to pay with razorpay, you got an error saying the phone number was missing. Steps to reproduce: - Setup RazorPay - Set a phone number on admin - Go to the POS - Add a product to the cart - Click on the payment button - Select razorpay - Scan the QRCode with your phone (make sure you'r connected on the admin account) - Try to finalize the payment opw-3669600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue in the Point of Sale system where orders containing two or more items with kits would fail with an error. The fix ensures that kit-based orders process correctly regardless of how many kit items are included in a single order, improving the reliability of kit-based sales transactions.
Original PR description
This commit fixes a ValueError that occurred when an order contained two or more order lines with kits. The error was caused by the 'self.qty' expression, which failed when 'self' was a recordset. The code has been updated to correctly handle multiple order lines with kits. opw-3708950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151807 Forward-Port-Of: odoo/odoo#151710
This fix corrects how spreadsheet formulas handle text fields that contain numeric values with leading zeros (like barcodes "00036"). Previously, these values were incorrectly converted to numbers in formulas, causing lookups to fail. Now they are properly preserved as text strings with their leading zeros intact, ensuring formulas work correctly.
Original PR description
When a char field contains a value which represents a number (e.g. "00036"), the value is inserted as a number in the formula instead of a string. Because of this, the function value is not found. actual: =ODOO.PIVOT.HEADER(1,"x_studio_barcode",00003456799) expected: =ODOO.PIVOT.HEADER(1,"x_studio_barcode","00003456799") opw: 3623662 Task: 3631998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151959 Forward-Port-Of: odoo/odoo#151312
Fixed an issue where task deadline dates were not being copied when duplicating a project. When users copied a project that contained tasks with deadline dates set, those deadlines were being lost in the copied tasks. This has been corrected so deadline information is now properly preserved during project duplication.
Original PR description
[FIX] project: task date_deadline not copied Steps to reproduce: - create a project and a task inside - set date_deadline on the task - copy the project => the copied task has date_deadline = False Source: - date_deadline copy property wasn't changed to True when the field was merged with planned_date_end in 17.0 Fix: - copy was removed as its default value is True X-original-commit: https://github.com/odoo/odoo/commit/56073896a69d9f68ce7e7938d9dec7ef094e19b3
This fix resolves an issue where discarding changes in forms containing HTML editor fields (like mail templates) would not properly remove the edits made to those fields. The fix ensures that when users click "discard changes," all modifications to HTML fields are properly reverted, matching the behavior of standard form fields.
Original PR description
Issue: ====== Discard changes of form having html field doesn't remove the changes applied in the html field. Steps to reproduce the issue: ============================= - Open any mail template - Add modification on the template - Click on discard changes Origin of the issue: ==================== The function `this.props.update` is responsible of updating `_changes` and updating the record which is called for usual input_field using `useInputField` hook, but since this html field isn't of the same format we didn't use it here se we have to call the update also on historystep. Solution: ========= Call `this.updateValue()` in historyStep too since it takes care of parsing the new value and calling `this.props.update` task-3453497 Forward-Port-Of: odoo/odoo#151876 Forward-Port-Of: odoo/odoo#149601
This update adds validation to prevent users from saving record rules with incorrect domain syntax. Previously, a typo in a record rule domain could lock users out of the system entirely. Now, the system will catch and reject invalid domains before they're saved, protecting system stability and user access.
Original PR description
**steps to reproduce:** - create an ir.rule on res.users and write a domain with a typo **before this commit:** - users can't log into odoo **after this commit:** - an error is raised to prevent saving a bad domain opw-3653746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151640 Forward-Port-Of: odoo/odoo#147763
This fix corrects how Odoo calculates automatic reorder quantities when visibility days are set on reordering rules. Previously, future sales orders were only considered if minimum stock levels were set; now they are properly included in calculations regardless of minimum quantity settings. This ensures accurate inventory planning when looking ahead at scheduled deliveries.
Original PR description
[FIX] stock: use visibility days in reordering If reordering rules' visibility is set bigger than DAYS_FROM_TODAY_TO_ORDER (plus lead time). Then the order should be included in the calculation of…
[FIX] stock: use visibility days in reordering
If reordering rules' visibility is set bigger than DAYS_FROM_TODAY_TO_ORDER
(plus lead time). Then the order should be included in the calculation of
quantity to order.
┌─ Today ┌── Scheduled Delivery
│ (2024-01-01) │ (2024-02-01)
│ │ aka commitment_date
│ │
▼ ▼ time
──────────────────────────────────────────►
◄────────────────────────────►
DAYS_FROM_TODAY_TO_ORDER
◄────►
lead_time
Before this commit visibility_days were taken into the account only if
there forecasted quantity was lower than product minimal quantity. This
commits ensures that the visibility_days will always be included into
the calculation.
[Reproduce]
- install stock,purchase,sale_management
- Create a product P (storable)
- Add vendor V under the purchase tab
- Create Reordering with route buy, vendor V, min 0, max 0
- Create a Sale Order for 1 unit of P, under the 'Other Info' tab, set the Delivery date to 1 month in the future, Confirm.
=> If you go back to the reordering rule, you have Qty To Order at 0 (ok)
- Set Visibility Days at 40
=> Qty To Order is still at 0, even though it should now see the sale order we made before (bug)
- Set the Min qty at 1
=> Qty To Order is now at 2, it found the sale order we made, and computed the correct quantity. (ok)
- Set the Min Qty back to 0
=> Qty To Order is back at 0 (bug)
opw-3638398
Forward-Port-Of: odoo/odoo#149530This fix resolves a display issue where the "allocated time" field appears partially hidden when viewing a task with zero allocated hours in studio mode. The field width has been adjusted to properly display the full label, improving the user experience when customizing task forms.
Original PR description
This commit's purpose is to fix the display of the default field when entering studio mode from a task form with no allocated time. Step to reproduce : -open project -open office design -create new…
This commit's purpose is to fix the display of the default field when entering studio mode from a task form with no allocated time. Step to reproduce : -open project -open office design -create new task/select a task with 0 allocated hours -open studio the display of the field 'allocated time' is partially hidden by the span 0% Source of the bug: the widget timesheet_uom_no_toggle has a max width of 7CH, which is too little to allow the full display of the default name. Solution: Create and add a new scss class which is only active in studio mode. Version affected: saas-16.2 to master task - 3553101 https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&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#152106 Forward-Port-Of: odoo/odoo#139741
This update adds missing accessibility features to the command palette search tool to help users with screen readers and other assistive technologies. Previously, when users searched in the home screen, the selected search result was only visually highlighted, making it impossible for assistive technology users to know which result was selected. This fix adds the necessary technical markers so that all users, including those using screen readers, can properly identify the currently selected search result.
Original PR description
Since searches in the home screen are now handled by the command palette, some ARIA attributes are required for assistive technologies to know what is the currently-selected result. That because the actual focus is always on the search box, while the actually-selected result is highlighted by toggling classes, which makes not possible anymore to know what is the selected result for e.g. screen reader users. For more info, see original implementation on enterprise's home menu on [1]. This commit is just re-applying such changes here. [1] odoo/enterprise#14511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145872
This fix resolves an error that occurred when users tried to change the analytic distribution on a posted journal item in the accounting module. The issue was caused by unnecessary processing in the system's change handler. With this fix, users can now successfully modify analytic distributions without encountering errors.
Original PR description
Install Studio Activate form view of journal items and disable readonly flag on Analytic distribution field. Create a journal entry adding analytic distribution to a line and post. Now open the journal item in form view and try to change the analytic distribution Action will be blocked by error This is caused by the onchange in _inverse_analytic_distribution. As the method take care of unlinking and creating new lines no more actions are required by the orm opw-3690346 Forward-Port-Of: odoo/odoo#151740
This update fixes the visual alignment of the Previous and Next navigation buttons on course lesson pages. The buttons were not centered vertically on the screen, which has been corrected by applying proper styling. This improves the user experience when navigating through course content.
Original PR description
HOW TO REPRODUCE ================ Don't sign in and go to front-end > Courses > Trees, Wood and Gardens > Main Trees Categories. '< Prev' and 'Next >' are not centered vertically. HOW TO FIX ========== Slides navigation buttons are <a> HTML elements. Add them bootstrap class 'my-auto' to handle their height properly. task-3633452 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146154
This fix removes an unwanted "Draft" label that was incorrectly appearing on invoices that had been previously posted and then reset to draft status. When such invoices were edited and saved, an extra "Draft" title would display. After this update, invoices that were posted before will no longer show this duplicate label, providing a cleaner and more accurate invoice display.
Original PR description
Consider an invoice that was reset to draft. When it is is edited to be '/' (and the record is saved) an additional "Draft" title appears. It should not appear. After this commit the "Draft" title will not be shown on invoices that were posted before. task-3680398 Forward-Port-Of: odoo/odoo#151880 Forward-Port-Of: odoo/odoo#149351
This fix corrects how product prices are calculated and displayed on branch websites when taxes are set to be included in the price. Previously, taxes from parent companies were not being considered, causing products to display incorrect prices. For example, a $100 product with a 15% tax should show as $115, but was incorrectly showing as $100. This ensures customers see accurate pricing information on product listings.
Original PR description
Steps to reproduce: - Create a branch for a company (e.g. Branch X) - Go to "Website / Configuration / Websites" - Create or configure a website on Branch X (e.g. Website X) - Go to "Website / Configuration / Settings" - Select Website X - Set "Display Product Prices" to "Tax Included" - Create a product for a price of $100 and a tax from parent company (e.g. 15%) - Go Website X - Edit Home page and add Products snippet Issue: On the Products snippet, the price of the product should be "Tax Included" ($115), but it is not. The displayed price is $100. Cause: When computing the prices, taxes from parent companies are not taken into account. This fix is a complement to https://github.com/odoo/odoo/pull/151223 opw-3660156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152012
This fix resolves an issue where cash rounding was being incorrectly applied to invoices due to floating-point precision errors in amount calculations. The system now properly rounds invoice totals to the currency's decimal precision before determining if cash rounding adjustments are needed, preventing unnecessary rounding charges from appearing on invoices.
Original PR description
Steps to reproduce: - Enable Automated Valuation. - Set the cost of Acoustic Bloc Screens to 287.33. - Set the Product Category on the product to have AVCO automated valuation. - Enable Cash Rounding. - Create a Cash Rounding (see tests). - Make an invoice selling one Acoustic Bloc Screen and remove the tax. - Set the Cash Rounding on the invoice under "Other Info". - Confirm the invoice. Bug: when summing the amount of all the lines the result is slightly off (float accuracy) this will create an unnecessary cash rounding to compensate Fix: round the sum to the currency precision before checking for the cash rounding opw-3681307 Forward-Port-Of: odoo/odoo#151833 Forward-Port-Of: odoo/odoo#151547
This update fixes an issue in the web editor where removing paragraphs from within list items would sometimes cause formatting styles to be lost. The fix converts paragraphs to spans within list items while preserving all associated formatting classes, ensuring that text styling remains intact when editing lists.
Original PR description
**Current behavior before PR:** if you have p within li,sometimes removing the p will result in the loss of all classes. **Desired behavior after PR is merged:** Replace p inside li with span while preserving classes. task-3546209 opw-3602047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151894 Forward-Port-Of: odoo/odoo#138973
This fix corrects an issue where empty quotations were being counted and displayed in mass mailing campaign statistics. Previously, clicking on the quotation count would show an empty screen because the system was counting quotes with no line items. Now, only quotations with actual content are included in the count, providing accurate campaign metrics.
Original PR description
Steps to Reproduce
==================
1). Create an empty quotation and link it to a mass mailing
(same medium and source).
2). Open the mailing form, the stat button displays "1 Quotation" 3). Click to open it
-> Empty Screen
Technical
==========
There are no records in this view as it is based on the sales report model. If a quote has no line, there is nothing to display.
After this PR
=================
Now empty quotes will not be counted.
Task-3635429
Forward-Port-Of: odoo/odoo#152045
Forward-Port-Of: odoo/odoo#147674This fix resolves a problem where company logos appeared distorted in PDF coupons sent to customers if the logo wasn't in a specific aspect ratio. The update ensures logos display correctly regardless of their dimensions, improving the professional appearance of customer communications.
Original PR description
Logo on pdf send to customer after generating coupon code was disorted if it was not in certain ratio. task-2588963 Forward-Port-Of: odoo/odoo#150638 Forward-Port-Of: odoo/odoo#144489
This fix resolves a system error that occurred when planning manufacturing orders with more than 88 work orders. The issue was caused by Python's default recursion limit being exceeded during the planning process. The fix increases the recursion limit to allow planning of approximately 320 work orders, enabling users to handle larger manufacturing operations without encountering errors.
Original PR description
Current behaviour: --- When planning more than 88 work orders, there is a recursion error. Steps to reproduce: --- 1. Go to Manufacturing 2. Operations > Manufacturing Orders 3. Create a manufacturing order 4. Add 90 work orders 5. Click on Confirm 6. Click on Plan 7. Recursion error Cause of the issue: --- Maximum depth of the Python interpreter stack The recursion limit being set at 1000 by default (with getrecursionlimit) Fix: --- Upped the limit to ~320 work orders opw-3651494 Co-authored-by: Rémy Voet <ryv@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149617
This update fixes a test in the accounting module to properly verify both warning and success notifications when sending and printing documents. The test was incomplete and has been corrected to ensure all notification types are properly validated, improving the reliability of the accounting system's notification functionality.
Original PR description
Forgot to update the test so that it tests both warning and success notifications.