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
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>
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to
allow its usage even if CRM is not installed as this makes more sense since this
field is usually related to Calendar.
Increase query number limit in company leave test, in order to take into account
the newly introduced query in Calendar.
UPG-PR: https://github.com/odoo/upgrade/pull/2423
Task-2514473
closesodoo/odoo#69846
Related: odoo/upgrade#2423
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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
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
Since commit 91560fae56f1cba0914, we are using sudo to write
calendar_last_notif_ack, but we need to update the real partner stored
in the context.
opw-2133566
closesodoo/odoo#41982
X-original-commit: 4d6416dbc82f07c91111457b503ccfc737f802c9
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Migration of all python code, mostly withtout chagnes. And adapting
xml files to guidelines.
On calendar.py, some changes have been perform to make the migration works :
- `_compute` method has been split into `_compute_dates`, `_compute_attendee` and `_compute_display_time`.
- remove unused method `onchange_partner_ids`, `check_partners_email`
- make `compute_rule_string` use a cache record instead of a value
dict to avoid crashes
- remove `new_invitation_token` method, and make it a default value on attendee creation
- add a default value on `day` field, otherwise the "Please select a
proper day of the month" exception is raised during the onchange
Arnaud Joset