odoo/enterprise#100501
Created by Quentin Smetz (qsm)
Statuses:
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- label
- odoo-dev:master-calendar-domain-qsm
- head
- 5b583dac67840b08aaefa3ddde82ecc69cf0cc20
- merged
- 2 days ago by i18n, Louis Wicket (wil)
| odoo/odoo | odoo/enterprise | odoo/documentation | |
|---|---|---|---|
| master | #237283 | #100501 | #15439 |
[FIX] voip: review VoIP calls calendar integration
This restores a feature lost at 1: a call beginning before the
calendar current range but ending inside it was not shown anymore.
Indeed the end_date became computed from the duration instead of the
other way around, allowing efficient domain manipulation based on the
duration. However, it prevented domain manipulation based on the end
date, which the calendar view needs. It also just makes sense to allow
filtering based on the end date too (even if we judged it less useful
when making 1). A solution could be to store the end date too, but it
would be redundant data. This instead allows domain manipulation through
a field compute_sql definition.
At the same time, this does the same thing for the start date: creating
a new computed field effective_start_date, which is either the call
start date or its create_date. This allows to entirely remove the
domain override needed in the calendar model (combined with the
community commit that comes with this one, which makes the calendar now
consider records without a set end date but which started within range).
Note: the date_delay option of the calendar was removed at 2.
This also fixes a runbot issue during the "click everywhere" test:
- Enter VoIP app
- Go to calendar
- Enter web studio
=> Crash, because the studio calendar ignores the VoIP custo about the
calendar domain and filters on end_date. The VoIP custo being gone
and filtering on end_date restored, this is not a problem anymore.
task-5350495
runbot-234398