When sorting by a many2many fields (e.g. partner_ids) with one of the record
having an empty value on the sorted field, the comparison method used to compare
and empty record (e.g. res.partner()) and a name_get result (e.g. "Agrolait").
This is because the sort_field was initialized with the result of self[field]
but never assigned a new value below.
Fallback on an empty string when no record is found
Fixes#26908
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 != '155-20120301120100' : Last event should be found searching it by date range
note: for 10.0 up to not including 11.0 which is solved with #26901
opw-1866151
closes#26887
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
When creating and editing a new calendar.event record from the calendar
view, the start_datetime field does not prefill from the day that was
selected on the calendar.
Introduced in e08f999468
opw-1875276
When creating an event using the list view, no value is set in the
fields start and stop.
If selecting all day, we could only change the value of start_date and
stop_date which does not change the value in start or stop.
This makes it impossible to create an event from the list view.
This problem is not present in the calendar view since this view sets a
value in start and stop, and the start and stop are recomputed via the
inverse fields.
Closes#25680
The end time of a calendar event is constrained to never be before the start
of te event.
However when updating events, one path would first update the start of the event
before updating the end of the event.
So in case where (s_1, e_1) is updated by (s_2, e_2),
with respectively s_i < e_i,
if s2 > e1 then the update would violate the constraint and thus crash
the calendar update.
opw 1854394
Consider the following:
``` python
from datetime import datetime
from dateutil import rrule
import pytz
dt = pytz.UTC.localize(datetime(2016, 9, 2, 15, 42, 43, 205))
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA', dtstart=dt, forceset=True, tzinfos={})
test = [d for d in rset]
```
This will generate the following error:
```
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1164, in _iter
advance_iterator(ritem)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1091, in __next__
self.dt = advance_iterator(self.gen)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 649, in _iter
date = datetime.date.fromordinal(ii.yearordinal+i)
ValueError: year is out of range
```
If such an event is received from Google Calendar, the synchronization
crashes. To avoid this, we enforce a `COUNT` condition if the latter or
`UNTIL` is not explicitly specified. This gives:
``` python
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA;COUNT=100', dtstart=dt, forceset=True, tzinfos={})
```
Note that this was supposed to be fixed in
https://github.com/odoo/odoo/blob/9dcc32c3041e7ad3549a09c5ed68ee3ef22c7a26/addons/calendar/models/calendar.py#L1287
However, this was working with the old API. The new API and its computed
fields does something different:
1. create the calendar event with the provided `rrule`
2. trigger the inverse method `_inverse_rrule` => `count=100` is added
to the computed parameters
3. however, doing so won't recompute `rrule` for obvious reasons (it was
the initial value provided, so we don't recompute it)
4. the crash is met in `_get_recurrent_date_by_event` when using
`self.rrule`
The fundamental issue is that `_inverse_rrule` is not strictly the
inverse of `_compute_rrule`.
Fixes#25189
opw-1861658
From a SO (for example), create an activity with type meeting
Create the calendar event
Access it as a guest with the route with the token
Before this commit, there was an error 500 because the description
of the event actually contained "\n" and was not parseable
After this commit, we strip the string at event creation, and no error occur
OPW 1867283
closes#25795
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
by datetime
The library `datetime` defines a MINYEAR and MAXYEAR limit.
If you try to play with dates outside of these years limits,
it crashes.
In the case of the opw, the date within its timezone was
within the limit (year 9999), but in the UTC timezone
it was no longer the case (year 10000).
Actually the condition should use `<=` instead of strict `<`,
and check the year *in utc*
is not outside the limit, but as soon as you try
to compute the date within UTC, datetime crashes :).
However we can assume nobody will need a event in the year 9999
any time soon, or by that time if Odoo still exists,
we should have refactored this module about 3333 times and somebody
would probably have removed this limitation by oversight anyway.
opw-1850024
Odoo Translation Bot