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>
There is code that automatically enable or disable the cron whether it
exists alarms. As alarms are automatically added, the cron is actually
always enabled.
When emails related to calendar events are sent email_from is set from
templates like invite template. Author of those email is however not set
and current user is used as default value.
In this commit we do as done in templates and try to set event responsible
as user, and fall back on current user if not set.
This notably solves an issue when using website_calendar. Appointments are
done using public user and mails have public user as author. This leads to
emails not being accessible or having a false email_from.
Task ID-2413792
closesodoo/odoo#64061
X-original-commit: c01d95d371e859002f09520d3a97436f3b3087b8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
STEPS:
* Update cron "Calendar: Event Reminder": set Execute every 2 minutes
* create a recurring event:
* date: now() - 8 weeks
* time: now() + 1 hour + 3 minutes
* Repeat every 1 week, until "now() + 8 weeks"
* Reminders: "Notification-1 hour", "Email-1 hour", "SMS-1 hour"
* wait 3 minutes
* Wait 0-5 minutes
* Check menu ``[[ Settings ]] >> Technical >> Discuss >> Messages``
* Check menu ``[[ Settings ]] >> Technical >> Phone / SMS >> SMS``
BEFORE: you get mail/sms/UI notifications for all passed dates
AFTER: you get mail/sms/UI notifications only for the comming event
WHY: in v13.0-, recurring calendar.event records were virtual, so
_get_occurrences was used to generate those virtual records. In Odoo v14+ it's not needed
---
opw-2389877
closesodoo/odoo#63466
X-original-commit: 0e434d8cedd6ff9c65e539febeef220b0334e584
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
This commit adds a link to each calendar.event to join a video call
hosted on Jitsi.
The domain of the Jitsi instance can be configured using the
configuration parameter `website_jitsi.jitsi_server_domain` (defaults to
meet.jit.si).
TaskID: 2367543
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>
Issue
- Install "Calendar" and "Studio" modules
- Go to Calendar app an open any event
- Switch to Studio mode
- Add a selection field X in the form then close Studio
- Go to list view and try group by X
Error message : "Grouping by X is not allowed."
Cause
`_get_public_fields` does not get custom fields created with studio.
Solution
Add custom fields to public fields.
opw-2402667
closesodoo/odoo#62640
X-original-commit: a2388931710e1043540bbf2de131d4783af17d0b
Signed-off-by: bon-odoo <nboulif@users.noreply.github.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>
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>
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>
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>
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>
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.*
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.
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
Issue
- Install Calendar, HR Recruitment & Studio
- Go into Calendar
- Create a recurring event
- Edit it with Studio
- Add a related field
- Select Applicant > Assigned
Traceback
Cause
Applicant > Assigned is a stored field.
Adding a stored field seems to triggers
something that recomputes all models
odoo/odoo:odoo/modules/registry.py@12.0#L307
Then it calls the _write method of models.py
which uses self.ids (which contains virtuals ids)
for a SQL query.
odoo/odoo:odoo/models.py@12.0#L3428
Solution
Avoid all the virtuals ids to be retrieved
when we have "update_custom_fields" in
the context.
OPW-2214170
closesodoo/odoo#48208
X-original-commit: 112f976eb193020c093068fd30a004be3f5e9254
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Before this commit, when user attempts to edit or delete a private
event without being an attendee, it raises an access right error.
This commit disables edit and delete buttons in this case, in
addition to hide event details.
task-2151150
Closes https://github.com/odoo/odoo/pull/42569closesodoo/odoo#42569
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- install calendar
- create a recurring event with 0 repetitions
- save
Previous behavior:
raises an UserError, this would interrupt the sync with google calendar
Google calendar sometimes sets recurring events to 0 repetitions
once they are done recurring
Current behavior:
the event is handled like a punctual event but remains recurrent
initial commit: https://github.com/odoo/odoo/commit/ba727e15d2dc9a1325cd20527e2ccfe6f8bc63f0
opw-2185699
closesodoo/odoo#45947
X-original-commit: 5b63ddb4e03f34f015e7668c69108fb4a2badd08
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Install Projects, documents, calendar, website, crm.
Under Settings enable "File Centralization"
Now go to Projects, enter in a Task, click on "schedule activity".
On the activity form under "Activity Type" choose Meeting, click on
"Open Calendar" button.
Choose a slot, edit the event, add a contact type individual, save
Error will popup.
This is caused by the whole flow of creating a new document for the
invitation.ics generated for the meetings which has to be sent via email
but get detected as an attachment to be sent into the document app as
well.
Disabling the document creation since it is not a relevant attachment
opw-2150770
closesodoo/odoo#43537
X-original-commit: 4e30db33938d4d740d847cfbc6a29b4013be964d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
When the event is private and some other user going to
see the event at that time it was going to display the
archived ribbon because the active field was not in the list
of public fields(readable field).
so added an active field to the readable list so it will display the
propper archive ribbon on a private event.
Task-2144553
closes odoo/odoo#41589
Closes: #41157
X-original-commit: c1b89567ca3fdd6f4004389aad345ad3e52248c3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently when other users view the private event of
another user it display the name of the private event as
'false' instead of 'busy' and onclick of event it generates
traceback.
so to fix it added display_name in condition of read because
the event name displayed in calendar view(previously name) is
replace by display_name in commit 369c20a99b
Task-2144553
Closes: #41157
X-original-commit: 1ec853751bd995449619585db8e17f582ba5e5bc
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
Julien Castiaux