Daily updates from Odoo
Tuesday, July 22, 2025
4 changes · master
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