Currently the summary and description in event ics file generation
are set directly, with a condition in case the event is an appointment.
We make these two ics 'fields' use a getter so that it can be
overriden inside appointment instead.
In addition we remove the special formater for 'online events'
as it is only used for appointments, which does not use it anymore
as of this task
task-3232952
closesodoo/odoo#116211
Related: odoo/enterprise#38570
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Currently the chatter of a private event is unavailable to excluded users
but a end user might be confused as no explanation message is currently
displayed on the chatter.
closesodoo/odoo#120545
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This task change the people who can edit a calendar event.
This calendar event currently allow every user to modify every
event in the calendar. This cause issue where one user can
modify the time-off event for other employees.
This PR change the right to modify an event from the calendar
view in the calendar app. With these changes, only the people
attending an event will be able to modify it from the calendar
view.
task-id : 3185743
closesodoo/odoo#112964
Signed-off-by: Arnaud Joset <arj@odoo.com>
The `read_group` of `calendar.event` sends a danger notification when
the user groups by any field in the list view. It is because the
security reenforcement done in 2c0b3ab670168a155b3974d5a5b39aa1f1df3452
is too strict. It checks all `fields`, even the ones that are filtered
out by the `read_group` (`fields` without aggregation specification
nor `group_operator`).
closesodoo/odoo#119459
Signed-off-by: Raphael Collet <rco@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = base_geolocalize, calendar, website_crm_partner_assign
Oversight of discuss refactoring. Code is restored into bus module as it
does not depend on any mail or discuss feature.
closesodoo/odoo#119243
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
Issue:
------
It is possible to create recurring events
that are in the same DST period.
Unfortunately, the basic event is sometimes duplicated
Cause:
------
The cause comes from the Daylight Saving Time (DST).
With the base event, we create a recurrence.
This recurrence will create all the events
of the recurrence.
To achieve this, with the basic event, we create all the ranges.
Then, we compare these ranges to remove those which already have
events.
Logically, we must reconcile the first range with the base event.
Sometimes the range of the base event and the first range
calculated to generate the occurrences do not match.
The consequence is the creation of a new event.
The cause of this problem is that we go back too far to find
the starting date of the period from which we will generate the ranges.
For example, in the case of a recurrence with a frequency of `MONTHLY`,
we will take the first date of the month.
And if we are in the month when the DST changes,
we will have the problem.
Solution:
---------
The solution is not to go back
if we encounter a difference in the DSTs
between the starting date of the base event
and the starting date for generating the ranges.
opw-3143680
closesodoo/odoo#119073
X-original-commit: 065dd4a2548ff0da6cf23a7ac62321ce99500d35
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This commit consists of a full rework of the quick create form in the calendar
view, so that it shows more options to the user rather than only the name of
the event. To accomplish this, we added a new attribute on the calendar view
with the id of the quick create form view to be used. This allows us to have
a custom view to be shown on quick create.
task-3129030
closesodoo/odoo#114827
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Calendar popovers are now easier to read and navigate.
If an event contains a lot of information, its popover now grows tall
instead of wide.
In case of more than a few attendees, the widget shows a summary and
allows the user to expand the full list.
The displayed total number of attendees is now accurate, without the
default field limit.
task-2685440
closesodoo/odoo#112114
Signed-off-by: Arnaud Joset <arj@odoo.com>
Changing end time for recurrent event will generate an error.
steps to reproduce the error:
1- Create an event in the calendar app with recurrence on
2- Save and close
3- Edit this event again and select change all events at the top
4- Change the ending time
The error was happening because the wrong key was accessed in a
dictionary
opw-3236432
closesodoo/odoo#118087
X-original-commit: 97f51b24da5db1a0217121aae583a9c1d715adc4
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
On a calendar event, the 'free' option does not hide the element.
So that the user doesn't expect this behavior,
you have to modify its description.
opw-3047999
closesodoo/odoo#117654
X-original-commit: ecc850f4df1151a793d36fdd58621665a6e1a414
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
In case the videocall_location was a relative URL, the link wouldn't work
properly. This commit fixes this by converting all URLs to absolute
automatically. Note that this only works for http and https protocols. If
using proprietary schemes such as :skype is desired, this implementation
should be done in the respective module.
X-original-commit: 16fb60e193d0c79333d95ef2f31f0ec01830571f
Part-of: odoo/odoo#117214
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a personal calendar filter
record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
When following recurring meeting are imported through google calendar
synchronisation, it happens that a meeting get unexpectedly
duplicated in Odoo, what will in turn duplicate the event on google
and send invitations to all the existing attendees.
As calendar.recurrence.calendar_event_ids is a One2many field,
the update using self was setting the base_event_id's recurrence_id
field to the last record of self recordset. Due to this, the event
will not be considered to filter out the existing_ranges in
calendar.recurrence._reconcile_events function.
Therefore, a calendar.event will in turn be created using the same
start and end datetime as the base_event_id of the calendar.recurrence.
OPW-3143680
closesodoo/odoo#114392
X-original-commit: d1587758ac642b0181e660ea48222385d01098e3
Signed-off-by: Arnaud Joset <arj@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
The goal is to be able to use Query objects for both subqueries and
known ids tuples. This provides a single API for injecting either a
subquery or its resulting ids into another query.
Part-of: odoo/odoo#112126
Method 'message_notify' is a simplified version of 'message_post' to use
to notify people of something, without posting on a document. It creates
a "user notification", a specific kind of message.
In this commit we make 'message_notify' process attachments like posting
does. That way the API is more similar between those two methods. Moreover
it allows to give 'attachments' to notify. Those are then transformed into
real 'attachment_ids' and converted if they come from the composer.
That way the mail composer can be used in notification mode with attachments.
This happens notably when using a template on a record that does not inherit
from MailThread. It is a classic usage of 'message_notify' which allows
notifying on documents that have no chatter, notably technical or admin
oriented models.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Overriding the _compute_field_value in order to only prefetch the currently requested field
opw-3141262
closesodoo/odoo#110489
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
If there was an issue an the lastcall value for the calendar cron
the cron would raise an error. This commit give a default value to
the lastcall equal to one week ago.
task-id : 3102295
closesodoo/odoo#110154
X-original-commit: e0aa273104ce576cd2746340f0e2c5c4af4a86bd
Signed-off-by: Arnaud Joset <arj@odoo.com>
Currently when using the composer to create a mass mailing emails are sent
directly, unless scheduled date is in the future.
With this commit it is now controllable through a field like what has been
done on SMS composer. Its default behavior is the same as before
* posting on a monorecord: force send notification emails;
* posting on multirecords: use the queue (force_send=False parameter given
to message_post and propagated to _notify_thread);
* mass mailing: use force send to send emails directly;
Usage of mail_notify_force_send context key is also removed when possible
as it is a standard parameter of posting API.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
Before this commit: syncing with google led to sending emails to
attendees of existing future events on Odoo.
Steps to reproduce the first issue:
Install 'google_calendar' module
Integrate with Google Calendar in setting
Add an event to the Odoo calendar for future date
Add one external attendee to the event
Sync with Google
Invitation emails would be sent to the attendees of the events.
Solution
It's possible to not send emails to the attendees in api calls. So
the solution is to not send emails to the attendees for the syncing
time.
opw-2819046
closesodoo/odoo#102870
X-original-commit: 5a56e37a5f54662b1f3593930738e51c010abab7
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, the default values of a recurrent meeting were overriden
by the false value, resulting in "count = 0" dans "weekday = False" in the form
view of recurrent meeting by default.
TaskId-2999194
X-original-commit: c8d9eefdc99eaacc124eebf7f0cbaabed4e38bf4
Part-of: odoo/odoo#101492
Currently, if we create an activity for user other than logged in one and
create a calendar event from the activity, it automatically changes the
attendee on the event and re-assigns the activity to the logged in user
instead of the one originally assigned to the activity during creation.
It happens because default attendees are not passed while creating the
event from activity. ALso, when editing the calendar event, the sync
mechanism changes the activity user to the organizer of the event, which
by default is logged in user.
This commit improves the behavior by passing the appropriate default
values so that the calendar attendees and organizer matches with the
user to whom the activity is assigned initially.
task-2920631
closesodoo/odoo#96943
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Switch to debug mode
- Go to calendar
- Create an allday event in the future named test
- Add an attendee with an email address
- Save
- Go to Settings > Technical > Email > Emails
Two emails have been sent:
* Invitation to test
* test: Date updated
Cause of the issue:
The method `_inverse_dates` is called when creating an event,
triggering a write on the start field.
This then causes an update email to be sent
Solution:
Add a context key and don't send the update email if it is present
opw-2841276
closesodoo/odoo#100925
X-original-commit: d1e55727d010de2cd05bd2871b60d0e95caaaebf
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Since 3a145216a6a6fb259c5afef6175669c8a65ba39f, partner_info value
was changed but not it's usage.
This commit also simplify the code for better understanding.
closesodoo/odoo#99422
Task-id: 2954397
X-original-commit: a667179e43ab00a8384b75923769782f1836c24b
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
MailActivity model has an ``_action_done`` method that is quite heavily
used and overridden. It notably posts messages, create next activities but
also has some specific behavior depending on category.
Purpose of this commit is to improve code of this method to avoid useless
queries, improve performance, and rethink the computation with batch in
mind.
Task-2883589 (Activity performance and cleaning)
Part-of: odoo/odoo#93682
Purpose is to have one file / model, easier when searching for inherited parts
of the code and see at a glance various usage of those models.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
* = calendar, im_livechat, rating, snailmail, test_discuss_full, test_mail,
website_livechat
Distinction between "replace" and "insert-and-replace" can be guessed based on
the type of the provided data.
task-2957295
closesodoo/odoo#98404
Related: odoo/enterprise#30580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When an online appointment (having no location set in it's appointment type) is
booked, we need automatically generate the `videocall_location` so that in the
confirmation email received by customers already has a link to join. For
building this URL, we need to use 'DISCUSS_ROUTE' when appointment is being
created (see the linked ENT PR).
For making 'DISCUSS_ROUTE' easily accessible, instead of keeping it as a global
variable, we now make it a class property of the model `calendar.event`.
taskID-2821957
closesodoo/odoo#92628
Related: odoo/enterprise#27136
Related: odoo/upgrade#3558
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to follow:
- Set your timezone to New York
In linux for example with: `timedatectl set-timezone America/New_York`
- Verify that the user timezone is also set to NY
- Create a reccurent event the 6 july 2022 (a wednesday)
- In options, check the recurrent box
- Set repeat to once every week
- Thursday is the only day checked
-> It should be Wednesday
Cause of the issue:
When `_compute_recurrence` is called, `event.recurrence_id` has not
yet been set
-> `event.recurrence_id.event_tz` is False
=> Copy the defaults before computing the start date and check the
timezone of the event itself
opw-2886253
closesodoo/odoo#96049
X-original-commit: 7186dbad38ef1f05919c398f3c0c5f5d8f8b2219
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
As several customers complained about lot of bugs in microsoft_calendar in 14.0,
It has been decided to backport bug fixes of the model layer from master to 14.0,
without the need of an upgrade script (no new field, ...).
In master, we use 2 ids (organizer event id + universal id) instead of only one,
to handle Odoo <-> Outlook sync correctly when several attendees sync their Outlook
calendar with their Odoo calendar. For that, we have added a new field.
To report this bug fix in 14.0, the existing field which stores the organizer event id,
is now a string storing both ids separated by a ':' as follow: 'organizer_event_id:universal_id'.
2 new compute fields have been added to be able to use these 2 ids more easily.
(all commits from the original PR have been squashed to ease forward-port)
closesodoo/odoo#95736
X-original-commit: 5e83318a7240585371efd31e407829793f3e732f
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Since the access_token is used in the videocall_location route, it makes sense
to create an index on this column to allow faster lookup. This commit adds the
index to this field since it's creation in 15.3.
closesodoo/odoo#94714
X-original-commit: 3b753dc2f5fcac03f719cd16e9c0216bae83e9b7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
We can use ._search() to make sure that permissions and ir.rules are applied. By making use of psql subqueries, we remove the need of costly python filtering afterwards, thus increasing performance.
Created test_meeting_count() to check that that the computing of meeting_count is done correctly.
closesodoo/odoo#91325
X-original-commit: 2df40ab03d29045546fbf7f19203e66796d52dc0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
To reproduce
============
- configure a default note on the "Meeting" type activity in html in the settings of crm
- create a meeting type activity from an opportunity: the activity created in the chat of this
opportunity is well formatted in html (the layout is preserved: bold line break, highlighting...)
- create the meeting corresponds to the activity in the calendar: the html format in the note is not kept
Purpose
=======
when creating the meeting we convert the html to plain text
Specification
=============
to solve the issue we removed the conversion to plain text.
opw-2825252
closesodoo/odoo#91079
X-original-commit: 7d19020b7ff15b8b9e14f38c96312e1c2d1cecb4
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Because private fields would automatically add a bunch of fields to
the user's request (in order to do their own post-treatment), unlike
normal behavior `read([])` would be completed to `read(['privacy',
'user_id'])` and would fail to trigger the "select all the fields"
behavior of `BaseModel.read`.
Move the privacy management to a `_read` override instead. Also update
the code to be more linear and straightforward, without a bunch of
intermediate helper function.
This is also a small performance optimisation, although apparently
much more minor for 14 (best case of about 5%) than on 15.0 (where it
seemed to reach 30). The gain is mostly for private events being read
for non-participants: because the non-public fields get neutered
before computation (rather than after), fields are computed on a
neutered basis and thus largely do nothing. This is especially salient
with computations relying on relations (in this case
`attendee_status`), as from an empty starting point they essentially
do not do anything.
This leads to the effort (and cost) of private events being read by
non-participants to be about the same as the cost of public events,
whereas before the change there is a visible overhead. The signal is
quite noisy though.
NOTE: backported the addition of `privacy` to the public fields from
2f4a91c0ce as that is better
behavior and makes the tests more logical (and easier to forward
port probably)
OPW-2831113
closesodoo/odoo#89936
X-original-commit: b0c6f2969596fb715e0a6c62865b5c7dbc0bcc78
Related: odoo/enterprise#26699
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A reorganization of the calendar alarm form view was necessary for easier
extension with new fields
(such as the one from appointment, see links).
The partner is now the author of notifications about their invitation
(instead of public user).
Task-2709580
See odoo/enterprise#23191closesodoo/odoo#82387
Related: odoo/upgrade#3383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit aims to integrate the calendar module with discuss video calls.
Now it is possible to add discuss videocalls by clicking on a button below
the videocall_location field. The discuss videocall_location is a URL that
is computed and it creates a discuss channel only when someone accesses that
URL.
For recurring events, the same discuss channel is used for all events.
However, each event in the recurrency has its own videocall_location URL.
This is done on purpose in order to allow the functionality even if the base
event of the recurrency is deleted. For single events, each event will create
a discuss channel.
task-2685472
Part-of: odoo/odoo#79654
Renaud Thiry