RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
'_sms_get_default_partners' exists in SMS to find default customers to
notify when sending automated SMS. It can be replaced by '_mail_get_partners'
helper available on BaseModel in mail.
A specific case exists in calendar where it was overridden to avoid notifying
attendees that declined the event, notably for alarms. This feature has been
moved directly in the reminder sending method, to keep behavior coherent.
Test is updated accordingly, and is now really using the SMS mocks to simulate
the sending.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
Probably due to a copy paste, _compute_sms_template_id on sms_template_id field
of alarm model is not correctly called. It refers to the mail template instead
of the sms one.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In order to prevent sms spamming the responsible of events, for users
having a lot of calendar events, like hairdressers (through appointment),
we add a field on the calendar.alarm model to make the sms reminder
optional. As not reminding the responsible is meant as a default
behavior, sms_notify_responsible is False by default.
This field is only meant for sms alarm_type. Indeed, by default, email
are not issued to their author and if the responsible is set in the
calendar_event, it will be used as author. Notifications are not
concerned by this issue as we consider we want to always receive the
internal reminder.
In order to distinguish between sms alarms with or without responsible
reminder, we add " - Notify Responsible " to the sms calendar alarms
with the option set to True. (This is also useful when alarms are used
in a m2m, like for appointment types or calendar events.)
Task-3032570
closesodoo/odoo#104327
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Issue :
- When sending an sms reminder by cron user, `_get_display_time` is
used which always uses Odoobot (cron user) timezone regardless of the
partner timezone
Fix:
- use `partner_id.tz` instead of Odoobot
OPW-2991624
closesodoo/odoo#105243
X-original-commit: 23d39f6de7ee656773f3e8f2515adfefc137c866
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Steps to reproduce:
- create a contact with a phone number
- enable IAP-sms
- take off the number of the admin-contact
- create an event in the calendar with a "text-sms reminder" with the new created user
Issue:
No sms will be sent
Cause:
The IAP server-side does not accept request with `number` set to False such as in:
```{'messages': [{'res_id': 23, 'number': False, 'content': 'Event reminder: test-local, 07/11/2022 at (15:46:00 To 16:46:00) (Europe/Brussels)'}, {'res_id': 24, 'number': '+32487253270', 'content': 'Event reminder: test-local, 07/1>
Solution:
Filter partners with a valid phone number in `_sms_get_default_partner`
opw-2867763
closesodoo/odoo#99697
X-original-commit: 512010cfeb80fd6f5511888ddbd58dd26212105b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
Fix a typo in a default / field name for SMS composer.
Task-2613245 (Server actions mail update / cleaning
closesodoo/odoo#97757
X-original-commit: 835c68e574ebae5980f57c53dc3c9fd1cd1707c1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
A duplicate of SMS rule for SMS template model for admins exist in calendar_sms
application.
Followup of odoo/odoo@23c82340c1 that broke some rule and was fixed with
odoo/odoo@13bf64b376 where a dummy rule was used to avoid removing data
in stable.
We can now remove some useless rule data.
closesodoo/odoo#86254
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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
odoo/odoo#64626 attempt at improving sms.template rules seems quite broken
* do not restrict system group to calendar.event: this makes no sense.
With this fix admins can now only use templates being linked to calendar
event if calendar_sms is installed which is not really smart. Not sure
what was the exact original purpose;
* ir.rule in hr_presence has no use on hr.manager group if they do not
have any access through access rules. Indeed they are currently
restricted to read access as all standard internal users;
Task ID-2191254
COM PR odoo/odoo#68445
ENT PR odoo/enterprise#17340closesodoo/odoo#68495
X-original-commit: 9353dedaf9111e5ee3ab5ed98e3571d5ac83cae8
Related: odoo/enterprise#17359
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
sms.template model has several record rules to give access to templates
linked to models managed by certain groups (like crm.lead for sales managers)
These record rules were meant to restrict access to certain model to create,
write and unlink, but not read.
This is leading to issues when trying to read a template on other models.
Indeed people should always be able read sms.template content.
Unit test were also added to the sms module to ensure that a member of
group_user can always read a sms template.
Unit test is added to ensure admin always has full control on sms.templates.
Task ID-2191254
COM PR odoo/odoo#68445
ENT PR odoo/enterprise#17340
X-original-commit: 6a00157f79be30a6efd6d039504c57be07c449fd
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>
BEFORE: sms templates from these modules become inaccessible if any module from
the list below is installed
* crm_sms
* event_sms
* stock_sms
* enterprise/account_followup
* enterprise/marketing_automation_sms
* enterprise/sale_subscription
those modules add security rules for sms.templates, which adds additional
conditions to get access: at least one security rule has to be passed. So, we
need to add such rules to give access not only to Superuser
closesodoo/odoo#64661
X-original-commit: 23c82340c1cbd3d5a25d5c2ecec6c7d0f988cd90
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.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>
Currently, when go to calendar > list view > action > send sms
to attendees, it will generate the the traceback because default
composition_mode is comment while when you process through the
list then sms_composition mode should be 'mass'.
So in this commit, pass the sms_composition_mode as 'guess' so
it will automatically check the record and take the correct
composition mode and also pass the active_ids as res_ids.
closesodoo/odoo#61909
Taskid: 2344284
X-original-commit: 200ab9fdaeb9cf6f8afcf572c013e2b6cc1e70df
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* calender_sms, hr_expense, sale_project
PURPOSE
Enable the framework to define some of actions in the controlpanel,
as buttons similar to the 'create/edit/discard' buttons.
SPECIFICATIONS
Replace the below-mentioned dropdown actions with controlpanel buttons
- 'send sms to attendees' in Calendar > Calendar
- 'approve report' in Expenses > Expense Reports > To approve
- 'post entries' in Expenses > Expense Reports > To post
- 'register payment' in Expenses > Expenses Reports > To pay
- 'create invoice' in Field Service > All Tasks > To Invoice
LINKS
PR https://github.com/odoo/odoo/pull/57830
Task-2300426
closesodoo/odoo#57830
Related: odoo/enterprise#13272
Related: odoo/upgrade#1785
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Gorash