Thursday, February 1, 2024
34 changes · 17.0
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-2612945Fixed 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
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 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 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 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
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
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