If an event is private, a bunch of fields
are hidden for the users not being
the owner of the event, even for sudo.
The fields on which depends the `rrule`
computation were part of the hidden/private
fields.
In addition, the `rrule` is always computed
as sudo. See `_get_rulestring`.
Therefore, the `rrule` of recurrent private events
was not correctly computed when the owner wasn't
the administrator.
opw-670295
This reverts commit 33755f1882.
note: revert for now since some scenarios were not taken into account,
detached event could have been moved to another day.
When editing a recurring event clicking `Update only this instance`
allow us to detach this event from the recurring sequence, but without
clicking it there are instances where the event will still be detached
maybe unexpectedly.
Clicking on it will create an event which shadow the recurring one that
being done thanks to:
- recurring_id: the id of the recurring event creating this event
- recurring_id_date: start of the virtual event this new event shadows
Before this commit: when the start or end date of an recurring event is
changed, all modification are not applied on the recurring events but
only the current virtual event occurrence is detached and modified.
After this commit:
- when the end date of a recurring event is modified, it is modified for
all the instance (not detached) of the recurring event,
- when the start date of a recurring event is modified, it is modified
all the instance (not detached) of the reccuring event and if:
* one occurrence of the recurring event is still on a (not-moved)
detached event of this recurrence, this virtual event will be
shadowed.
* a detached event has now no occurrence of the recurring event on its
day, it will still be left untouched but will now not shadow an
event anymore.
eg.
we start with recurring event A on 4, 5, 6 => we see [4: A, 5: A, 6: A]
-> detach event on 5 calling it B => we see [4: A, 5: B, 6: C]
-> change start of recurrence to 5 => we see [5:B, 6:A, 7: A]
-> change start of recurrence to 7 => we see [5:B, 7:A, 8: A, 9:A]
-> delete detached event B on 5 => we see [7:A, 8: A, 9:A]
-> change start of recurrence to 3 => we see [3:A, 4: A]
closes#10873fixes#10278
opw-665700
Before the fix dda8e2211a, the duplicate
records were erased thanks to the index used in the dictionary(id of the partner).
After this fix, to avoid this this problem, the label of each record is used as
key in the dictionary.
Has been changed at d8e5cdec in the source but wasn't in the translations.
Replace also is .po files combined with a tx push to be able to add the new one.
Closes#10461
While this is important to read the replies
you get in the threads you follow, `Unread messages`
is more accurate to describe what these filters
displays.
opw-666739
When changing anything regarding the recurrence,
e.g. the number of repetitions, the weekdays, ...
the event require an update by Google side
As the `rrule` is a computed field, we need to mark
the event as needing an update by Google side as soon
as one of the fields on which depend the `rrule` field
is updated.
opw-659963
Odoo Translation Bot