Wednesday, September 9, 2026
3 changes · 17.0
Security fixes and vulnerability patches
Discuss calls now use a channel-specific key instead of reusing the same database secret directly. This helps better protect call connections by limiting keys to the relevant conversation channel.
Original PR description
derive channel-specific key from db secret and the channel id.
Enhancements to existing features
Log entries now show the real time even when tests or processes simulate a different date or time. This makes run logs easier to understand and helps teams analyze long-running test activity more reliably.
Original PR description
When using faketime the logs are not showing the real time but the faketime one which can be confusing when listed in the runbot interface. Before the usage of the JSONFormatter, the logs were using the PostgreSQL time, which is the real time. This restores the previous behaviour. Having the faked time oustide JsonFromater is also painful: long running faketimed tests end up with most of their logs stamped to nearly the same real date, preventing any analysis of execution time based on the logs. One drawback of this change is the inability to identify at first sight whether a log was faketimed or not, but at this point it is just a tradeoff, and the faked_created field on the record still allows getting this info if needed.
Resolved issues and error corrections
This fix ensures salespeople receive an upsell warning when several smaller timesheet entries together exceed the prepaid service threshold. It helps teams avoid missed upsell opportunities when work is logged incrementally instead of all at once.
Original PR description
Steps to reproduce: -------------------------------------------- 1. Install `sale_timesheet` module 2. Create a product with: * Type: Service * Invoicing Policy: Prepaid/Fixed Price * Create on…
Steps to reproduce:
--------------------------------------------
1. Install `sale_timesheet` module
2. Create a product with:
* Type: Service
* Invoicing Policy: Prepaid/Fixed Price
* Create on Order: Project & Task
* Upsell Threshold: Set some value (e,g. 600%)
3. Create and confirm the sale order with that product
4. Create and confirm an invoice for the sale order
5. From Recorder Hours Smart button:
* Add two timesheets for hours 3 & 4 (Combined h > Threshold Percentage/100)
Observation:
--------------------------------------------
* When adding a single 7h timesheet, an upsell warning activity is correctly created for the salesperson in the chatter.
* When adding multiple incremental timesheets whose combined duration exceeds the threshold, no upsell warning activity is created.
Issue:
--------------------------------------------
* The `_compute_field_value` method filters on `invoice_status != 'upselling'` before recomputing the new invoice status.
* After the first incremental timesheet is added, the sales order already has the upselling status from the previous computation.
* As a result, subsequent computations skip the upsell activity logic, even though `has_displayed_warning_upsell` is still `False` and no warning activity has yet been created.
Solution:
--------------------------------------------
* Removes the `so.invoice_status != 'upselling'` condition from the filter.
* The order-level `invoice_status` was never the right place to control upsell activity creation. An order can have `invoice_status == 'upselling'` for various reasons (delivered > invoiced), but that doesn't mean all lines have already triggered their upsell warnings.
opw-6117754