Some of the non canononical timezones are not present in Ubuntu Noble,
it would be a better practice to only use canonical timezones in data
and tests.
Note that this is not a real fix for all cases since the database that
ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have
the issue with timezones already in database.
One of the possible fix would be to manage that during upgrades, but
this isn't a verry flexible solution since upgrade are meant to manage
chyange of version, not change of server. If an old 17.0 versions needs
to be moved to a Noble server, this won't work.
Another solution would be to install package like tzdata-legacy that may
keep the old timezones but it is not the only think since TAI-10 are
also in this package. This solution is not ideal because non canonical
timezone will still be shown in the dropdown. We would need to filter
them.
A last solution would be to add the support for those old timezones by
monkeypatching the lib. This way, only new timezones would be shown but
non canonical one won't crash when used. This is not ideal either
because we may need to keep this for a while. But in combination with
the upgrade solution, it may work proprely.
Part-of: odoo/odoo#160842
In calendar, we use the interval value of the event to define if the
rrule_type_ui is custom or not. However, since a yearly recurrence in odoo
becomes a monthly recurrence every 12 months, we were showing the rrule_type_ui
as custom. At the same time, we were getting the wrong rrule_type. Instead of
being a monthly rrule type, it was being set as weekly (the default rrule_type).
This commit fixes this by getting the correct rrule_type, however we still show
it as custom as internally the yearly recurrence is a monthly one with interval
set to 12.
task-3570053
Part-of: odoo/odoo#139736
Before this task, lots of mails were sent after updating or deleting recurrent event in 'All events' or 'This and future events' update type. This was happening because updating these recurrent events was triggering patch calls event by event, when they should be handled in batch.
After this commit, updating or deleting recurrent events should trigger at most two mails for Google users.
closesodoo/odoo#137607
Task-id: 3163695
X-original-commit: ad2106babda61446bce13283d570dc723418b630
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
This commit changes the way we define recurrences from the UI so it's simpler.
Instead of showing the user many options for recurrence like we currently do,
we add a selection field for each rrule (daily, weekly, monthly and yearly)
that sets some default values for the recurrence without the user having to
define each field manually. This change makes the definition of recurrence from
the UI closer to what is done in google calendar. In order to allow users to
define more advanced types of recurrence, we also add a custom option in the
new selection field that will show the old recurrence options to the user.
Additionally, the week days widget defined in web takes too much space, so it
was decided to create an overwrite of this widget for calendar only that looks
cleaner and takes less space. This commit introduces this new widget and
applies it to the calendar event form view.
task-3234677
closesodoo/odoo#116649
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, if you had a recurring event and tried to change any
recurrence-related fields while selecting the 'This Event' option from
the header, the changes you made would not be applied. The desired
behavior is that when we changed the recurrence of an event,
we intend to modify both the current event and the following events.
When you update the event recurrence to 'This and following events,
all other updated events will have no recurrence.
In this commit, a UserError is now thrown to notify that changing the
recurrence of an event is not allowed when the 'This Event' option is selected.
In the values of the updated events 'recurrency': True' is passed to make sure
that updated events have recurrence
Task-3425216
closesodoo/odoo#128835
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This commit adds a test to make sure allday recurring events have correct dates.
task-3327004
closesodoo/odoo#123442
X-original-commit: ad0c6052d87e35128aabc3a2716dbbae4bc4ce36
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Issue:
------
It is possible to create recurring events
that are in the same DST period.
Unfortunately, the basic event is sometimes duplicated
Cause:
------
The cause comes from the Daylight Saving Time (DST).
With the base event, we create a recurrence.
This recurrence will create all the events
of the recurrence.
To achieve this, with the basic event, we create all the ranges.
Then, we compare these ranges to remove those which already have
events.
Logically, we must reconcile the first range with the base event.
Sometimes the range of the base event and the first range
calculated to generate the occurrences do not match.
The consequence is the creation of a new event.
The cause of this problem is that we go back too far to find
the starting date of the period from which we will generate the ranges.
For example, in the case of a recurrence with a frequency of `MONTHLY`,
we will take the first date of the month.
And if we are in the month when the DST changes,
we will have the problem.
Solution:
---------
The solution is not to go back
if we encounter a difference in the DSTs
between the starting date of the base event
and the starting date for generating the ranges.
opw-3143680
closesodoo/odoo#119073
X-original-commit: 065dd4a2548ff0da6cf23a7ac62321ce99500d35
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Changing end time for recurrent event will generate an error.
steps to reproduce the error:
1- Create an event in the calendar app with recurrence on
2- Save and close
3- Edit this event again and select change all events at the top
4- Change the ending time
The error was happening because the wrong key was accessed in a
dictionary
opw-3236432
closesodoo/odoo#118087
X-original-commit: 97f51b24da5db1a0217121aae583a9c1d715adc4
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This PR change the delete button in the attendee calendar if the
event is recurrent.
If the event is recurrent, a wizard pop up to ask if you
wish to remove :
- The selected event
- The selected event and the following
- All the event in the recurrence
task-id : 3148011
closesodoo/odoo#113024
Signed-off-by: Arnaud Joset <arj@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
As several customers complained about lot of bugs in microsoft_calendar in 14.0,
It has been decided to backport bug fixes of the model layer from master to 14.0,
without the need of an upgrade script (no new field, ...).
In master, we use 2 ids (organizer event id + universal id) instead of only one,
to handle Odoo <-> Outlook sync correctly when several attendees sync their Outlook
calendar with their Odoo calendar. For that, we have added a new field.
To report this bug fix in 14.0, the existing field which stores the organizer event id,
is now a string storing both ids separated by a ':' as follow: 'organizer_event_id:universal_id'.
2 new compute fields have been added to be able to use these 2 ids more easily.
(all commits from the original PR have been squashed to ease forward-port)
closesodoo/odoo#95736
X-original-commit: 5e83318a7240585371efd31e407829793f3e732f
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit aims to integrate the calendar module with discuss video calls.
Now it is possible to add discuss videocalls by clicking on a button below
the videocall_location field. The discuss videocall_location is a URL that
is computed and it creates a discuss channel only when someone accesses that
URL.
For recurring events, the same discuss channel is used for all events.
However, each event in the recurrency has its own videocall_location URL.
This is done on purpose in order to allow the functionality even if the base
event of the recurrency is deleted. For single events, each event will create
a discuss channel.
task-2685472
Part-of: odoo/odoo#79654
Before this commit, the calendar UX was not good enough. The look and feel was not modern.
This commit improves a lot of small details, remove unneeded or not mature features (like the videocall location url).
Counted recurrence now brings a better experience. When weekly or montly recurrences are created, occurences in the past are dismissed but before this commit their number was not adapted.
User would end up with less occurences than the provided number without explanations.
Taskid: 2484335
Part-of: odoo/odoo#68700
Before this commit, it was not possible to reapply all events in recurrence, delete all events of a recurrence or archive them.
This commit remove that limitation by reapplying the recurrence and remove all the existing events. When the events are synched, the action_mass_archive is used and it must ensure that only a request for the recurrency should be sent.
Individual request for each event are not sent.
Taskid: 2484335
Part-of: odoo/odoo#68700
with this commit we changes field names for week days like su, mo, tu etc. to
sun, mon, tue and so on in calendar module, this is going to be used in
task 2317795 where we developed recurrency module for recurrency mixin.
Also with this commit we change field names of weekdays in lunch module to have
same name as we have in calendar and project module so that we can easily use
custom widget "web_weekly_recurrence" instead of defining boolean field in xml
for each day.
task-2335399
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Issue
- Install 'Calendar' module
- Create new event from Calendar view
- Edit event
- Set True to 'Recurrent' in options tab
- Repeat every 2 weeks
- Until : Number of repetitions 2
- Save and go back to calendar view
- Events are shifted (+ 1 week)
Cause
The rrule.rrule (who create the generator with the recurrence ranges dates) use
by default `calendar.firstweekday()` as first week day ('wkst').
Solution
If recurrence frequency is 'weekly', get first week day based on user language,
and add it as param ('wkst') to the rrule.rrule.
https://dateutil.readthedocs.io/en/stable/rrule.html#classes
opw-2448325
closesodoo/odoo#66311
X-original-commit: 5e85ee521edb70d4d2c7cdbf59c29794a8cd98b9
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Co-authored-by: LucasLefevre (lul) <lul@odoo.com>
The fields `start_datetime` and `stop_datetime` are the exact miror
of fields `start` and `stop` respectively.
The field `display_start` is never used.
Hence those fields are removed.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit refactors the event attendees and notifications according
to the recurring event refactoring.
Some (very) basic reminder tests are also added.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
Purpose
=======
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.
Specification
=============
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
unchanged but now ends when the second recurrence begins. The second parts is the
updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).
Some design choices explained
=============================
Where to store the rrule?
-------------------------
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.
2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.
Reusing events on rrule update
------------------------------
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?
Reusing events on events shifts
-------------------------------
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Xavier-Do