This commit follows https://github.com/odoo/odoo/pull/64948
Before this commit, the mail composer was not properly used. It was not started with a model and business document ids.
This commit also reverts a keyword context value for the sms composer.
closesodoo/odoo#69910
Taskid: 2342252
X-original-commit: 14629c8e1778269dc2ccc0dedd5e39b23c78669f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
The purpose is to allow the user to have the opportunity to manage what is
going to be send as reminders. He can now access to the template or create
a new one when the type of reminder is email or sms. In case of a simple
notification, a new text field is added to add custom content.
Task ID-2191254
COM PR odoo/odoo#68443
UPG PR odoo/upgrade#2313
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to ease sending mail to attendees using template
by using a template record instead of an xml id. Indeed this allow having
flows using a configurable template instead of an hardcoded one.
Code in calendar_sms is split into main models to ease future improvements
related to SMS.
Taks ID-2191254
COM PR odoo/odoo#68443
This commit improves multiple small details in the calendar application.
UI, UX mostly:
* some labels were confusing
* the invisible attribute were not set in popover view
* the sample data were missing
* ...
taskid: 2342252
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>
in a cron run frequently.
The cron "ir_cron_scheduler_alarm" stores its last run datetime in an
ir.config.parameter. Since modifying config parameters cleans the
cache,
the cron clears the cache every 30 minutes, unless modified...
As the cache is used to improve global system performance, clearing it
frequently should be avoided as much as possible.
Since v13, ir.cron records now store their lastcall datetime, there
is no need to keep the information in a config parameter anymore.
This commit uses this lastcall information instead, as it was done for
the calendar module:
See
https://github.com/odoo/odoo/commit/52645a7b43be157be0782674a0f6b38359293f21Fixes#63354 for 13+ versions.
For earlier versions (12.0), it cannot be "fixed" since the lastcall
information isn't available (note that the cache clear also happens in
the base calendar method in 12.0).
closesodoo/odoo#63560
X-original-commit: 10c08157cb152f111bc9df783e15632c52a61b39
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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>
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.
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
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Purpose of this commit is to include SMS templates and the new sms messaging
API and methods in calendar_sms and hr_presence. Templates allow people to
customize the content of sent SMS. New SMS messaging API allows to track
notification status when sending SMS.
Related to task 1922163
Linked to PR #33510
Purpose of this commit is to better include SMS notifications when posting a
message. SMS is now just another way of notifying people along with Inbox and
email. Following recent mail merge improving notification mechanism [1] we
have to define a _notify_record_by_sms method on mail.thread.
When a message_post is done using message_type being ``sms`` notification type
of customers is set to sms. Customers can be computed on model (generally based
on partner_id field) or directly set usign partner°ids. Notification model is
updated to store this information directly inside the notification itself.
An new ``_message_sms`` helper method is introduced in SMS module allowing
to send messages using sms type and notification with a reduced parameters
number. It is just a shortcut to message_post, easier to use. Either it
computes default recipients on the record set, either it is based on given
partners and numbers to notify.
The following use cases are notably supported
* default computation: find customer, notify by sms;
* force recipients to notify by sms (partner_ids);
* give a set of numbers to notify by sms (sms_nubmers), not necessarily
linked to existing partners;
* force number / customer relationship independently of mobile number defined
on customer (for example when sending an SMS directly from a mobile field
on a lead linked to a customer);
Tests are updated accordingly. Performance tests are added in order to have
some insights on queries generated when sending SMS, like already done for
mail.thread alone.
Related to task 1922163
Linked to PR #33510
[1] see be27955136: performance and notification code improvements
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Even if data is not really sensitive, there are no reason to let it public.
closesodoo/odoo#33326
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Yolann Sabaux