Tuesday, October 8, 2024
29 changes
3 changes
Resolved issues and error corrections
Reloading an import records page now keeps the selected business object, so users are returned to the correct import screen instead of seeing an error or being redirected. This makes record imports more reliable when users refresh the browser or change interface settings during the process.
Original PR description
- In any APP (We would use CRM for the example); - On a multi-record view (Kanban, List, or other); - Click the action menu; - Click on “Import records” dropdown; - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, an exception was raised, and the default multi-record view was loaded. This occurs because, the client action base import required a model (found in the context) that was lost when reloading. Now, the model is put in the query string of the URL (as active_model), in that way, when reloading, the client action base import will have the needed model. Note that, this is also the behavior of the stock TraceabilityReport client action [1]. opw-3959254 [1] : https://github.com/odoo/odoo/commit/8b3deab679bfee844ccd84c7f4f6f831921365d3
Reloading an import screen now keeps users on the same import page instead of briefly showing an error and sending them back to the list or kanban view. This preserves the user's workflow and prevents confusion during record imports.
Original PR description
- Go to CRM app - Click on the action menu --> Import records --> Import screen will appear - Reload the page a traceback will occur which will disappear quickly (you can see it in console) - It redirects you back to the kanban view which is not correct Before this commit, on reloading the import screen page a traceback was occuring which redirects back to the kanban/list view. This occurs because the ImportAction lost the current model at reload (resModel). Now, the ImportAction will update the state of action using updateActionState prop, to add the resModel to the url (as a query param), and be able to restore the full state at reload. Task-3959254 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Pivot table header menus now close again after choosing a grouping option. This prevents users from adding multiple groupings from a stale menu state, which could lead to incorrect pivot table results.
Original PR description
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217
1 change
Resolved issues and error corrections
Odoo Studio and related apps now avoid creating outdated view rules when customizing screens. This helps keep customizations compatible with current platform standards and reduces the risk of future display or upgrade issues.
18 changes
Resolved issues and error corrections
A spelling mistake in the invoice PDF report was corrected. This improves the professionalism and clarity of customer-facing invoice documents without changing how invoicing works.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
7 changes
Resolved issues and error corrections
This fix corrects how revenue and margin are calculated in project planning reports when products are sold by units other than hours (such as days). Previously, the system incorrectly assumed all pricing was hourly, leading to significantly inaccurate financial reporting. Now the system properly accounts for the actual unit of measure specified on the sales order, ensuring accurate revenue and margin analysis.
Original PR description
*= account_asset, account_consolidation, account_disallowed_expenses_fleet, account_reports_cash_basis, appointment, documents, helpdesk, l10n_ph_reports, planning, whatsapp This PR consist of two commits: 32c4dc22980c2b723e68a68e417afe3efaebe6a6 - This commit will prevent using deprecated xpath. f01b2e58841fe247d44102055413bbbcea2586e2 - This commit will change studio xpath api such that it no longer generates custom views using deprecated xpath. Specifications: `contains(@class...` => `hasclass(...` Community PR: https://github.com/odoo/odoo/pull/174139 Task - 3820162
This fixes a visual issue in the Discuss sidebar where the selected conversation could lose its background color and show only an outline. The change restores the expected highlight, making it clearer which item is currently active without affecting the previous hover-status fix.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/182394 PR above fixed an issue where mouse-hovering IM status lead to buggy background color. This happens because the IM status requires `bg-inherit`…
Follow-up of https://github.com/odoo/odoo/pull/182394 PR above fixed an issue where mouse-hovering IM status lead to buggy background color. This happens because the IM status requires `bg-inherit` in order to determine the right background color to crop the avatar. Buttons have specific bg-color that cannot simply be overidden with `bg-inherit`, so this was defined in SCSS with higher specificity. A consequence of increasing the specificity of this rule was that it became more specific than the one for active item, so the active item in discuss sidebar had no background color but only the outline. This commit fixes the issue by increasing the stylerule specificity of active item background color, so that this is higher than the `bg-inherit`. The specific bg-inherit is still important to fix the issue in PR above. Before / After  
This fixes an issue in Point of Sale that prevented custom extensions from saving additional related sales records. Businesses using customized POS workflows can now add and store extra order details more reliably.
Original PR description
At the moment it is not possible to add new X2many relations to a model inside the `SERIALIZABLE_MODELS` list. I would like to add an One2many relation to the `pos.order` model: ```python class…
At the moment it is not possible to add new X2many relations to a model inside the `SERIALIZABLE_MODELS` list.
I would like to add an One2many relation to the `pos.order` model:
```python
class PosOrder(models.Model):
_inherit = "pos.order"
example_items = fields.One2many("example.item", "order_id")
```
```javascript
import { Base } from "@point_of_sale/app/models/related_models";
import { registry } from "@web/core/registry";
export class ExampleItem extends Base {
static pythonModel = "example.item";
setup(vals) {
super.setup(vals);
}
// ...
}
registry.category("pos_available_models").add(ExampleItem.pythonModel, ExampleItem);
```
A call to [`order.serialize`](https://github.com/abichinger/odoo/blob/f9de1eef6dd403157c0222dc75de85c8b7b59e3c/addons/point_of_sale/static/src/app/models/related_models.js#L191) throws the following error:
```
Trying to create a non serializable record example.item
```
After this PR is merged it is possible to add new models to the list of serializable models:
```javascript
import { SERIALIZABLE_MODELS } from "@point_of_sale/app/models/related_models"
SERIALIZABLE_MODELS.push("example.item")
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe stock operations board no longer allows cards to be dragged and dropped in grouped views. This helps prevent accidental changes that could cause operational issues in multi-warehouse setups.
Original PR description
In a multi-warehouse environment, dragging and dropping operations card by mistake in "group by" view can lead to many issues. Therefore, this PR disables this feature. task-4207673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue that prevented users from closing Point of Sale sessions. It improves day-to-day store operations by ensuring session closing works correctly while handling administrator-level checks appropriately.
Original PR description
Before this commit: ==================== - The user cannot able to close the session. After this commit: ==================== - Able to close the session. - Check the logged-in user ID with the `SUPERUSER_ID` for the userError. task-4239959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents an error when importing records that use a custom property field linked to another record type but missing its target setup. It also makes import errors for numeric property fields clearer, helping users understand and correct import files faster.
Original PR description
## [FIX] core: fix traceback when importing many2one Property without comodel It is possible to create a Property field as many2one but without choosing a model. But it generates a Traceback in the import. ## [IMP] core: improve error message for import of Properties int/float.
Switching a Point of Sale payment method away from a terminal integration now clears the terminal-specific fields. This prevents hidden or outdated terminal settings from blocking users when they save payment method changes.
Original PR description
[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty or do not pass validations. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go to Configuration > Payment Methods. Click new or edit a record. 4. Select a journal 5. Select an "Integration" option "Terminal" 6. Select a terminal in "Integrate with" option 7. Switch an "Integration" option to None 8. Observe that the added fields does not disappear and is still getting validate when you save the record. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adds a standard identification header when Odoo hardware drivers open websocket connections. It helps prevent legitimate hardware-related connections from being blocked by proxy firewalls, improving reliability in protected network environments.
Original PR description
**This is a forward-port of a fix that was manually committed to saas-17.4 during the OXP:** `websocket.WebSocketApp` doesn't set any fingerprint header, like no user-agent or origin, ... It can lead to issues when using a proxy firewall, such as HAProxy, as it could lead to the fingerpint to be 00000000-00000000-00000000-00000000, which can be seen as not legitimate, and the requests to be rejected for that reason. By setting a user-agent, we overcome this limitation 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
Paid restaurant orders no longer keep a table marked as booked, so staff can quickly see which tables are truly available. The update also improves product setup visibility by showing tracking information in the Point of Sale product form.
Original PR description
## Commit 1 After paying an order in a table, the table isn't rendered to be "emtpy". In this change, we make sure that the order that makes a table "booked" is based on the table's active order that is not paid. There is already a getter for that which is the `.orders`. And since the `getOrder` method isn't used, we are also removing it in this change. ## Commit 2 Before: <img width="663" alt="Screenshot 2024-10-01 at 15 17 28" src="https://github.com/user-attachments/assets/cb7af694-cbc9-46d5-a219-048cfd6a1895"> After: <img width="665" alt="Screenshot 2024-10-01 at 15 16 07" src="https://github.com/user-attachments/assets/29bf899c-9f92-4bd7-b4e2-ec98ffcce24a">
Users who end a call while camera or screen sharing permission is still pending will no longer see an error after responding to the permission prompt. This improves reliability in Odoo Discuss calls by safely handling cases where the call is no longer active.
Original PR description
Fixed an issue where an error is thrown if the call is ended before accepting/rejecting the camera or screen access. After ending the call, accepting or rejecting access would trigger an error due to the absence of a check for whether the call is still active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes visual issues in website product carousels so product images and text display correctly. It also removes an unwanted mobile scrollbar caused by carousel arrows, improving the shopping experience on smaller screens.
Original PR description
This commit fixes two layout issues: 1. In the dynamic products snippet: using the layout "centered", the image was overlapping the text of the card due to having no height set for the image. 2. On…
This commit fixes two layout issues: 1. In the dynamic products snippet: using the layout "centered", the image was overlapping the text of the card due to having no height set for the image. 2. On the dynamic carousel snippet: on mobile, a scrollbar was appearing because of the arrow buttons. task-4215589 | | Before | After | |--------|--------|--------| | Image issue |  | <img width="1394" alt="Capture d’écran 2024-10-08 à 09 01 46" src="https://github.com/user-attachments/assets/ba710372-dd08-4854-8cfd-c8c999197dca"> | | Scroll issue |  | <img width="447" alt="Capture d’écran 2024-10-08 à 09 02 25" src="https://github.com/user-attachments/assets/415aa9f3-94fd-45e1-9743-ad1ac0a3a205"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes an automated live chat test more consistent by ensuring the page is focused before a keyboard shortcut is used. It reduces random test failures, helping maintain confidence in the live chat functionality without changing the user experience.
Original PR description
In this commit, we click on element to set the focus on window before press ctrl+k. This fix an undeterministic error. 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
Deleting certain accounting records could fail when they were still referenced by saved default settings. This update corrects that cleanup logic so users can remove affected records without encountering a system error.
Original PR description
To reproduce: - Setup 2 companies. Company 1 should use the generic CoA. - Go to Accounting -> Configuration -> Chart of Accounts - Open the account 110400 Cost of Production in Company 1. - In the 'Mapping' tab, add a code for the account in Company 2. - Change the account's `company_ids` to remove Company 1 and put Company 2 instead. - Open the Chart of Accounts list view with Company 2, and try to delete the account. - A traceback appears: `psycopg2.ProgrammingError: can't adapt type 'ir.model.fields'` Diagnosis: - `ir.default.field_id` is already a recordset, so we shouldn't do `self.env['ir.default'].browse(default.field_id)` in `BaseModel.unlink()`. taskid: none
This change fixes the setup for web development tooling so it works correctly with Odoo 18 and future versions. It helps teams maintain code quality checks consistently before changes are submitted, reducing avoidable issues in development.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update aligns Enterprise tests with a fix in Odoo Community so recorded payments fully update invoices without requiring bank reconciliation. It helps ensure invoices show the correct remaining amount and payment status when users record payments in Community edition.
Original PR description
This commits only adapts tests based on the change of code of the related community PR. Message of the community PR: In Odoo Community, bank reconciliation is not available. For that reason, when recording a Payment, this should be enough to fully recognize the payment of the invoice, as there is no second "reconciliation step". In this case, we always want a "behind-the-scene" entry to be created to compute the amount_residual and the status of the invoice accordingly. After the Payments rework, the problem is that by default, no Outstanding account is set up on basic Payment Methods, not triggering any entry and messing up the computation of the invoice status. On top of that, the user can't even configure accounts on journals, as this is only possible in Enterprise edition. Outstanding accounts have also been re-instantiated as they are actually necessary in community edition. task-4224553
Fixed a display issue where section headers were hidden when customers grouped helpdesk tickets by sales order in the portal. This makes grouped ticket lists easier to read and navigate for portal users.
Original PR description
…ing by SO in portal When grouping by SO in the helpdesk ticket portal list view, the group headers were invisible. That was cause by changing the groupby options from ``sale_line_id`` to ``sale_order_id`` without changing the condition in the template that would draw the group headers. In this commit we change the condition to ``groupby == 'sale_order_id``. task-4213896
This update standardizes Mexican electronic invoicing on global rounding and fixes a rounding issue when combining multiple invoices into one global invoice. It helps ensure invoice totals and tax amounts match expected legal reporting values, reducing small discrepancies in Mexican CFDI documents.
Original PR description
[IMP] l10n_mx_edi: Remove support of round_per_line Now the round globally is fully working and since we enforced the round_globally in Mexico, let's force all Mexican users to use the round…
[IMP] l10n_mx_edi: Remove support of round_per_line Now the round globally is fully working and since we enforced the round_globally in Mexico, let's force all Mexican users to use the round globally. [FIX] l10n_mx_edi: Fix global invoice taxes aggregator with round globally When the global invoice is made on multiple invoices, aggregating rounded values lead to rounding issues. That's the case for "Subtotal" in the test case added in this commit: Suppose 5 invoices having a single invoice line with 16% price included tax. The unit price are: 2803.0, 1842.0, 2798.0, 3225.0, 3371.0. 2803 + 1842 + 2798 + 3225 + 3371 = 14039 14039 / 1.16 = 12102.586206897 ≃ 12102.59 Before this commit, when aggregating each 'Subtotal' of CFDI file, one per invoice: 2416.38 + 1587.93 + 2412.07 + 2780.17 + 2906.03 = 12102.58 [IMP] l10n_mx_edi: Cleanup dead code When introducing the dispatching on the negative lines long time ago, we added a config parameter to disable it. Now, it doesn't make any sense to disable it and the config parameter is gone so the method always returns True. Let's remove it.
This fix ensures that when a receipt is processed through the barcode app and part of a product fails a quality check, both the accepted and failed quantities are received correctly. The failed quantity is moved to the chosen failure location instead of incorrectly creating a backorder, improving inventory accuracy and warehouse workflow reliability.
Original PR description
Steps to reproduce: - Create a QP (quantity and pass/fail, also define a failure location) on a product on receipt picking type. - Create a receipt order with any quantity of this product. - Open the picking from the barcode app. - Open the quality wizard. - Fail the check. - From the second wizard, set a partial quantity and a failure location. - Confirm the wizard. - Validate the transfer. Current behavior: Only the passed quantity is added to the stock, and a backorder is created with the failed quantity. Expected behavior: The whole quantity should be added to the stock with each line moved to its corresponding location.
Original PR description
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales…
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning' in Settings > Planning - Go to Project > : Menu > 'Timesheet and planning analysis' - Under the Measures dropdown, add all columns You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet. opw-3918082
This fix resolves a system error that occurred when invoice consolidation was enabled and multiple users were assigned to subscription invoices simultaneously. The issue caused the billing process to crash with a technical error. By disabling the automatic user assignment notification during consolidation, the system now handles these scenarios correctly without interruption.
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```This fix resolves a user experience issue where the vendor dropdown menu would not close immediately when selecting an option to create a new vendor. Previously, users had to click twice to close the dropdown. Now it closes automatically on the first interaction, making the invoice extraction process smoother and more intuitive.
Original PR description
The vendor dropdown does not close when a extract box is clicked and a creation dialog opens. It would only close after the first click. In this commit the dropdown is closed straight away. Forward-Port-Of: odoo/enterprise#71039
This update corrects how quarterly tax declaration fields are submitted to Spanish tax authorities (AEAT). Previously, new fields introduced for Q4 2024 and later were left empty, but the tax authority's submission system now requires these fields to be filled with zero values instead. This ensures tax reports are properly accepted by the AEAT system.
Original PR description
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842) Forward-Port-Of: odoo/enterprise#71379
This fix corrects how product demand quantities are displayed in the Master Production Schedule (MPS). Previously, when products used different units of measurement (like dozens), the system was not properly converting the quantities, causing demand to appear incorrectly (showing 1 unit instead of 12). This fix ensures quantities are always shown in the product's correct unit of measurement.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71216
This update improves how product information appears in Ecuador electronic invoices by prioritizing the line item name in the description field. Companies that include detailed product information in invoice line labels will now see this information properly displayed in the XML format used for electronic document submission, providing better clarity and detail in official invoices.
Original PR description
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml.
This fix corrects an issue where Amazon orders containing multiple items were incorrectly creating separate shipping lines for each item, even when no per-item shipping cost was defined. Now shipping is properly consolidated, preventing duplicate and incorrect charges on customer orders.
Original PR description
If an Amazon order has more than one item it was creating for each item an own shipping line even if it had not even a shipping price defined per item line. Info: @wt-io-it