Daily updates from Odoo
Saturday, July 4, 2026
13 changes · saas-19.1
Resolved issues and error corrections
Archived document folders that are linked to projects are now excluded from automatic trash cleanup. This prevents cleanup jobs from failing and keeps project document access working correctly, including when viewing archived project folders.
Original PR description
## Problem
When a folder linked to a project gets archived, the documents trash autovacuum unlinks it along with regular trash. That triggers the constrains . This happens whether the project is still active or also archived.
## Fix
Add one leaf on the GC domain: `('project_ids', '=', False)`. so the document is not deleted if linked to a project
Forward-Port-Of: odoo/enterprise#117692Confirmed sale orders that create field service projects now assign the delivery address as the project customer. Creating projects from field service templates also avoids an incorrect default sales line, preventing setup errors.
Original PR description
FIX 1: industry_fsm_sale: set delivery address on project customer] ----------------------- **Steps to reproduce:** - Create a product: - Product Type: Service - Service Tracking: Create on Order…
FIX 1: industry_fsm_sale: set delivery address on project customer] ----------------------- **Steps to reproduce:** - Create a product: - Product Type: Service - Service Tracking: Create on Order (project) - Project Template: FSM type project template - Confirm a sale order with this product - Check the generated project customer **Issue:** The customer's delivery address is not set on the generated project. **Fix:** Set the delivery address as the project customer when creating the project. [FIX] industry_fsm_sale: remove default sale line in fsm projects ------------ **Steps to reproduce:** - Install industry_fsm_sale - Create a project template of fsm type - Create a sale order (service-type product) - Confirm the sale order - Create a project and select the fsm-type project template - Create the project **Issue:** - SQL constraint is triggered, preventing project creation. **Fix:** - If the project template is of fsm type, remove the default sale line from the context. task-5074893 Forward-Port-Of: odoo/enterprise#95920
Belgian CODA bank imports now use the full payment communication as the transaction reference when no structured reference is available. This makes imported bank transactions easier to identify and match, reducing manual reconciliation effort.
Original PR description
### Issue: When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref Causing difficulty to match with the transactions ### Cause: For simplicity reason, the payment_ref and the communication where different The `payment_ref` was fetched once and replace The `communication` was always completed by new lines ### Steps to reproduce: - Install `l10n_be_coda` - Set the account on the Bank Journal to GR5605700000000928073840752 - Import the Simplied CODA (On the ticket) from the bank dashboard Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter opw-6245848 Forward-Port-Of: odoo/enterprise#122344 Forward-Port-Of: odoo/enterprise#120536
Signing now preserves the original look of PDFs by locking existing interactive form fields instead of flattening them in a way that could change their appearance. This prevents users from editing those fields during signing while reducing the risk of visual issues in signed documents.
Original PR description
Currently, we flatten fields in a naive way which does not handle many edge cases and can alter the PDF appearance for users. We could use pypdf to handle production-grade flattening, but Odoo's `pypdf` dependency (5.4.0) does not support native form field flattening (which was introduced in 5.8.0). To resolve this, rather than flattening, we lock the interactive fields so they are no longer editable while signing, which perfectly maintains the original appearance. In the future, when we support higher pypdf versions, we can truly flatten the PDF to provide a better user experience. task-6037759 Forward-Port-Of: odoo/enterprise#112351
Users with limited permissions can now open the Preparation Display app without seeing an access error. The app now opens the display page directly, avoiding an extra step that required permissions those users do not have.
Original PR description
A recent fix in the base module requires users to have "write" access on ao model to execute its server actions. commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`. However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display. This commit bypasses the intermediate server action and opens the URL action directly. Task-6311320 Forward-Port-Of: odoo/enterprise#121293
The timesheet view now correctly marks days as unavailable based on the current employee's working schedule when users open their own timesheets. This prevents employees from accidentally entering time on days they are not scheduled to work.
Original PR description
To reproduce: ============= - modify Mitchel Admin's working schedule and remove a day of work - open timesheet app as Mitchel Admin - the removed day is not grayed out as unavailable Porblem: ======== the method `get_unavailabily` was handling only the case when calling it with `groupby=employee_id` otherwise it returns the company's unvailability Solution: ========= when the "My Timesheet" action is opened, the method `get_unavailabily` is now called with a specific context key, allowing to return the current user's unavailability instead of the company's one. opw-5949236 Forward-Port-Of: odoo/enterprise#122720 Forward-Port-Of: odoo/enterprise#113984
This update corrects a technical error that occurred when managing employee leave periods with overlapping versions. Specifically, a missing method in the HR system caused a traceback when changing an employee's schedule. This fix ensures leave management functions correctly under these circumstances, preventing disruptions to employee time tracking.
Original PR description
**Steps to reproduce the issue:** - Create a leave for an employee with a period that overlaps with two versions. - Change the employee's working schedule. - You get a traceback. The issue is that the definition of the `_update_leave_state` method is missing from the `hr.version` model. task-6332404 Forward-Port-Of: odoo/odoo#272060
This fix ensures that mass mailing unsubscribe links direct recipients to the correct website based on their company affiliation. Previously, the links pointed to the main company's login page, regardless of the contact's company. This update corrects the URL generation process, guaranteeing accurate redirection for a better user experience.
Original PR description
In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page. ### Steps to…
In a multi-company setup with a website per company, the unsubscribe link in mass mailing emails could send recipients to the login page instead of the unsubscribe confirmation page.
### Steps to reproduce
1. Enable multi-company and create a second company `Company B`.
2. Create two websites with different domains, one per company:
- `Website A` on the main company, domain `http://website-a.test`
- `Website B` on `Company B`, domain `http://website-b.test`
3. Set the system parameter `web.base.url` to `http://website-a.test`. System parameters are global, so this value applies to the whole database regardless of the company you switch to.
4. Create a contact and set its `Company` field to `Company B`.
5. In Email Marketing, create a mailing with recipient model `Contact`, target the contact above, pick any template with an unsubscribe link, and send it.
6. Open the email in an incognito window and click the unsubscribe link: you land on the login page instead of the unsubscribe page.
### Cause
Mass mailing builds the unsubscribe link in two steps.
First, each email body is rendered for its recipient. While rendering, relative URLs like `/unsubscribe_from_list` are turned into absolute URLs by prepending a base URL. That base URL comes from the recipient record itself: `recipient.get_base_url()`. The `website` module overrides this so that, when the record has a company, it returns that company's website domain. For a contact in `Company B`, the body ends up with `http://website-b.test/unsubscribe_from_list`.
Second, right before sending, `mail_mail._prepare_outgoing_list` replaces that placeholder URL with a per-recipient signed URL pointing to `/confirm_unsubscribe`. It does this by plain string replacement: it looks for `{base_url}/unsubscribe_from_list` in the body and swaps it. The `base_url` used here came from `self.mailing_id.get_base_url()`. A mailing has no company, so its base URL falls back to the global `web.base.url`, which in our setup is `http://website-a.test`.
The two base URLs no longer match. The body contains the website B URL, but the replacement code searches for the website A URL. The search fails, the placeholder stays in the email, and the recipient clicks a link to `/unsubscribe_from_list`. That route only redirects to `/mailing/my`, which requires being logged in, so the user lands on the login page.
### Fix
Compute the base URL from the recipient record (the same record used when rendering the body) instead of the mailing. The two URLs then agree and the replacement works. Fall back to the mailing's base URL if there is no recipient model on the mail.
opw-4914203
Forward-Port-Of: odoo/odoo#273583
Forward-Port-Of: odoo/odoo#264055This update fixes an issue where dialogs opened from Kanban quick creates would unexpectedly close when switching tabs. Now, dialogs remain open and functional, ensuring a smoother user experience when navigating between Kanban views and creating related records. This enhances usability and prevents data loss.
Original PR description
similar fix: https://github.com/odoo/odoo/pull/181220 - On a kanban view, click "New" to open a quick create record; - On a many2one field, type a value and click "Create and edit..."; - A dialog…
similar fix: https://github.com/odoo/odoo/pull/181220 - On a kanban view, click "New" to open a quick create record; - On a many2one field, type a value and click "Create and edit..."; - A dialog opens to create the related record; - From that dialog, open another many2one field the same way, so a second dialog opens on top of the first one; - Change tab in the browser. Before this commit, the quick create's `beforeVisibilityChange` handler unconditionally validated and closed itself as soon as the tab became hidden, with no regard for what was happening around it. Since the "Create and edit" dialogs are owned by the field widgets living inside the quick create (`useOwnedDialogs`), closing the quick create also close those dialogs, with no action from the user. This reuses the `formInDialog` counter already relied on by `FormController` for the same kind of issue: the quick create now listens to the same `FORM-CONTROLLER:FORM-IN-DIALOG` bus events, and only validates/closes itself on visibility change once every dialog opened from it has been closed. opw-6357255
This update fixes issues where project templates weren't correctly associated with sale orders and allowed selection from incorrect companies. It now ensures project templates are displayed based on the sale order's company or are universally available, improving project creation workflows and data accuracy. This resolves inconsistencies in how project templates were presented.
Original PR description
Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project --------------------- **Issue:** When a project is created from the sale app, it is not billable by default,…
Fix 1 : project, sale_timesheet: remove default_allow_billable context in Create a Project --------------------- **Issue:** When a project is created from the sale app, it is not billable by default, and the sale order / sale order line are not set. **Fix:** Remove default_allow_billable = False in the Create a Project **Note:** default_allow_billable = True already exists in action_view_project_ids, but that default context is replaced when opening the project directly from the view. This happens because default_allow_billable = False is set in the Create a Project action. Fix 2: sale_project: show only relevant project templates per company ---------------- **Steps:** - Install sale_project - Create two companies (A, B) - Create three project templates: - Template A (company A) - Template B (company B) - Template C (no company → visible to all) - Create a sale order for company A with a service product - Confirm the sale order - Create a project and try to select a template **Issue:** All project templates were visible even if the sale order had a company set. **Fix:** Added a filter (domain) on the project template field so only templates for the sale order’s company or templates with no company are shown. Users cannot select templates from other companies. fix 3 : crm_sale_project: show only relevant project templates per company -------------------------------------------------------------------------------- Steps: - Install crm_sale_project - Create two companies (A, B) - Create three project templates: - Template A (company A) - Template B (company B) - Template C (no company → visible to all) - Create a lead for company A - Create a project and try to select a template Issue: All project templates were visible even if the lead had a company set. Fix: Added a filter (domain) on the project template field so only templates for the lead’s company or templates with no company are shown. Users cannot select templates from other companies. task-5074893 Forward-Port-Of: odoo/odoo#229309
This update fixes an issue where increasing the amount of an online payment didn't correctly update the order on the server. Now, adding an online payment line automatically syncs the order, ensuring the customer's payment information is always accurate and up-to-date.
Original PR description
When an online payment line is added, the order is synced to the server so the customer can pay it online. This sync was only performed when the order did not yet exist on the server (string id). As a result, once an order had already been synced, modifying it (e.g. increasing the amount) and adding the online payment line again did not push the new amount to the server. opw-6314690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272961 Forward-Port-Of: odoo/odoo#271542
This update significantly improves the speed of closing Point of Sale sessions, particularly when using 'Identify Customer' for bank payments. Previously, closing a session with many payments could take over 10 minutes, but now it completes in approximately 75 seconds. This change reduces processing time and improves overall system performance.
Original PR description
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method (the client reporting the issue had 1700), and put a customer on each order. 3. Close the session. With "Identify Customer" enabled, closing the session creates one `account.payment` for each payment and posts it one by one, then reconciles each payment separately. With many payments this is slow and the close takes several minutes and the worker is stopped by its time limit, so we get the error "Cursor already closed". Now we create and post all these payments at once in a single batch, and reconcile the payments in one call too. Benchmark --------- These numbers come from closing a session that has 1700 orders paid with such a payment method, on a test database: - before: the close did not finish after more than 10 minutes. - after: the close takes around 75 seconds. opw-6242303 Forward-Port-Of: odoo/odoo#269306
This update fixes issues where scanning employee badges during login wasn't working correctly, specifically when using a PIN. The changes ensure that badge scans are properly recognized as PIN inputs, allowing users to seamlessly log in with their badges and resolve 'Wrong PIN' errors. This improves the overall login experience for PoS employees.
Original PR description
See commit messages. [[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3) [[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014) (Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff) [[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92) opw-6125029 Forward-Port-Of: odoo/odoo#273838 Forward-Port-Of: odoo/odoo#262474