Daily updates from Odoo
Thursday, July 3, 2025
18 changes · master
New functionality added to Odoo
Adds check printing layouts tailored for Dominican Republic payments. This helps businesses in the Dominican Republic print compliant checks directly from Odoo, reducing manual formatting and payment processing effort.
Original PR description
Essentially a copy of the l10n_us_check_printing module, adjusted to work with DO stuff. The layouts is adjusted to qualify as 'vaguely matching the target check layout', which I was told is enough.
Concern: I can't fit the layout closer without being able to overlay it over an example blank check background.
Concern: The width of partner address lines (ckdo_payee_addr class in print_check.xml) is a bit too limited (so even Azure Interior's ordinary address turns into a vertical mess) by the generic address line widget ir_qweb_widget_templates.xml -> <template id="contact">. Adding a width parameter directly to .ckdo_payee_addr{} in report_check_*.scss solves this, but it doesn't seem like the correct solution.
task-4290725
Forward-Port-Of: odoo/enterprise#88967
Forward-Port-Of: odoo/enterprise#75498Enhancements to existing features
Front desk host and responsible user choices are now limited to people from the selected company, reducing mistakes in multi-company setups. The update also clarifies selection options and ensures notifications reach hosts through the right available channel.
Original PR description
The purpose of this change is to ensure that hosts and responsible users are selected only from the appropriate company in a multi-company environment. This PR includes the following changes: - Added a Hosts field restricted to employees of the selected company. - Made the Hosts field visible only when the Host Selection checkbox is enabled. - Restricted Host Selection to the hosts of the selected station. - Updated the Responsibles field to allow selection only from users in the same company. - Added tooltips for Host Selection and Responsibles to clarify their purposes. - Updated the /get_hosts API to enforce host selection restrictions. Task - 4657837
Starshipit shipping labels no longer block delivery confirmation when the final shipping cost is not immediately available. Odoo temporarily records a zero cost, then automatically retrieves the final price later and updates both the delivery and related sales order so customers and staff see the accurate charge.
Original PR description
**Description of the issue/feature this PR addresses:** This PR enhances the Starshipit integration to reliably handle scenarios where the exact shipping cost is not immediately available from…
**Description of the issue/feature this PR addresses:** This PR enhances the Starshipit integration to reliably handle scenarios where the exact shipping cost is not immediately available from Starshipit after label creation. Cost is fetched via a cron job and correctly applied to both the stock.picking's carrier_price and, crucially, the corresponding Sales Order delivery line. First commit removes the 3-tries loop, and was already reviewed on this [PR](https://github.com/odoo/enterprise/pull/85088). **Current behavior before PR:** When confirming a picking with a Starshipit Delivery method, the exact Shipping cost was not instantly available. The previous code had 3 attempts to retrieve it, before stopping the process, asking the user to try at a later time. **Desired behavior after PR is merged:** The price fetching becomes non-blocking. If Starshipit did not return an immediate `total_shipping_price`, a temporary price of 0.0 will be used. A Cron job will then run on all pickings with a 0.0 carrier price in order to fetch the exact price from Starshipit, and update the SO delivery lines. opw-4748113 When merging on `master`, further improvement might be to introduce a `starshipit_pending_price` boolean field instead of running the CRON job on all 0.0 carrier price pickings. With the new view `view_picking_form_inherit_stock` being introduced, runbot tests fail when migrating to saas-18.1. (Because view is not yet present in the saas-18.1 codebase) **How to test?** - On a runbot DB, install the `delivery_starshipit` module - Configure the DB to interact with the connector - Place a Sales Order with a delivery method configured to use Starshipit. - Confirm the Delivery. The shipping price, if not available, will be temporarily set to 0.0. - Run the Cron Job manually. You can check and activate the Cron by navigating to Settings > Technical > Automation > Scheduled Actions. - Check that the SO has been updated with the actual shipping price from Starshipit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#89184 Forward-Port-Of: odoo/enterprise#86383
Website administrators can now open the website generator directly from the website settings. This makes it easier to import or set up a website at any time, without needing to go through the initial onboarding flow.
Original PR description
Added a button in the website settings that redirects to the website generator configurator. The goal is to have a standart way to import a website without necessarily behing part of the onboarding flow.
The salary package page now keeps the salary section visible while users scroll through related benefits and personal information. This makes it easier for employees or HR users to review compensation details alongside the rest of the package without losing context.
Original PR description
this commit makes the salary section sticky in the whole page. Some CSS tweaks were applyied along with some tweaks in the template to make it possible. Most important change is to make the `salary_package_benefits` , `salary_package_sidebar` and `salary_package_personal_information` inside the same `div` to make the sticky effect work properly. task-4878562
The AI module can now build assistant guidance dynamically from templates, making future AI agents easier to tailor to different business situations. This lays groundwork for more context-aware AI features, such as natural language search, while keeping the current change mostly internal.
Original PR description
- I see `ai.agent._generate_response` as an entry point to communicating with the agent, whether we want the direct response from the llm or the user chats with the agent. - In the future, we'll be introducing different types of `ai.agent`, each has its own responsibility. E.g. the natural language search feature will have a custom ai.agent for it. It will have it's own set of dynamic system prompts (computed based on the situation). I propose these dynamic system prompts to be defined as qweb templates which are rendered when system messages are computed. - [ ] tests for the html_to_markdown function
Financial reporting now avoids creating temporary database tables and views for budget and analytic analysis, using direct queries instead. This should make those reports easier to run on read-only database servers and reduce database overhead, without changing report content.
Original PR description
- temporary view for the analytic groupby replaced by a query directly - temporary table for the budget also replaced by a query directly - temporary table for cash_basis not replaced as we are not sure about the impact We can also use readonly servers for budget and analysis as we dont need to create a table/view task-4841765
Resolved issues and error corrections
This fixes an error that could appear when adding a rental product with variants to a renewed subscription before rental dates were set. The product configurator now only uses rental dates when they are actually available, preventing interruptions in the renewal flow.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a rental product with multiple variants; 2. create a subscription order via the Rental app; 3. add the rental product; 4. confirm & invoice the subscription; 5. renew the subscription; 6. add the rental product to the renewal. Issue ----- > `Uncaught Promise > value.setZone is not a function` Cause ----- Commit 76526bdb3835 implemented the `_getAdditionalDialogProps` method for using OWL in the product configurator. In our flow, it simply checks whether the order is a rental order, and if so, it attempts to serialize its rental dates. Issue is that rental dates are not a required field as long as the order hasn't been confirmed yet, causing the traceback. Solution -------- Instead of checking whether it is a rental order, verify that the order has rental dates before attempting to serialize them. opw-4898437 Forward-Port-Of: odoo/enterprise#89016 Forward-Port-Of: odoo/enterprise#88629
This fix updates the Mexican payroll salary rule conditions so employee subsidy calculations apply only when appropriate. It helps payroll teams produce more accurate payslips and reduces the risk of incorrect subsidy amounts.
Original PR description
task-4690544 Forward-Port-Of: odoo/enterprise#89067 Forward-Port-Of: odoo/enterprise#84780
This fixes an error that could block payslip generation for Mexican employees whose pay is entirely variable, such as commissions or bonuses without a fixed base salary. Payroll teams can now generate these payslips more reliably, avoiding manual workarounds and processing delays.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89212 Forward-Port-Of: odoo/enterprise#85756
EasyPost delivery labels now include the Odoo delivery reference, making it easier to match carrier shipments with the correct Odoo delivery. This helps users identify and reconcile shipments more quickly in both Odoo and the carrier dashboard.
Original PR description
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the…
Issue ----- When using the Easypost delivery service, we don't pass the move reference to the carrier. This makes it hard for the user to match the deliveries found on the carrier dashboard with the corresponding Odoo move. Steps to reproduce ----- - Set an Easypost delivery method up - Create a sale - Add delivery product & get a rate - Confirm the sale - Go to the linked delivery & confirm it --> The printed label has no reference field Discussion ----- As per EasyPost: > The reference field within the shipment body is used for transmissions of electronic data between the shipper and EasyPost, and typically does not get expressed anywhere on the physical label. To get data to the label, you need to leverage the "print_custom" fields outlined in the options section of the shipment. See also https://docs.easypost.com/docs/shipments/options Visual comparison ----- DPD UK labels, before and after the change:  USPS labels, before and after the change:  ----- Ticket: opw-4681615 Forward-Port-Of: odoo/enterprise#88941
This fix prevents payroll batch processing from failing when an employee has multiple version records returned during grouped payroll calculations. It helps payroll users complete payslip runs more reliably without encountering an unexpected error.
Original PR description
As we are using a read_group, that return an agregate of records, version may contain multiple version. If you get multiple records, you get a singleton error when trying to read date_version of version. So we append all version records into the all_employee_versions dictionnary Forward-Port-Of: odoo/enterprise#89143
OCR invoice processing now better handles multiple documents from the same supplier being processed at the same time. This prevents duplicate supplier contact records, improving data quality and reducing manual cleanup.
Original PR description
When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it. This typically happen when the update of the documents is done…
When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it.
This typically happen when the update of the documents is done through the webhook.
In that case, the different SQL transactions overlap each other and can't "see" the partner created by another request.
There are two kind of SQL transactions overlap that need to be handled:
- The partner creation is overlapping:
```
------------------------------------------------------------------> time
BEGIN INSERT COMMIT
T1: [ |-----------]
BEGIN INSERT COMMIT
T2: [ |----------]
```
This case can be handled by using an advisory lock on the VAT number of the partner to create. If the lock isn't available, it means the partner is being created concurrently and the transaction should be retried.
- The partner creation isn't overlapping:
```
------------------------------------------------------------------> time
BEGIN INSERT COMMIT
T1: [ |-----------]
BEGIN INSERT COMMIT
T2: [ |----------]
```
In that case, `T2` would be able to acquire the lock fine, but it can't see the partner created by `T1` in its main SQL transaction.
To fix this, we re-check the presence of a partner in a **new** SQL transaction.
The combination of those two mechanisms should ensure that no duplicated partners can be created.
task-[4904333](https://www.odoo.com/odoo/project/2068/tasks/4904333)Fixed Chilean electronic factoring documents so the assigned amount is always reported in Chilean pesos, even when the invoice uses another currency. This prevents incorrect AEC XML values and helps ensure documents sent to the tax authority match local requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MontoCesion tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on `Send Now to SII` and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MontoCesion is in selected currency which is wrong opw-4830957 Forward-Port-Of: odoo/enterprise#88175
Bookkeeper users can now process automatic follow-ups and manual reminders even when a customer is missing required contact details such as an email or address. This prevents access errors and helps accounting teams continue debt collection workflows without unnecessary interruptions.
Original PR description
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic…
Before this commit, a Bookkeeper user wasn't able to create a followup for a user with missing information (email or address) That error append using the manual_reminder and the Process Automatic Follow-ups For the Automatic Follow-ups action, the user wasn't able to access the 'missing information view' For the Followup Button (manual_reminder), that's in the follow-up report view, the user wasn't able to access either the 'manual_reminder view' or the 'missing information view' ## Steps in runbot 17.0: - Create an invoice with a past due date and a new customer (leave email empty) - Go in Accounting > Customers > Follow-up Reports - Select the In need of action report for your new customer - In Actions, click on Process Automatic Follow-ups - An AccessError should be displayed ## To test the manual reminder: - Create the invoice as before and go to Follow-up Reports - Open the report linked to your new customer - Click on the Follow up Button - An AccessError should be displayed opw-4848745 Forward-Port-Of: odoo/enterprise#88168
This update removes an outdated internal access-rule mechanism and adjusts several reports and workflows to use the newer approach. It helps ensure users see the right information consistently, especially in appraisal workflows where access could depend on cached data.
Original PR description
task-4067945 odoo/odoo#191775
CSV bank statement imports now continue more reliably by moving automatic reconciliation to a background process. The fix also prevents two imported lines from being matched to the same reconciliation candidate, reducing import failures and incorrect matches.
Original PR description
When doing an import of a csv in the bank rec widget, it could happens that the try_auto_reconcile throw an error which will lead in the rollback of the import. By triggering the schedule action auto_reconcile_bank_statement_line we will do the try_auto_reconcile in the back ground which will speed up the import process When importing, we pass a batch of statement lines to the try_auto_reconcile function, which identifies possible reconciliation candidates for each line. The issue arises because we iterate through each statement line and assign its potential candidate without checking for conflicts: if two statement lines map to the same candidate, we don’t verify whether that candidate has already been reconciled with a different line. opw-4888045,4890008 Forward-Port-Of: odoo/enterprise#88529
Fixed an issue where customized employee contract signing links could fail to open after generating an offer. The signing process now uses the correct signer-specific access token, helping applicants and employees complete contract signatures without interruption.
Original PR description
Steps to Reproduce: - Create a new contract template. - Define signatories to it(pref: employee) - create a offer linked to an applicant and try generating a offer and signing Fix: - Since the sign creating new role every time when we add new signer, we can't use the existing employee role id anymore. - Hence we will get the access token from signatory linked with the signer in the contract template and use that. task-4894597 Forward-Port-Of: odoo/enterprise#88953 Forward-Port-Of: odoo/enterprise#87420