From calendar create a recursive event and add some guests. Delete one
event of the chain.
Invitations (Mail) will be created for the deleted event, and should not
be the case because the event has been deleted.
This happens because the recursive event is really just a record in the
database representing all the generated events. When the user want to
delete an event in the chain, a new event, copy of the "parent" event
has to be registered and subsequently disabled.
In the process of creating the event the mail is sent as
side effect. Note that the code to prevent this was partially there
because a context flag "dont_notify" is sent by the unlink in
Calendar.Meeting but was ignored from the mail subsystem.
opw-2039576
closesodoo/odoo#36270
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Be in the timezone Australia/Brisbane
On an object, create a Meeting activity
Create the calendar event and set a start date "tomorrow" at 7:00am
Now go back to the object to see the activity
Before this commit, the activity appeared as due "today"
After this commit, it is due "tomorrow"
OPW 1891110
closesodoo/odoo#28576
Be in timezone Europe/Brussels, where, in 2018, the DST switch
happens on 2018-10-28.
Create a recurring event starting on 2018-10-27 until 2018-10-29
at say, 8am
For the days before the 28, the time of the event will be correct
Before this commit though, for the days after the 28,
the meeting time will be shifted by one hour
This is because the rrule took a TZ aware datetime, and generated recurring
event dates with that same TZ, i.e. the one in STD time
After, this commit, all the meetings are well scheduled at 8am,
OPW 1895315
closesodoo/odoo#27985
With a user in a distant timezone, like UTC +/- 11
Create a all day event.
Before this commit, the event was displayed across the wrong days
This was because the dates were converted from the user's timezone
into UTC before being stored.
Which is:
- start date at december, 12
- if the user's tz is utc-11: the date becomes december, 11 (at 1:00pm)
- at rendering, it becomes december, 11 (at 7:00am)
After this commit, we store the datetime field "as if" it were a date field
that is, we don't convert it to any particular tz
It is worth noting that, if one removes the allday mapping in the xml view,
an event that has been created as allday will get its start and stop date converted
to the browser's timezone, and will NOT be displayed as from 8am to 8pm as one could expect
This is considered as a limitation of the code, that was present before this commit anyway.
In any case, please do not revert this commit :D
OPW 1891110
closesodoo/odoo#27949
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
Since 76b7242 if we have a recurring event with 3 occurences:
[4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]
And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:
- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]
And wrongly apply the current filtering over:
[14th 4:00-4th 5:00] [24th 4:00-14th 5:00]
So the issue hides recurrences of event wrongly if:
- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
number of detached previous events) is not in the current filtering.
With this change, the stops are also filtered based on start of
occurrence + duration.
Without the change, the added test fails with:
False != '27-20120301120100' : Last event should be found searching it by date range
note: 11.0 version of 10.0 #26887
opw-1866151
closes#26901
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
The custom computation for domain applied on recurring event
was assuming that a leaf value was true. This can lead to miscomputation.
Context:
For a domain like
'|',
('start', '>=', '2018-06-28 23:59:59'),
('allday', '=', True),
the domain will be transformed into
'|',
'|',
('start', '>=', '2018-06-28 23:59:59'),
'&',
('recurrency', '=', 1),
('final_date', '>=', '2018-06-28 23:59:59'),
('allday', '=', True],
In order to fetch recurring event with date that COULD match the domain.
Then, the custom evaluation will filter the generated virtual ids with
the base domaine, replacing leaf not specific to bounds by true,
leading to a domain like:
'|',
('start', '>=', '2018-06-28 23:59:59'),
True,
Also well known as "True"
Therefore, all recurring event virtual ids will be kept.
Solution:
This fix proposes to fetch the leaf values from the database to ensure
the consistency of the domain.
Thanks to RLI for the help.
Task: #1858076
PR: #25544
It seems to randomly save a bad value into the cache for star_date(time) field.
For already impacted database, it can be easily fixed with a simple update.
update calendar_event set start_datetime=start, stop_datetime=stop where allday = 'f';
update calendar_event set start_date=start, stop_date=stop where allday = 't';
Than can cause errors for google synchro.
Read(['start', 'start_datetime', 'start_date']) make the cache corrupt
for computed field start_datetime or start_date.
Now we don't read (for nothing ?) these 2 fields.
We can remove the skip for the test #500fabf1
Before this commit, a simple :
x = self.create({'name':'subject', 'allday': False, 'start': foo, 'stop': bar})
create randomly an event withtout start_datetime
Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.
Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.
In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).
ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).
OPW-771886
A recurring event with a start date and a time duration had a wrong start and
stop date computed.
Introduced at 76b724294a.
Previously the r_date contained only the start_date but now it contains both
start and stop dates. This implies that the method 'get_recurrent_ids' could
use 'get_search_fields' with a stop_date (depending on the domain order) and
returns incorrect dates.
This commit ensure to launch the get_search_fields with the start date.
Closes#15922
Add a 3 use cases with tests that were failing before.
datetime filters were not working correctly on stop filters
The `_get_recurrent_date_by_event` was only computing recurrency on the start
field of an event which can make a difference. A recurring event
start=2017-01-01 09:00:00; stop=2017-01-01 10:00:0
was not matched in a search ('stop', '>', '2017-01-01 09:30:00')
The filter != was not handled in the recurring use cases.
e.g. making the search 'start is set' in the web client is equal to
('start', '!=', False)
Searching with only a start filter matching recurring events but not the
first ("real") occurence, was returning no result if no stop filter was present.
start=2017-01-01 09:00:00; count=5
had no result in a search ('start', '>', '2017-01-02')
Yannick Tivisse