Purpose of this commit is to clearly check input of ``message_post`` method
and its main helpers in order to prevent wrong usage of message post API.
Some values used to populate message fields should not be set directly when
posting or logging messages. Indeed they may be part of other process (like
notification process managed by ``_notify_thread``, or could be setup by
custom routes like 'reaction_ids', or custom usage of 'model' and 'res_id'
that could conflicts with record on which methods are called).
We therefore add checks and cleanup in those methods to be sure the API
is used as intended and avoid unwanted side effects.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose is to be able to create find or create partners in batch based on a
list of emails. When sending email in batch, notably using templates, doing
sequentially a search or create for each potential email to contact is not
efficient from computation point of view. This commit introduces a new batch
method for that purpose.
If no valid email is found for a given email, it is used as it to try to
find partners with same invalid email and/or keep the value in order to
allow updating it afterwards. Notably with notifications resend it is
possible to update emails, if only a typo prevents from having a real
email for example.
Falsy emails do not create partners as those have no real interest.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Fix usage of CCs when sending emails. Currently CCs are added to all outgoing
emails, which leads to unnecessary spam. Recipients are currently computed like
* create an outgoing email based on 'email_to';
* create one outgoing email / partner in 'recipient_ids';
* add CCs to all outgoing emails;
They are now sent only once, either with the email_to if given, either as
standalone. That way partners receive specific emails (due to tracking and
partner specific links management), email_to / email_cc are sent on their own.
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
In this commit we add some logs when we fail to evaluate the 'headers' field
on a 'mail.mail' record, used to populate the headers of outgoing emails.
Some tests are added to ensure we do not crash if headers is malformed, and
to cover the feature itself as it was still not really done.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
RATIONALE
When sending a ``MailMail`` some data preparation is done. This is done
directly in ``_send`` and in sub-methods. As a given MailMail may lead to
several emails being sent we have to go from a mail to a list of emails
to send :
* one email for ``email_to``. They all receive the same email, as those are
just a list of emails to contact and no specific post-processing is done;
* one email for each partner in ``recipient_ids``. It enables a partner-based
update of the body, for example for links or traces in mass mailing;
SPECIFICATIONS
In this commit we move code so that all preparation is done in a sub-method
``_prepare_outgoing_list``. That way it can be cleanly overridden to add or
modify values before sending the actual emails.
This commit does not change behavior and calls done to ``build_email``. This
will be updated in the next commits, notably to improve "cc" management.
Task-2710804 (Mail: Clean MailThread Posting API)
Task-3093268 (Mail: Stop spamming CCs)
Prepares Task-2684479 (Mail: Better report errors when sending emails)
Part-of: odoo/odoo#99482
Composer holds code to check recipients email and avoid sending emails when
recipients do not have valid emails. Purpose is to avoid bloating the email
queue with emails that are about to fail.
It is done by analyzing recipients of emails, aka checking 'recipient_ids'
value before creating the mail.mail.
When being in comment mode, this code has no use as recipients are computed
by the notification process, not by the composer. We can therefore skip this
part. It adds the 'state' and 'failure_type' values that are used on mail
model, but not on messages.
The same kind of processing could be done in notification process to avoid
sending unnecessary notifications, but this improvement belongs to another
commit and task.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In this commit we add a method to check MailMail, based on a given record.
When having duplicates to differentiate in a given mailing, having just
recipients is not sufficient as multiple emails may match a given recipients
list. Checking model / res_id is another method for finding emails.
This will be used notably to add tests for exclusion list and duplicates
management in standard mail composer, outside of mass mailing context.
While being at it, use subTests when having loops checking values. That
way it is easier to fix tests that have several failing values in the same
global assertMailMail_* .
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
In this commit we correctly set 'error_msg' field as computed. As it was not
defined as computed, it was not really updated and therefore not displayed
in the preview form view. It is now the case.
ValueError are now also catched, for example when having badly configured
'partner_ids' field we may face this kind of error, which is now logged
in the preview wizard.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Sometimes the previewer crashes in rendering with cache-based records, hence
trying to check directly the id of the related reference record.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Mail holds an helper function to convert datetime from a char input into a
datetime value. It is used notably when having to store a datetime value
(e.g. on a mail_mail) from a string generated by templates with expression
like ``{{ datetime.datetime.now() + datetime.timedelta(days=2)}}``.
In this commit we explicitly remove microseconds, as otherwise we end up with
something that the web client cannot parse, not speaking of even going into
server side storage with this value not matching the expected format.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Enlarge selection fields of record and language in the template preview form so
that the labels are not truncated.
Task-3098782
closesodoo/odoo#110075
X-original-commit: f1ac110cb71d982acd9d6cdbccaf6d2415a38736
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
before this commit, there is no form view defined for the mail.guest model and on accessing these record from Guests menu under the settings, is returning odoo generated form view.
after this commit, clean form view will be displayed on accessing the Guest menu.
closesodoo/odoo#109826
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
To Reproduce
============
- add event on calendar
- edit the event and remove the user from participants list and add another one.
- save the record -> traceback
Problem
=======
we try to read `hasReadAccess` from `this.followedThread` that is `null` in this case.
Solution
========
check if `this.followedThread` is `null` or not
opw-3126545
closesodoo/odoo#109721
X-original-commit: f9a23af63bb5fe882f0d42f06ef1406910836115
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue: `node.data` is an unescaped text content and used as an escaped
content just after (set `innerHTML`) which remove some of the escaping.
Without the fix, the 2 new first assertions would fail:
- first one with 'https://example.com/?¤cy_id' instead of
'https://example.com/?&currency_id' in the text node
- second one with `&` replaced by & and `>` replaced by >
other assertions ensure that use case before the fix (special char and
URL regex, smileys, ...) still work the same after the fix.
opw-2525028
Fixes#70485closesodoo/odoo#109357
X-original-commit: 4938af5dd8bfb4ea0722e3de8340ff6437329b48
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Current behavior
In the recruitment module, if you set an email template for the first step of
a job recruitment process you cannot send any other email using the full
composer. This happen because the partner type goes from 'contact' to 'private'
and this type cannot be set as recipient in the full composer.
Steps to reproduce
- Go to any job recruitement and set an email template for the first
step
- Go on the website and apply for this job
- Go back to the job application and send an email using the full
composer, the email is not sent to the applicant. And the applicant
is not added to the followers.
Fix is to somehow improve support by adding asked partners from default in
context.
Note that this does not change anything from ACLs point of view, as trying
to access private partners without the necessary group or ACLs will raise an
access error anyway.
Also note that private partners defined on a template are still stripped
as they do not respect the new (nor the old) domain. That would be tricky
to solve, better not use private partners in templates.
opw-3010308
closesodoo/odoo#109451
X-original-commit: 12b25f21216b11511d5fed22fb3564d9dc297559
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Part-of: odoo/odoo#109522
Co-authored-by: Robin Engels <roen@odoo.com>
Add tests showing current behavior of partner_ids fields on composer when
dealing with private partners. Some use cases are added as unit tests
* default_partner_ids: coming notably from suggested recipients;
* template usage adding a partner (e.g. partner_to);
* when not having the rights to see private partners, access error should
be raised;
* mail gateway when a private partner sends an email;
X-original-commit: 2153eec790b730761fe50d6bea5cd4bacedce97a
Part-of: odoo/odoo#109522
Co-authored-by: Robin Engels <roen@odoo.com>
Since the refactoring of the activity view, luxon is not in the
rendering context. Resulting in crashing in some activity views
that used luxon in their template.
- Go to Appraisal
- Switch to the activity view
- Create a record in this view -> crash
Now, luxon is in the rendering context.
closesodoo/odoo#109153
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before, in activity view, it was not possible for users to hide
never used columns.
Now it is possible for users to hide and show columns in the
activity view.
task-3039919
Part-of: odoo/odoo#109153
This commit adds checks in the view validation, to detect the use
of implementation details in archs. The goal is to prevent people
from using owl directives in archs (e.g. t-on-click). Recall that
a view arch isn't an owl template, it must follow the DSL of the
given view type.
In kanban, gantt and activity archs, using `t-xxx` attributes is
forbidden, except for directives historically supported by qweb
(e.g. `t-esc`).
In other views, using `t-xxx` attributes is forbidden (except for
`t-translation`).
In all views, using attributes `data-tooltip`, `data-tooltip-template`
and `data-tooltip-info` is forbidden.
Task 3085357
closesodoo/odoo#107083
Related: odoo/enterprise#35352
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
All emails sent from the chatter start with "Re:" followed
by the name of the record. The name of the record alone is sometimes not enough for
the followers to understand what the mail is about.
Additionally, "Re:" does not make sense when starting a conversation.
This commit gives better default subject
for event registrations and allows thread models
to override the default subject of messages.
This also removes "Re:" from default mail subjects.
Task-2833215
closesodoo/odoo#95817
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps:
- Install knowledge on a fresh db
- Install and set fr_BE language
- Open knowldge
- Traceback
The traceback occurs because `emoji_registry.js` fails to load `emoji_data.js`
because of some translated string that contains non-escaped characters for JSON
opw-3110823
closesodoo/odoo#109086
X-original-commit: 455b335ae773ae4c8f5197c2a6f517947e6a7009
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, typing an emoji source in composer like
emoticon `:)`, it may not substitute to the corresponding emoji.
This happens because the emoji substitution requires loading
emoji data. It was only loaded when opening the emoji picker.
This commit fixes the issue by lazy loading emoji data when
focusing the composer.
closesodoo/odoo#109035
X-original-commit: 066e8029c0d66974c59bfe9e430affb4bf0604b9
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
request.geoip is no more a dictionnary cached in the session. It is now
a full blown object with lazy and smart geolocalisation capabilities.
Among other things, the previous dictionnary API is now deprecated. The
changes are:
* `request.geoip['country_name']` -> `request.geoip.country_name`
* `request.geoip['country_code']` -> `request.geoip.country_code`
* `request.geoip['city']` -> `request.geoip.city.name`
* `request.geoip['latitude']` -> `request.geoip.location.latitude`
* `request.geoip['longitude']` -> `request.geoip.location.longitude`
* `request.geoip['region']` -> `(request.geoip.subdivisions[0].iso_code if request.geoip.subdivisions else None)`
* `request.geoip['time_zone']` -> `request.geoip.location.time_zone`
It is safe to access all the attributes. Doing `request.geoip.city.name`
when the geolocalization failed (missing db, invalid address, ...)
evaluates to None. It does not raise an AttributeError.
Task: 2848206
Part-of: odoo/odoo#91337
Before this commit, processing of pinned channels during
init_messaging was slow due to sorting them in sidebar
of discuss.
This commit improves the sort so that we do a binary insertion
on add rather than push + quick-sort.
Before what took 2.2 seconds now takes around 0.6 seconds.
closesodoo/odoo#108839
X-original-commit: dd4c3c0a8e38147065980cf2c431b056a5253255
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since #107916, the ActivityModel did not include
`["activity_ids", "!=", false]` in its domain, causing incoherence in
some views and resulting in crashes.
To reproduce the issue:
- In the runbot, navigate to Website -> eCommerce -> Product.
- Switch to the activity view.
- Remove the Published filter.
- The view crashes due to an incoherence between the data records
in the `web_search_read` and the `get_activity_data` calls.
This commit resolves the issue by correctly setting the domain.
closesodoo/odoo#108807
Signed-off-by: Luca Vitali <luvi@odoo.com>
*: project, web
This commit converts the Activity view to the current framework shared by
other views. Instead of extending Kanban view/elements, the Activity view
has been implemented by its own.
The project customization of the view has also been converted, as legacy
files have been removed.
Some tests have been adapted since some classnames might differ from the old
implementation, resulting to failing tests. But the overall testing cases
have been conserved.
closesodoo/odoo#107916
Related: odoo/enterprise#35177
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Florent Dardenne <dafl@odoo.com>
The field `notified_partner_ids` has type Many2many with relation table
`mail_message_res_partner_needaction_rel` [1] which is a regular Odoo model
`mail.notification` with some extra fields. One of those fields is required:
`notification_type`.
On copying `mail.message` record, ORM copies Many2many fields directly without
using `default_get` method for `mail.notification` model. Particularly,
`notification_type` get null value and we get an error.
STEPS
1. Create Server Action for `mail.message` model:
```py
for message in (records or record):
message.copy({
"subject": message.subject + "(SA copied)",
})
```
2. Add contextual action
3. Open `mail.message` which has non-empty value on
`notified_partner_ids` (*Partners with Need Action*)
4. Run the Server action via Action menu.
PROBLEM
```
ValueError: <class 'psycopg2.errors.NotNullViolation'>: "null value in column
"notification_type" of relation "mail_notification" violates not-null constraint
DETAIL: Failing row contains (11, 210, null, 3, null, null, null, null, null,
null, null, null, null).
```
SOLUTION
Fix it by adding `copy=False`, because we don't want to copy those values
anyway (confirmed by TDE).
[1]: The relation table is renamed to `mail_notificaiton` in v15+
opw-3069556
closesodoo/odoo#108599
X-original-commit: d68b0f7d6b8f973ddaafdd7526d4f753a1b6abd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
PURPOSE:
When the push to talk key is the "space" we show an "empty string",
which is very confusing and not very clear.
SPECIFICATION:
We display `Space` string instead of empty space.
Task-2794733
closesodoo/odoo#108573
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose is to cleanup and add some details in some tests, notably about
default values when using message_post wrappers with either a view or
a template.
Tests with void recordsets are also added to check their current behavior
and try to keep it consistent when cleaning code in a near future.
Add a missing mute logger.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#108320
Kanban and form archs aren't owl templates. Kanban archs define
a (historically) qweb template ("kanban-box") which is html + some
directives (e.g. t-esc, t-foreach...) and extra tags (field, widget).
Form view archs are html + some extra tags (e.g. group, notebook,
field, widget...).
With the conversion of those views to owl, a door was left open:
one *could* use owl directives (for instance, t-on-click) in archs.
However, we don't want people to do that, as it would tie the archs
in database with js implementation details, which will then limit
the evolution of the js framework.
This commit adds warning when such forbidden directives are detected.
In master, we'll raise errors.
Part-of: odoo/odoo#108221
The tests consist in sending a mail related to a record to a customer and
checking that the record can be viewed through the embedded link:
- either in the backend if the user is connected and has the right to
- or in the portal otherwise
It also test that if the embedded link is tampered, the access is forbidden.
Task-2797311
closesodoo/odoo#105405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour
Start odoo without -d and with a --dbfilter that allows multiple
databases. Via JSON-RPC access the /web/session/authenticate route
providing a non-filtered database and valid credentials. Traceback,
`request.env` is None.
Since httpocalypse the initialization of the ORM (cursor, registry,
environment) is greedy. It means that the connection to the database is
established very early during the request routing or skip altogether in
case no dbname was known at that time. This contrast with prepocalypse
where the various ORM thingies were lazily setup the first time they
were accessed.
This changement has an important implication regarding authentication.
In prepocalypse, thanks to the lazy approache, a cursor/registry/env
would be setup on the database you just login upon using the
`request.env` for the first time. This was very nice in this regard but
had other problems.
Since httpocalypse such operation is no more possible. Devs must
initialize and use their own cursor/registry/env in case they
authenticate on another database than the one `request.cr` is (maybe)
connected to.
The `/web/session/authenticate` controller is an example of such case.
It crates its own cr/registry/environment after authentication. The
problem the controller uses `ir.http.session_info` and that not all
overrides were updated to use `self.env` (=the env created in the web
controller) instead of `request.env` (=the missing env of the request).
closesodoo/odoo#108063
X-original-commit: 7b9bd9d37731fae724dc5d91da656dab70aa9ad4
Related: odoo/enterprise#35012
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit:
There is no debug icon in Discuss Public Page to show whether debug mode
is on or not.
After this commit:
Added a debug icon which will be visible when debug mode is on.
Task-2664824
closesodoo/odoo#97178
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
Emoji data are all in English. Unable to use in other languages.
After this commit:
Emoji names and keywords are translatable for search and display purposes.
Emoji category names are translateable for display.
Task-3043336
closesodoo/odoo#107941
X-original-commit: ee5e0a201fb1980c1745692d366fd8539815773e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In some case, we want that chatter takes the all space
available.
Steps to reproduce:
- Go to Email Marketing
- Click on any record
- Go to the Chat tab
closesodoo/odoo#107928
X-original-commit: cbbbc23800e2a00aab9af45087b5d3f7698823d8
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before [1], the bus was started lazily: either as a consequence of
the addition of a channel to listen to or by manually calling the
`startPolling` method.
Before this commit, the websocket would have been started as soon as
the bus service starts which degrades performances.
This PR fixes the issue by re-introducing the same mechanism as before
that is by starting the websocket either by calling manually the `start`
method of the bus service or automatically when adding a channel.
[1]: odoo#75510
closesodoo/odoo#107878
X-original-commit: 5d7deacf54f37f0938b92a3c45c9f1d1325d1a9f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
Some mail clients set a wrong content-type for PDF attachments, they
set `binary/octet-stream` which doesn't exist[^1]. Odoo would crash
with a traceback in case it tried to extract the content of such
malformed attachment because Python doesn't know how to decode such
content-types.
Looking at the actual content of the emails we received, we would had
expected the content-type to be `application/octet-stream` instead. It
is fair to assume that the mail client software is buggy or poorly
configured and that it assumes that `application/octet-stream` and
`binary/octet-stream` represent the same thing.
Following Postel's Law[^2], it is better to still handle those malformed
emails, assuming the content-type is `application/octet-stream`.
opw-3030113
opw-2716507
[^1]: https://www.rfc-editor.org/rfc/rfc2046#section-3
[^2]: https://en.wikipedia.org/wiki/Robustness_principleclosesodoo/odoo#107317
X-original-commit: e6169325b968711a0a28444818b34aa1932a6bae
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Warn user and alias responsible when model creation fails on incoming
message due to alias mis-configuration.
Alias custom default values that references archived or deleted records can
prevent the record to be created when receiving an email.
Unfortunately, correcting values on the fly has too many downsides:
- as the value cannot come from nowhere, we would probably end up with
corrupted record like a task without a project
- as errors are silent, lots of suboptimal record could be created before it
is corrected
- as the code would have to deal with different kind of updates, it would be
heavily depend on the framework meaning additional maintenance cost
- the attempt made had also a performance cost by using savepoint which we
want to avoid
For all those reasons, we have decided to warm the user rather than trying to
solve the problem automatically.
The users are warned:
- through a bounce email sent to the sender and alias responsible
- in the alias interface through an alias status present in the list and the
form view
Technical notes:
- They are multiple kind of errors: error in the message (ex.: user not
authorized to send to a specific alias), error in the alias (ex.: dangling
reference in alias_defaults), other error (ex: technical error like a
service unavailable when receiving the message). Here, we want only to detect
alias error and skip other errors. So rather than doing a big try except around
_message_route_process, we have selected the spot where we should detect alias
error:
-- in _alias_get_error_message where we distinct a message error from an alias
error
-- in inside _message_route_process where record are created using
alias_defaults (custom values with reference to record that might have been
deleted since the alias creation)
- In test, we call mail.thread message_process with sudo as it is the case in
real use case (processed when fetching mail). It is needed as in some test
alias status are modified.
Task-2675209
closesodoo/odoo#101019
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = crm, mail, survey, test_event_full, website_event
To increase readability and performance, use f-strings where appropriate
(multiple concatenation +- formatting).
Note: Also removing unnecessary string concatenation with `%` for `(i)like`
in domains definitions.
Task-2977548
See odoo/enterprise#31156closesodoo/odoo#99811
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Before this commit, the rendering context of kanban and form views
was the instance of the KanbanRecord and FormRenderer, respectively.
As a consequence, a lot of implementation details (e.g. "props",
"__owl__", any Class method...) were available. This wasn't what
we want.
The door being left open, people went through, and in 16.0, several
kanban and form archs contain(ed) such use of undesired "features".
With this commit, we restrict the rendering context of those two
views. In kanban views, it contains what has been historically
available (e.g. "record", "widget", "kanban_color"...). In form
views, nothing is available since the only dynamic part in those
archs is the attrs, which aren't evaluated by the rendering engine.
To do that, we use `t-call-context` owl directive. When using this
directive, the rendering context is the given one, + `this`. So the
component instance is still available, but through the `this`
keyword. We can thus use it in our compilers, to make them work as
before. Note that `this` can never be used in an arch directly.
Task 3085357
closesodoo/odoo#106045
Related: odoo/enterprise#34493
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
CONTEXT:
emoji_char_field and emoji_text_field
previously used the emoji_dropdown component
along with some utility functions to display
a very limited number of emojis.
As discuss now has a feature-full emoji picker
we aim to take advantage of it by bootstrapping
the picker from the existing components,
using a new javascript model for the
insert/update logic
AFTER THE CHANGE:
Users should be able to select the same emojis
they can use in the discuss chat in all fields
that previously featured an emoji picker.
Such as the livechat bot responses,
social posts, mailing subjects and
the sms message composer.
RELATED CHANGES:
Some tests are updated to use the pyEnv testing
'framework', as we now need to have access to
the messaging service to test these fields.
emoji_mixin is modified to match any emoji
character. The mixin is consolidated into
a single function is actually called anymore.
The text to emoji dict from emojis.js is removed
as it is no longer relevant where it was used.
The fields that used the emoji_mixin will no longer
trigger onChange on inserting an emoji.
However both the input and keydown event are fired
to allow fields using onchange_on_keydown
to trigger the onchange.
The emoji button was turned into an actual button
replacing the original span used in these fields.
This required a different approach to styling as
buttons inherently behave differently than spans.
The button is now moved using an empty div next
to the input and absolute positioning.
Most of the code used for char and text emoji
fields is consolidated into emojis_field_common.
task-3035021
closesodoo/odoo#104799
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, when resizing window so that chatter swap
position, the text content of message disappeared.
This happens because OWL re-render the message view as completely
different DOM elements, while modeling in discuss code kept
identity of the MessageView. As a result, the message text content
was unchanged therefore it was not updated in the DOM, thus staying
blank.
This commit fixes the issue by enforcing setting the message text
content in DOM whenever the value is empty in DOM but the message
has logically some text content.
closesodoo/odoo#106978
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this PR, posting a message containing an attachment with a long
name in the chatter would result in the chatter overflowing the main
window. This is due to the fact that flex items cannot be smaller than
their content.
This PR fixes the issue by adding the `overflow-auto` class to the
chatter container in order to override the default `min-width: auto`
of flex items thus allowing them to be smaller.
closesodoo/odoo#106927
X-original-commit: 73fb78e75b6126586385ea7621b6d71fae715305
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Thibault Delavallée