Daily updates from Odoo
Tuesday, July 22, 2025
8 changes
Enhancements to existing features
Closed subscriptions can no longer be reopened through the portal when more than one billing period has been missed. Customers now see the amount due when reopening is allowed, or a message to contact their sales manager when payment is blocked.
Original PR description
Before, The portal allowed to reopen closed subscriptions without checking how many billing periods were overdue. - The amount to pay was not clearly displayed. - The number of missing periods was incorrectly computed (X instead of X + 1). After this commit, - Blocking the payment option when more than one billing period is overdue (i.e., next_invoice_date + 1 period < today). - Displays a message to contact the sales manager if multiple billing periods are missed. - The payable amount is displayed when reopening is allowed. task-4724154
The HR Documents app replaces the old action for sending an HR access link with a more flexible email-sending option. This lets users send different types of HR-related emails from documents, improving communication workflows for employee records.
Original PR description
With this commit; the old server action "send hr access link" is replaced by "send email" to allow the user to send differents kind of email. task-3927412
Brazilian product tax setup now supports Avalara exception codes for NCM classifications. This helps businesses handle special tax rules, reduced rates, and benefits more accurately when calculating taxes through Avalara.
Original PR description
Added support for Avalara's EX Citations to handle tax exceptions for products with special tax rules (e.g., ICMS, IPI, PIS, COFINS), such as reduced rates or special benefits. It simplifies tax setups and improves calculation flexibility. In this commit: --- - Added an `EX` field to the NCM model to capture Avalara's exception codes. - Integrated EX field with Avalara tax calculations. - Updated NCM form view to include the EX field. task-4929018
IoT boxes can now use a direct browser connection through WebRTC when the user is on the same local network. This can improve responsiveness for IoT interactions while keeping existing connection methods as a fallback when WebRTC is unavailable.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/218871 This PR adds a third connection type to the IoT box, using the WebRTC protocol. This commit handles the browser side of the connection. The…
Community PR: https://github.com/odoo/odoo/pull/218871 This PR adds a third connection type to the IoT box, using the WebRTC protocol. This commit handles the browser side of the connection. The WebRTC connection is added as a third connection type to the existing `iot_http` service, with the highest priority. The first time it is used, the connection will not be open yet so it will fail, but will begin establishing the connection in the background. The next time an IoT message is sent, it can use the WebRTC connection. We use the Browser APIs `RTCPeerConnection` and `RTCDataChannel` to setup the WebRTC connection to the IoT box. The flow is as follows: 1. Browser creates an `RTCPeerConnection` instance, generates an 'offer' and sends it to the IoT box via the existing WebSocket connection. 2. The IoT box receives this offer, and sends us back an 'answer', again via the WebSocket connection. 3. At this point the browser will automatically establish the connection to the IoT box. Any future calls to `iot_http` will use this connection (unless it fails, in which case it will fallback to the other connection types as before). This implementation is intentionally very simple. This means we do not use a STUN server, and so the connection will only work on the local network. This isn't a huge problem because in the case you are not on the same network as the IoT box, the WebSocket connection will still work and there would be little gain from using WebRTC. task-4894918
Resolved issues and error corrections
Fixed an issue that could prevent project task overlap checks from correctly handling filters based on related task information. This helps ensure planning conflicts are detected accurately and reduces the risk of missed scheduling issues.
Original PR description
The query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first one, injecting the second one's where clause as join condition, but that composition does not work if the second query has extra joins. Those extra joins come from related fields that may occur from the domain. The fix consists in recomposing the query with a join condition that does not depend on a dynamic domain, and injecting the domain in the where clause of the main query. With this strategy, the joins that appear because of the related fields in the domain are part of the main query, and are no longer lost by the composition. Note also that the test test_same_user_overlap_with_allocated_hours_less_than_workable_hours was actually broken, because the field allocated_hours wasn't flushed when doing the SQL query. The new query flushes the field, and the test has been fixed.
This fix makes Odoo more stable when working with newly created records before they are saved. It prevents errors during automatic field updates and display-name calculations, reducing interruptions in workflows such as field service reporting and Belgian tax reporting.
This change fixes an access problem that could prevent users from using the salary configurator correctly. It removes an unnecessary company-related recalculation that was causing permissions issues, while keeping company filtering already handled elsewhere.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/b68569868c00765bca910b5630a72db75347c03d, the salary configurator had an access issue on hr.job model. This is due to the compute method on company_id introduced in the previous commit. As the properties definition field of the hr_job is defined on the company, it was recomputed every time the company commute is triggered. Additionnaly, this compute on the company_id is useless as the domain on the contract_template_id is already filetered based on the company. A test for this is added in this PR: https://github.com/odoo/enterprise/pull/90412 task-4951648
When a report is opened in Studio without an existing template, the system now automatically creates the standard views it needs. This prevents crashes and lets users continue editing reports created from the technical menu.