| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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#17340
closes odoo/odoo#68465
X-original-commit: 7c4c20a6be78c98e44fcc580b54a12110d238a65
Related: odoo/enterprise#17348
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: c9e119a096ba5410e0ab9767207192eb4b7822a2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from #64626
closes odoo/odoo#64928
X-original-commit: 1a34778beccd634d0b812afe303fa48debdfdedc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.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
closes odoo/odoo#64654
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/52645a7b43be157be0782674a0f6b38359293f21
Fixes #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).
closes odoo/odoo#63549
X-original-commit: eb02393d2b2b3aee48cfd1d24766ca74bc28fb85
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
closes odoo/odoo#62701
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.
closes odoo/odoo#60330
Taskid: 2344284
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
|
|
|
|
Except Spanish, waiting for cleanup
closes odoo/odoo#60848
Related: odoo/enterprise#14421
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
There was a problem in the Transifex translations for Spanish and all
translations were overwritten by mistake with english defaults.
This commit reverts all modified es.po files to their previous version
while we work to restore the translations on Transifex.
|
|
|
|
|
|
|
|
|
|
Without demo data
closes odoo/odoo#56839
Related: odoo/enterprise#12821
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Convert deprecated tags through the codebase.
|
|
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.
closes odoo/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
closes odoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
SMS reminders are not timezoned
closes #38243
closes odoo/odoo#38893
X-original-commit: 93d17be423d27c2e5eddf313327133082995f003
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
That will be used a the basis for the future 13.0 version
Without demo data
closes odoo/odoo#36057
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Clean the use and options of sms composer after FP feedback :
* see https://s.nimbusweb.me/share/3167586/ap1xpy95rz29a5cys576 as basis;
* globally, do not display invalid recipients, only valid / invalid count
as well as current selection / active domain counts;
* consider logging a note as default behavior when using the composer;
* simplify code: when doing a mass SMS, send SMS and attach a simple note
to the document;
Some other points
* make name of sms templates translatable;
* improve various wording, notably in sms widget;
* display error code in sms list view;
* update sms composer actions accordingly by correctly setting active id
or ids;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
|
|
closes odoo/odoo#35404
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
PURPOSE
Improve integration of SMS in various applications: calendar, contacts.
SPECIFICATIONS
Calendar_sms: set right composition mode on calendar event in form mode
aka comment
SMS: keep log when sending SMS in batch through action menu
Linked to task 1925950 and 1935280
Part of PR #34864
|
|
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
|
