Daily updates from Odoo
Friday, January 10, 2025
17 changes · 18.0
Enhancements to existing features
The web domain field now limits how many records it counts when checking filter results. This avoids slow responses on very large datasets while keeping users informed enough to continue configuring filters.
Original PR description
Executing a search count on a table with a large number of records can be slow, which is why a limit was added on b37d221e. The same issue exists on the domain field widget, and so the same solution is applied here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor's snippet search now helps users find building blocks by their technical names or styling classes, making review and testing faster as the snippet library grows. The update also improves search responsiveness and fixes an issue where the Custom tab could disappear after searching.
Original PR description
With the increasing number of snippets and their potential option classes, it became even more important to be able to search for them quickly while reviewing / testing features (... we really would like to restore the search for inner snippets too if it was accepted ...).
This commit improves the snippet search. If the search starts by 's_', it will:
- Also match any snippet whose root or child nodes have a class that begins by the search term.
- For those extra matches, sort them by:
- Exact XMLID match first
- Exact class match on the root node first
- Partial class match on the root node firstUsers will no longer see the real-time connection lost warning immediately during brief network interruptions. The warning now appears after 15 seconds, while a subtle spinner indicates reconnection attempts right away, reducing unnecessary alerts without hiding connection issues.
Original PR description
Before this PR, the "real-time connection lost" alert was displayed right after the disconnection was detected. This PR adds a 15s delay to avoid spamming the alert on unstable connexion. Task-4453176
Sales commission results now focus on the currently selected company, making figures clearer for multi-company users. Sales users can update their own forecast values, commission screens have been refined, and copying commission plans no longer triggers an error.
Original PR description
Display commission of current company only Allow sale user to edit the forecast value Various UI improvements taskid: 4452731
Resolved issues and error corrections
Fixes an issue where adding a dropshipped product to a purchase order created from a subcontracted service incorrectly generated a warehouse receipt instead of a customer delivery. Sales orders are now properly updated when those dropshipped items are processed, reducing manual corrections and fulfillment errors.
Original PR description
If the user adds a product to a PO generated for a sold and subcontrated service, the picking will be a receipt and the related SO will not be updated To reproduce the issue: 1. Create a service S: -…
If the user adds a product to a PO generated for a sold and subcontrated service, the picking will be a receipt and the related SO will not be updated To reproduce the issue: 1. Create a service S: - Add a new vendor V - Subcontracted Service: True 2. Create a product P: - Vendor V - Routes: Dropship 3. Create and confirm a SO with 1 x S 4. Add 1 x P to the PO 5. Confirm the PO - Error 01: it generates a receipt while a dropship is expected 6. Process the receipt - Error 02: the SO does not change while a new SOL for P1 is expected If the initial SO had P, it would work correctly. The user could even add a second dropshipped product before confirming the PO, the picking would be a dropship and there would be some new SOL for the dropship products. When confirming a SO, the process that generates the PO depends on the SOL. If at least one of them is a product, the stock rule mechanism will always handle the situation since it is called before the `super`: https://github.com/odoo/odoo/blob/899878f8e4d61de6b7bb6e4799a3e97e8d9f4434/addons/sale_stock/models/sale_order.py#L176-L178 while, service side, we generate the PO after `super` https://github.com/odoo/odoo/blob/706431510110a005618a2acaf6566f2bb61d5114/addons/sale_purchase/models/sale_order.py#L20-L24 And, good news, everything works correctly when the PO is created by the stock rules. However, when creating a PO for a sold service, we have few mistakes. First, we don't provide any operation type: https://github.com/odoo/odoo/blob/238a41e35280256382f6509182b9e900fb4f7aba/addons/sale_purchase/models/sale_order_line.py#L131-L141 We therefore use the default one, a receipt: https://github.com/odoo/odoo/blob/f9381a0611207e0fec6b957aef3b160437ecbafb/addons/purchase_stock/models/purchase_order.py#L23 We don't provide any destination address either, as explicitly said by the comment: "False since only supported in stock". All this could make sense as long as we don't add any product. If we do, we will then have an issue with the picking: error 01. The PO has been created to subcontract a service to a customer. It's a dropship-like situation. We should therefore anticipate the situation and set some correct values in case we add some products. Then, when processing the picking, we update the related SO in some conditions: https://github.com/odoo/odoo/blob/84d2c884300f090103b917b8911d82dbeac9279e/addons/sale_stock/models/stock.py#L119-L130 Fixing error 01 solves a part of the conditions: we now have a correct destination location. However, we still don't have any SO linked to the picking. This info actually comes from the group: https://github.com/odoo/odoo/blob/84d2c884300f090103b917b8911d82dbeac9279e/addons/sale_stock/models/stock.py#L87-L90 However, when confirming the PO, it leads to the picking creation. To do so, we directly create the missing group but we don't provide any value for `sale_id`: https://github.com/odoo/odoo/blob/f9381a0611207e0fec6b957aef3b160437ecbafb/addons/purchase_stock/models/purchase_order.py#L259-L264 OPW-4332074
Customers using POS self-invoicing could encounter an error when opening the portal page from the receipt QR code. The update prevents the page from failing when optional invoicing information is not present, allowing the self-invoicing flow to continue normally.
Original PR description
Steps: - Enable the self-invoicing option from Configuration → Settings → Bills & Receipts. - Open the POS system. - Create an order and validate it. - Scan the QR code for self-invoicing displayed on the receipt. - The QR code opens the portal. Issue: - A traceback error appears when opening the page. Cause: - A problem in the `account_peppol` module was causing it to search for an element on the page that wasn’t available. Fix: - Included a condition such that If the element isn’t found, it skips the step and assigns a null value to the variable, resolving the error. Task: 4438885
Wave transfer preparation now excludes stock move lines that are not linked to a picking. This prevents users from selecting invalid items that would cause an error when adding them to a wave transfer.
Original PR description
### Steps to reproduce: - In the settings enable: 1) Multi-Steps Routes 2) "Batch, Wave and cluster Transfers" - Inventory > Operations > Jobs > Wave transfer - Click on "Prepare Wave". > A read group of the stock.move.line model is performed for you to compose your wave transfer. ### Issue: Move lines without picking are also displayed. Hence if selected raise a traceback during the `_add_to_wave` call. ### Note: The `action_prepare_wave` and `action_prepare_wave_for_picking_type` actions performing the read groups were added to the 18.0 versions by commit 71eeeae5c7212a709c0b18181d195975b5ca6a99 so that there is no issue prior to that version. opw-4464695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents parts used in a repair order from being counted again when the related payment is processed through Point of Sale. It helps keep inventory accurate by ensuring repair materials are only consumed once.
Original PR description
When creating a repair order, and paying it with a POS order, the product from the repair order would be consumed twice, once when creating the repair order, and once when validating the POS order. So we end up with 2 stock moves for the same product. Steps to reproduce: ------------------- * Create a repair order for any product * Add product A to the part list * Start and end the repair (at this point one stock move is created) * Create a quotation for the repair order * Open PoS and settle the quotation * Validate the PoS order, and check the stock moves for the product A > Observation: You can see one more stock move for the product A coming from the PoS order Why the fix: ------------ We make a similar fix as this one https://github.com/odoo/odoo/pull/186812 to prevent the creation of stock moves when the product is coming from a repair order. opw-4351266
Discuss calls now move users onto the latest call connection when a channel is updated, preventing people from being left behind on an outdated connection. The update also makes partial audio connection issues easier to spot so teams can identify call problems faster.
Original PR description
Before this commit, if a discuss channel was provided a new sfu channel, users that were already in a call on that old sfu channel would stay there instead of moving to the new one. This commit also adds an icon if a rtc session is missing an expected `audioStream` so that it becomes easier to notice if a partial connectivity issue arises.
This fixes an Accounting error that could block users from opening an account from the Chart of Accounts when one of their branches had been archived. Users can now view accounts normally without being stopped by an unauthorized company access message.
Original PR description
**Steps to reproduce:**
- Install Accounting
- Create a branch
- Archive the branch
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Click on the "View" button of any account
**Issue:**
An AccessError is raised:
"Access to unauthorized or invalid companies."
**Cause:**
The "account.code.mapping" records are fetched for all the companies of the current user, even the archived ones.
{'active_test': False} is added in the context in the read method of the One2many class in fields.py
opw-4450588
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix limits record counting in the domain field widget so screens remain responsive when working with very large datasets. Users should see fewer slowdowns when building or editing filters that would otherwise scan many records.
Original PR description
Executing a search count on a table with a large number of records can be slow, which is why a limit was added on b37d221e. The same issue exists on the domain field widget, and so the same solution is applied here. 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 corrects Belgian payroll reporting so required declarations better reflect contract timing and include applicable structural reductions in owed amounts. It also avoids unnecessary encryption during tests, helping payroll processing and validation run more reliably.
This fixes several appointment and restaurant booking interface issues, making key actions, translation controls, timezone fields, and Google Calendar connection messages clearer. It also prevents unnecessary activities and incorrect admin attendees from being added to bookings, improving calendar accuracy and reducing confusion.
Original PR description
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event…
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event linked with appointment type. This PR exclude appointment model in valid_activity_model_ids using helper function, so we won't get any activity on appointment type. (See community commit.) 3) The 'Connect Google' button with info and warning it's too vague for users. Add new warning when there are no creds but Google Calendar is Installed. Show old warning + info if creds are found but not synced. 4) The translation icon is badly positioned, it should be inside the field. 5) On Appointment Resource Create, Make Timezone field invisible if there is no resource_id. 6) When creating a booking in POS, the admin is always set as an attendee, becuase default for `default_partner_ids` was set to current user on create, which is not correct. 7) Change booked_mail_template_id field's name to 'Booking Email', as it may contain mail for appointment event which yet to be confirmed. Task-4243603
Users can now copy documents even when they do not have permission to edit the original folder. In those cases, the copied files are placed in My Drive and a notification explains what happened, avoiding access errors and batch-copy crashes.
Planning users can now delete recurring shifts more consistently from the Gantt popover, matching behavior already available elsewhere. This makes shift management clearer and helps avoid incomplete recurrence updates when deleting scheduled work items.
Original PR description
As of now the gantt popover delete button is added through gantt-popover template which is making it harder to extend its functionality. In this PR we move the button to the ganttPopoverProps. We can pass the button through JS side, thus being to extend it's functionality of reccurence deletion. Made a dedicated hook function to combine the logic used in both form and gantt view in reccurence deletion of shifts. The unschedule gantt popover button is migrated to JS side to preserve the order of buttons in gantt popover. task-4224792
Helpdesk teams in a second company can now open their website form without hitting an access error. This makes it easier for multi-company users to manage customer support forms from the Helpdesk app.
Original PR description
Steps to reproduce: 1.) Create a trial db 18.0 2.) Install website and helpdesk 3.) Create a second company (two companies, one website, may have to delete a website) 4.) Navigate to a Team in 'Helpdesk / Teams' with company B 5.) Enable 'Website Form' 6.) Use 'Go to Website' smart button 7.) We get an access error - Remove multi_website group and add conditional to stat button
This fix ensures the Italian Point of Sale starts with the company's required partner information already loaded. It helps prevent unexpected POS errors related to fiscal operations, especially where Italian POS requirements depend on that company partner data.
Original PR description
Before this commit, it could happen that the partner associated to the current company was not automatically loaded at the start of the POS session. Since this parter is required for proper operation of l10n_it_pos, it could lead to unexpected errors. After this commit, the partner is explicitly force-loaded at the start of the POS session to ensure proper operation. opw-4394672 Linked community PR: https://github.com/odoo/odoo/pull/193123