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>
* 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
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>
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>
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
dasa-odoo