WHY: odoo translation framework still cannot properly handle terms that have
different translations, so we need to avoid english terms with double meaning.
Also, this improves term understanding for translators.
---
closes odoo/odoo#61668
Discussion: #60765#61272
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>
The purpose of this commit is to have reliable calendar event reminder.
Before, the reminders was not send directly and was instead put in mailing
queue, which was leading to some delay. This is due do mail_notify_force_send
context key being force to False when being in cron mode. However here we
do not want to have calendar cron scheduling emails, then mailing cron
sending them as it implies two delays.
In order to try to send reminder mails as soon as possible compared to their
schedule let us send mails directly during the calendar cron.
Task ID-2331999
closesodoo/odoo#60598
X-original-commit: 232a3c4c65dd60215a5def010da8559a9ffb2378
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Before this commit
- If Google Calendar and Outlook Calendar are installed, there are two
'Calendar' tabs displayed on the user form view which is confusing
and they both share very similar fields.
- Also, in calendar the 'Sync with Google' and 'Sync with Microsoft'
buttons were not having the same size.
After Commit :
- Now only one 'Calendar tab is there which contains two groups, one
for 'Google Calendar' and one for 'Office 365 Calendar'.
- Top margin is added on 'Reset Account' button for both Google and
Microsoft groups for better UI.
- In calendar, 'Sync with Google' and 'Sync with Microsoft' buttons are
having the same size.
Note - The scss files are not much needed anymore and thus were removed.
Also to avoid a bridge module just for the sake of empty container,
we add it in calendar itself.
Task Id-2323205
PR #56551
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* mail,calendar,note
Before this commit:
When accessing activities from the systray, any existing breadcrumb-item should
be clearer.
After this commit:
Clear breadcrumb-item when access activities from the systray.
Task-2342246
closesodoo/odoo#59396
X-original-commit: 6dd181c789d22f99073fcd0a9b0fa2edccdfe0fc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
Removing default read/write access rights on Calendar Attendee Information for Portal User.
opw-2325322
closesodoo/odoo#57314
X-original-commit: 7df6583dba5d4d11664c21979bfb4f926fabce16
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
before this commit, widgets which has specialData attribute
e.g.many2manyattendee were not supported in calendar popover, as widgets with
specialData attribute are meant to be supported in form view.
after this commit, widgets with specialData attribute can be added in calendar
popover, specialData method is called explicitly from calendar_popover to fetch
special data required to render such widgets.
with this commit we also did miscellaneous improvement in many2manyattendee
- many2many_attendee status widget bullet not aligned with attendee name, with
this commit bullet is aligned with attendee name.
- if many2many_attendee does not have status value then do not display status
else blank space is displayed before attendee name.
- in community tentative status color in many2many attendee tags widget has
o-brand-secondary color which is almost light grey, so due to badge light grey
color and tentative status light grey color status is not displayed. To fix
this issue, set tentative status color to simple grey which is bit dark then
badge background color.
task-2058767
closesodoo/odoo#46396
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously, creation of the 'All day' event was not possible in some
scenarios due to constraint error, even with proper configuration.
Scenario 1: (main spec of the task)
------------------------------------
- go to form view of calendar event
- create a new event
- enter future datetime in 'Starting at' field
- tick the 'All day' checkbox
- enter the end date which is greater than start date
- try to save the record
Scenario 2:
------------------------------------
- go to form view of calendar event
- create a new event
- enter future datetime in 'Starting at' field
- try to save the record
Scenario 3:
------------------------------------
- go to form view of calendar event
- create a new event
- enter any datetime in 'Starting at' field
- enter duration -1.00 hour
- tick the 'All day' checkbox
- enter the end date which is greater than start date
- try to save the record
In all above scenarios, user is not able to save the record even if
the there is no obvioius wrong configuration.
All of the above bugs are result of a recent refactoring[1]
where some redundant fields were removed.
The first two scenarios are result of 'stop' date not being computed
proerly based on 'start' in case the duration is set to '00:00'
(which is default duration) while the third one is due to lack of
proper check in the constraint after the fields used to validate
starting and ending dates were removed.
This commit fixes the issue by improving the compute method and by
ensuring proper validation in the constraint.
[1] - https://github.com/odoo/odoo/pull/42031/commits/6bafd7c677d016e82473f01bd0a3381ac3b24bbd
Task Id: 2299212
PR #54673closesodoo/odoo#56411
X-original-commit: cc5d090c267bac892d2e8200f8e55de88c5a0af2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: D J <dja@odoo.com>
Before this commit there is no label shown at the top of the invite if
the user hasn't done anything with the invite or if he chose
'Tentative'. Now it always shows the informative label. This commit
also adds the description of a meeting subject as it can be
interesting and important in many cases.
closesodoo/odoo#43121
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closesodoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Remove the field privacy in the search view since privacy
is not considered as a public field.
task-2285901
closesodoo/odoo#55398
X-original-commit: 0f6a531dcd7bba270ba83627d7140a76459c6d08
Related: odoo/enterprise#12193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
Purpose
=======
Task 2195254 introduced many wonderful widgets to pimp the list view.
This task aims at implemeting them into the Services apps: project,
timesheets, helpdesk, expense, planning and field service.
Remaining days: https://drive.google.com/file/d/1o4Wn47445GxLqBkw-ifH9MgtFU_437xz/view
Avatar: https://drive.google.com/file/d/1yDwJWP0MZCUKZbqCa8hte1ziVTYRMMtb/view
Activities: https://drive.google.com/file/d/1e_rXH50eZq4zY2HOzw7_pfgiD39SoRIl/view
Field-specific decorations: https://drive.google.com/file/d/1WFnqJ-jkyDFftRHxWW4bgomoWrOpOuaY/view
More control on buttons
Specifications
==============
You will find below a list of which widgets to apply to which fields by
model. Some changes have to be done in the form/kanban views as well.
1) project.task
remaining days -> date_deadline -> list + kanban + form views
hide this field if is_closed is true
avatar -> user_id -> list view
activities -> 'next activity' field to be added -> list view
field-specific decorations
https://nimb.ws/ACewrY remove the current orange/red decorations we have
if planned_hours > 0, display the remaining_hours field in (list view):
red if progress is > 100%
orange if progress is between 80% and 100%
green if progress is <80%
display unit_amount in red if > 24:00 -> form view
2) rating.rating
display the rating in:
green = satisfied
orange = not_satisfied
red = highly_dissatisfied
list + form views
3) project.project
avatar -> user_id -> list + form views
4) account.analytic.line
avatar -> employee_id -> list view
display unit_amount in red if > 24:00 -> list + kanban + form view
https://nimb.ws/eIWa7E merge the timer and duration fields together
5) helpdesk.ticket
avatar
user_id -> list view
employee_id under timesheet_ids -> form view
remaining hours -> sla_deadline
activities -> 'next activity' field to be added -> list view
field specific decoration -> display unit_amount in red if > 24:00 -> form view
6) hr.expense
avatar -> employee_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
reported = green
approved = green
done = green
refused = red
combine the unit_amount and the currency_id fields (see the total_amount field for reference) -> list view (idem for the expense_line_ids one2many on hr.expense.sheet)
display the total_amount in bold
move 'company_id' before 'amount'
7) hr.expense.sheet
avatar
employee_id -> list view
user_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
submit = green
approve = green
post = green
done = green
cancel = red
display the total_amount in bold
move 'company_id' before 'amount'
8) planning.slot
avatar -> employee_id -> list view
decoration
display the allocated_percentage field in red if > 100% -> list + form view
display the forecast_hours field in red if > planned hours and if planned_hours > 0 -> form view
display the effective_hours field in red if > forecast_hours and if forecast_hours > 0 -> form view
9) misc
calendar.event -> avatar -> user_id -> form view
mail.activity.type -> combine the delay_count and delay_unit fields together -> list view
note.note -> 'next activity' field to be added -> list view
crm.lead.mining.request
combine the lead_number and lead_type fields together -> list view
display the name in bold
badge -> state
draft = blue
done = green
error = red
planning.slot.template -> display the duration field in red if it is = 0
closesodoo/odoo#51271
Taskid: 2248351
Related: odoo/enterprise#10605
Related: odoo/upgrade#1252
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
The following task implemented new widgets/features in the listview for better UI.
https://www.odoo.com/web#id=2195254&action=327&model=project.task&view_type=form&cids=1&menu_id=4720
The goal of the current task is to use those to upgrade our listviews
Specification
=============
Below are change requests on various listviews.
Remove decoration-bf="message_needaction==True" from every listview in every module.
PRODUCT - stock.view_stock_product_template_tree (product template)
remove all decorations from <tree>
set the following decorations on 'virtual_available' and 'qty_available'
decoration-danger="virtual_available<0"
decoration-warning="virtual_available==0"
also set decoration-bf on 'virtual_available'
apply the same modifications on stock.view_stock_product_tree for product variants
SUBSCRIPTION - sale_subscription.sale_subscription_view_list
remove all decorations from <tree>
'stage_id' field
set <field name="stage_id" widget="badge" decoration-info="stage_category == 'draft'" decoration-success="stage_category == 'progress'"/>
'recurring_next_date' field
set <field name="recurring_next_date" string="Next Invoice" widget="remaining_days" attrs="{'invisible': [('stage_category', '!=', 'progress')]}"/>
set decoration-bf on 'code' and 'recurring_total_incl'
move 'percentage_satisfaction' before 'recurring_total_incl'
set widget="many2one_avatar_user" on 'user_id'
add <field name="activity_ids" widget="list_activity"/> after 'user_id'
ELEARNING - website_slides.slide_channel_view_tree
set widget="many2one_avatar_user" on 'user_id'
'enroll' field
set <field name="enroll" widget="badge" decoration-success="enroll == 'public'" decoration-info="enroll == 'invite'" decoration-warning="enroll == 'payment'"/>
POS - point_of_sale.view_pos_order_tree
remove all decorations from <tree>
'state' field
make visible and move it at the end of the view
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state not in ('draft','cancel')"/>
set decoration-bf on 'name'
APPRAISAL - hr_appraisal.view_hr_appraisal_tree
'state' field
set <field name="state" widget="badge" decoration-info="state in ('new','pending')" decoration-success="state == 'done'"/>
'date_close' field
set <field name="date_close" widget="remaining_days" attrs="{'invisible': ['|',('state','=','done'),('state','=','cancel')]}"/>
PAYMENT - account.view_account_payment_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'posted'"/>
move 'company_id' before 'amount'
CONTRACT - hr_contract.hr_contract_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'close'" decoration-success="state == 'open'"/>
set widget="many2one_avatar_employee" on 'employee_id'
PAYSLIPS - hr_payroll.view_hr_payslip_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state == 'verify'" decoration-success="state in ('done','paid')"/>
set decoration-bf on 'number' and 'net_wage'
move 'company_id' before 'basic_wage'
set widget="many2one_avatar_employee" on 'employee_id'
SURVEY - survey.survey_tree
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-success="state == 'open'"/>
APPLICATION - hr_recruitment.crm_case_tree_view_job
set widget="date' on 'create_date'
set widget="priority' on 'priority'
set widget="many2one_avatar_user" on 'user_id'
TIME OFF - hr_holidays.hr_leave_view_tree
remove all decorations from <tree>
'state' field
set <field name="state" widget="badge" decoration-info="state == 'draft'" decoration-warning="state in ('confirm','validate1')" decoration-success="state == 'validate'"/>
apply the same changes in hr_holidays.hr_leave_allocation_view_tree
closesodoo/odoo#51305
Taskid: 2256589
Related: odoo/enterprise#10614
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Currently template rendering in calendar returns a tuple instead of real
results. This is a followup of 7159f657a0 and probably linked to cleaning
done in template while working on new calendar.
This commit makes calendar correctly use the rendering API.
Spotted when working on task ID 2238597
- 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>
- Go to the calendar list view
- Click on 'Create'
- Tick 'All Day'
- Set a start date
The end date is set to the day before.
This happens because in this case, the default duration is zero.
opw-2236766
closesodoo/odoo#49682
X-original-commit: 0b6ae3ed4ff20898cd88b97a644190b20f11cf8f
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
Known limitations
=================
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
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 removes the `state` field of calendar events.
The field was not displayed on any view and never used by any business code.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Some fields of a calendar event are private.
The previous implementation was deleted while refactoring recurring events.
This commit cleanly re-implements the feature.
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
IEL