Steps to follow:
- Set your timezone to New York
In linux for example with: `timedatectl set-timezone America/New_York`
- Verify that the user timezone is also set to NY
- Create a reccurent event the 6 july 2022 (a wednesday)
- In options, check the recurrent box
- Set repeat to once every week
- Thursday is the only day checked
-> It should be Wednesday
Cause of the issue:
When `_compute_recurrence` is called, `event.recurrence_id` has not
yet been set
-> `event.recurrence_id.event_tz` is False
=> Copy the defaults before computing the start date and check the
timezone of the event itself
opw-2886253
closesodoo/odoo#96049
X-original-commit: 7186dbad38ef1f05919c398f3c0c5f5d8f8b2219
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
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>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
We can use ._search() to make sure that permissions and ir.rules are applied. By making use of psql subqueries, we remove the need of costly python filtering afterwards, thus increasing performance.
Created test_meeting_count() to check that that the computing of meeting_count is done correctly.
closesodoo/odoo#91325
X-original-commit: 2df40ab03d29045546fbf7f19203e66796d52dc0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Because private fields would automatically add a bunch of fields to
the user's request (in order to do their own post-treatment), unlike
normal behavior `read([])` would be completed to `read(['privacy',
'user_id'])` and would fail to trigger the "select all the fields"
behavior of `BaseModel.read`.
Move the privacy management to a `_read` override instead. Also update
the code to be more linear and straightforward, without a bunch of
intermediate helper function.
This is also a small performance optimisation, although apparently
much more minor for 14 (best case of about 5%) than on 15.0 (where it
seemed to reach 30). The gain is mostly for private events being read
for non-participants: because the non-public fields get neutered
before computation (rather than after), fields are computed on a
neutered basis and thus largely do nothing. This is especially salient
with computations relying on relations (in this case
`attendee_status`), as from an empty starting point they essentially
do not do anything.
This leads to the effort (and cost) of private events being read by
non-participants to be about the same as the cost of public events,
whereas before the change there is a visible overhead. The signal is
quite noisy though.
NOTE: backported the addition of `privacy` to the public fields from
2f4a91c0ce as that is better
behavior and makes the tests more logical (and easier to forward
port probably)
OPW-2831113
closesodoo/odoo#89936
X-original-commit: b0c6f2969596fb715e0a6c62865b5c7dbc0bcc78
Related: odoo/enterprise#26699
Signed-off-by: Xavier Morel (xmo) <xmo@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
Step to reproduce:
- Create a lead
- go on the smart button meeting
- create a new meeting and edit it
- save
Current behaviour:
- Validation Error
- It seems the default_get apply command in onchange instead of passing the value which lead to missformed argument for meeting
Behaviour after PR:
- Do not send readonly attendee in calendar.event form view
opw-2724372
closesodoo/odoo#82794
X-original-commit: fba25d6982d149a9d5083f993dea7c2091736c58
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
When an event is created from an external calendar account such as
Google or Outlook, attendee info such as email and state may be given,
and should be taken into account.
For example, if the current user who is syncing his calendar is not
the organizer of the event, his attendee state should be set to
'needsAction' and not automatically set to 'accepted'.
opw-2489815
closesodoo/odoo#81636
X-original-commit: eb1adbd6af4b01a8b3b5b16dbf2d6c32eec852e6
Signed-off-by: Arnaud Joset <arj@odoo.com>
If some attendees of an event have an empty or invalid email address,
the organizer of this event should be informed that these attendees
won't receive any email notifications.
opw-2667016
closesodoo/odoo#79368
Signed-off-by: Arnaud Joset <arj@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, it was not possible to create events with defined attendee state. The default value was always set.
This was a limitation when the events were part of a recurrence and all events attendee needed to be created with a known state.
To reproduce, one would create a recurrent event, sync it with Google and in Google, 'decline' this event and the following.
The attendee state was not properly set.
closesodoo/odoo#68700
Taskid: 2484335
Related: odoo/upgrade#2537
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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
Before this commit, read_group with private fields would automatically raise an user error, preventing the action.
This commit filter out the private records that the user should not access and display the public ones according to the current user.
Taskid: 2484335
Part-of: odoo/odoo#68700
Following the removal of read access on ir.model (odoo/odoo#69120),
the mail.activity.type model was not accessible to non-admin users due
to the res_model_id many2one field.
Before this commit, a project user could not access the Activity Type
menu.
Convert it to a selection field with the selection values being
computed in sudo.
closesodoo/odoo#74981
Related: odoo/enterprise#20214
Related: odoo/upgrade#2734
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating a meeting from a partner/lead, the invitations won't be
created/sent
To reproduce the error:
1. Open a lead
2. Click on Meeting
3. Create a meeting
- On meeting creation, directly click on "Create", not "Edit"
Error: No invitation has been sent. When editing the created event,
there isn't any invitation on Invitations tab. Same error will happen
when opening the form of a customer instead of a lead (step 1)
For an attendee to be created, the partners associated with the meeting
must be explicitly listed in the creation values:
https://github.com/odoo/odoo/blob/3e20e68f0790a0b0f3b5c4d43f59f235b7d20fef/addons/calendar/models/calendar_event.py#L710-L713
However, in the above use case, the partners identifiers are given
through the context. This explains why the attendees are not created.
OPW-2531496
closesodoo/odoo#75353
X-original-commit: a8b4f8f6c009d8abd7210973005fd755ac3bc573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Adding a new method convert_online_event_desc_to_text
Because online events have fixed format for the description,
this method removes some specific html tags, and converts it into
readable plaintext (to be used in external calendars).
Models -> Fields
1) calendar.event -> description
Task Id: 2499504
X-original-commit: 0d5ca6a6fe8821b4ec19dd603bde116518721792
Before this fix, the runbot would fails randomly during the nightly multi-build in test_accept_meeting_unauthenticated and test_accept_meeting_authenticated.
```py
odoo.addons.calendar.tests.test_calendar_controller:36
FAIL: TestCalendarController.test_accept_meeting_unauthenticated
Traceback (most recent call last):
File "/data/build/odoo/addons/calendar/tests/test_calendar_controller.py", line 36, in test_accept_meeting_unauthenticated
self.assertEqual(self.event.attendee_ids[1].state, "accepted", "Attendee should have accepted")
AssertionError: 'needsAction' != 'accepted'
- needsAction
+ accepted
: Attendee should have accepted
```
There was a hard coded index of a record in a many2one field and sometimes, the record order changed. The asserted value was not the one expected and therefore, the test failed.
closesodoo/odoo#69263
Taskid: 2497816
X-original-commit: 4632ee9a02e366dcb7da6b46f23a3cd367412ccb
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With this commit we try to improve the way the events are displayed
to the user. Now, an event is displayed for each attendee of the event
that are selected in the filter. These events are displayed correctly
based on the status of the attendee in the event.
The colors displayed for the events now represent the attendees and not the
organizer.
If an attendee edit an event, it is edited for all others attendees.
Also, when an attendee that is not the organizer try to delete the event,
then the event is now declined in place of being deleted. If the organizer
delete the event, it is deleted for all attendees.
In case of an event where all attendees have declined it but the organizer,
the organizer see now a danger icon before the name of the event and it's
outlined and not filled with color, no matter of the actual status of the
organizer in the event.
task-2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
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>
When testing cron triggers, it is common to get the newly created
triggers in order to validate they exist and are scheduled are the right
moment.
This new helper is a context manager that capture all triggers or
triggers created for a specific cron. The created triggers are
accessible via the context's object `records` attribute.
The various tests have been updated so they use that new helper.
closesodoo/odoo#68163
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
* Replace the "Snooze 7d" action for lead-related activities linked to
a calendar event by a "Reschedule" action, which will redirect the user
to the calendar view with the focus on the next event related to the
opportunity
- The "Snooze 7d" action only impacted the activity and not the meeting,
and snoozing a meeting is not very logical anyway. The "Reschedule" fits
better in this use case.
* It was discussed to show only a modal allowing to reschedule the next
calendar event, but that could lead to inconsistent states (out of order
sequence of scheduled events, if the first is rescheduled after the
second).
* The reschedule option will be shown next to any activity related to a
calendar_event regardless of its activity type. There are some edge cases
that we may want to change in the future :
- When changing the activity type of a 'meeting' activity associated to
a calendar event to any other activity type, but without removing the
calendar event, the reschedule action is still showing (since the event
is still ongoing and was not deleted from the calendar).
- Conversely, with a meeting which is not (yet?) related to a calendar event,
the reschedule action will not be available.
* Add a new field to MailActivityMixin in the calendar module context. This
field is the event linked to the next activity, if there is one such event.
It is used to check whether the reschedule action should be available to the user.
* Add a test for this new field to validate the expected behavior.
* Add the priority widget to the priority field in the opportunity tree view
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
Context
-------
in the module website_calendar, the controller create
an event with alarm with the Public user and the company of the public
user
and set partner_ids that may belong to a different company
Issue
-----
The company of the user that create the event remains in the context
and _notify_next_alarm check for each user which event should be notify
using with user of the partner that may be notified and check the access
rules to filter the event the partner should actually see.
The check of the acces rules need env.companies that remains the company
of the user that create the event which the current user may not see
which trigger the following error.
"Access to unauthorized or invalid companies."
Solution
--------
Wipe the company in the context when calling get_next_notif
closesodoo/odoo#66999
X-original-commit: 7fe9012301f606e153ad2ad04c392aa193c182f3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
You have have a scheduled activity precisely at 8:12:34 AM (send an
email, anything). You trigger the cron using that precise moment. The
cron runs at 8:12:00 AM which is before the scheduled moment so the
activity is skipped. Imagine there is no other scheduled activity that
coudld trigger the cron, it is only run at worst 23h59 minutes later
thanks to the daily cron execution fallback.
The assumption of a29bb54 is wrong, it groups the moments the
cron should be triggered by grouping the moments on the rounded down
minute. This is not consistent with the trigger API that promises the
cron will run *as soon as possible but **not before*** the scheduled
moment.
closesodoo/odoo#65555
Task: 2452697
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Often the business want to trigger the cron several time at different
moments. The typical use case is the business holds a recordset and
needs to trigger the cron for every record. The current solution is to
loop on each record to call `_trigger` times.
We now allow to invoke `_trigger` with an iterable of `datetime`
objects, and isolate the implementation in method `_trigger_list`.
We also removed the `delay` argument as it was not used.
closesodoo/odoo#65459
Task: 2452697
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Fine tunning of c8f031ad77, this commit has the missing code
compatibility for sms_calendar.
closesodoo/odoo#65064
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The calendar reminders are emails or web notifications sent moments
before an event start. The mechanism to send web notifications is
controlled by the browser, it fetches all the future notifications and
uses `setTimeout()` to delay them. The mechanism to send emails was
controlled by a cron, every 30 minutes the cron would look for the
coming events and send the mail reminder.
The cron was running every 30 minutes even if there was no event. The
best precision was 30 minutes.
The new mechanism use cron triggers, every time one add email reminders,
triggers are created to call the cron at the precise moment the alarm is
set. The cron no longer send emails for events in the coming 30 minutes
as those will be triggered too.
closesodoo/odoo#64560
Task: 2416741
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before this commit, a notification was sent to all the attendees
whenever a past event was modified.
Now the notification is only sent if the event is taking place in the
future.
closesodoo/odoo#63015
Taskid: 2409394
X-original-commit: e31819bccec604ba61c053015304abebdd189690
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
What are the steps to reproduce your issue ?
1. Install "google_calendar"
2. Log in with "admin"
3. Create an eventX with "admin" and "demo" has attendees
4. Run "Google Calendar Synchronization" from "Scheduled Actions"
What is currently happening ?
eventX is successfully added to Google but without admin
if you sync Odoo to Google one more time, Google will overwrite eventX
and it will remove admin from attendees
What are you expecting to happen ?
Sync Odoo to Google and Google to Odoo without lost attendees
Why is this happening ?
Because there is a filter that prevent addition of current user to the attendees
How to fix the bug ?
Remove the filter
This reverts commit 287ee0f83ae6fd457e5356860c8a8ab5a4e66754.
opw-2382443
closesodoo/odoo#62416
X-original-commit: f6a610d0b1379aa97ad97fb7494a5d269da87775
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When the test starts after 00:00:00 UTC, the test fails.
closesodoo/odoo#60891
X-original-commit: c62acb48ac3ae11180a6817321664fb01833d3bd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Behavior prior to the fix:
When accepting a meeting invite from the invitation email, if not logged
in, an Internal Server Error is received. Additionally, if already
logged in, an Internal Server Error is also received (albeit for a
different reason)
Behavior after the fix:
Accepting (or declining) the meeting invite works and shows the
accepted/declined meeting.
opw-2366173
closesodoo/odoo#60617
X-original-commit: d44d9e58b2cd5530e15e2a8c5055b18d2d8395e7
Related: odoo/enterprise#14361
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
Issue
- Install "Calender"
- Install "Google Calendar"
- Try to sync google in "Calendar"
Every created events will trigger the sending mail to attendees
even if the event date is past
Cause
'events' was not filtered
Solution
Filter 'events' to get all the events that have not yet happened
opw-2358123
closesodoo/odoo#60414
X-original-commit: 3b1df8f57e0cd342fe7f9ff7bd34100b2c821569
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
When creating an event through the quickcreate, the user creating the
event was not set as attendee.
closesodoo/odoo#58631
Taskid: 2334943
X-original-commit: 07d799a5f676ed68fd2ffd9cd9bac3269f947ad1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
- In a res.partner;
- Schedule activity;
- Choose 'meeting' as activity;
- Set a summary : 'test summary';
- Open Calendar;
- Chose a date and an hour;
- Edit the meeting;
- Add a description with a line break;
- Save the meeting;
- open the res.partner view;
Before this commit, the note on the planned activity lack the line
break.
Now, the note in the planned activity has the same output as the
description of the calendar meeting.
opw-2236838
closesodoo/odoo#50226
X-original-commit: 2e9cc92fb45f9328c45520275ab11c7a486a2590
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Commit b0f1086 forgot that `read_group` supports
aggregation functions (e.g. "start:month") and that
`groupby` could be a single field or a list of fields.
+ add some tests
Task 2238100
closesodoo/odoo#49550
Related: odoo/enterprise#9878
Signed-off-by: Yannick Tivisse (yti) <yti@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
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Hubert Van de Walle (huvw)