Daily updates from Odoo
Thursday, February 1, 2024
39 changes · 17.0
Enhancements to existing features
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
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
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 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 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