Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In future commit, we plan to use it notably to remove custom code in account
journal model and make it more standard. Using it in more models will be done
later, but it is a candidate to cleanup unused aliases related to discuss
channel model.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Linking some bug fixes about that subject (notably due to 'account.journal'
model that uses aliases without going through the 'mail.alias.mixin', hence
allowing to see differences between sanitize and constraint):
* odoo/odoo@33bd1a951a : non ascii aliases when installing COA and generating
journals automatic email aliases;
* odoo/odoo@e08ee893d1 : left-part should not begin or end with dots as well
as containing dots sequence;
* odoo/odoo@f1215389e8 : prevent international char in aliases;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Currently ICP parameter clean and check is done at create / write override.
However it should be done at ``set_param`` level to avoid messing with the
specific behavior of ir.config_parameter with falsy values.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
In addition to checking conflicts with existing aliases, we have to check
that given name list also contains only unique names. Otherwise creating
in batch with duplicates raises the SQL unicity constraint instead of the
expected UserError.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
Aliases should be unique except when they are empty. Indeed each valid email
address should be unique, as it targets a specific behavior e.g. creating
a task in a project or a ticket in an helpdesk team.
For that purpose an SQL constraint exists that enforces the unicity. Null
values in DB are not considered as being the same, meaning we may have
multiples aliases with Null values in DB.
When voiding the alias we may end up with a void string, which is not the
same as giving False to the ORM in term of DB storage. Multiple void strings
break the unicity constraint where multiple False strings do not.
In this commit we therefore enforce that void alias names are forced to
False to avoid any constraint issue. Sanitize method is now independent
from the check method, to avoid calling multiple times the sanitization
as it is often used for other checks.
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
CODE LINT / CLEANUP
Reorder fields definition per main usage: definition, owner, parent, gateway
configuration. Order computed fields accordingly.
Rename some methods (notably constrains), move an inner sanitize method as a
model method to allow its future usage.
Perfom a quick linting of code, simplify some lines.
TESTS
Add some tests related to alias management, notably copy, and multi-company
models using aliases. Those will help when moving to multi-company support
for aliases.
Add tests for current sanitation / cleaning of alias names and alias domain
parameters, to be more precise about accepted / unallowed characters, support
of unicode, ...
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
This PR adds the `add_guest_to_context` decorator in order to provide a generic
way to extract the guest from a request. It will be used to unified guest
extraction from cookie/param based on its provenance (external livechat/public
page).
This is better than the `pre_dispatch` method since it can be applied to
specific routes instead of adding this logic to every request.
part of task-3332628
closesodoo/odoo#130052
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
With this commit, users can send voice messages in channels and chat.
There's a new button in composer to record audio from the microphone,
up to 1 minute clip duration. This adds a voice attachment with its
dedicated voice player that shows waveforms and allows playback.
To ensure compatibility in all supported browsers, we choose to
encode voice recording with `audio/mp3` thanks to lib `lamejs`.
Task-3240168
closesodoo/odoo#117036
Related: odoo/enterprise#45482
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
`_get_starred_counter` method is obsolete now.
So, there is no meaning in keeping it anymore.
It's usecase has been removed by this PR
https://github.com/odoo/odoo/pull/83777closesodoo/odoo#131299
X-original-commit: cbf590bfa0999e99064e1a2bb337c8e63f00dd8c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Rahul Prajapati (rapr) <rapr@odoo.com>
Since 69f911d994 it was no longer possible to post an HTML
message via a script. Allow to do it but log a warning to discourage
doing so. Markup object should still be the propoer way to do it.
closesodoo/odoo#130883
X-original-commit: a890db49935813d0794765492c057404592e5977
Related: odoo/documentation#5273
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
'field_groups' computation is missing their triggers. As field is not stored
it is not that annoying, but better be explicit.
Task-3345979 (Mail: Simplify tracking model)
closesodoo/odoo#130791
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
[1] introduces an issue when a response is sent to an aliased email.
In that case, it is intended that the message should be created
by the owner of the alias by [2]
Which breaks the assumption of made in the first commit, as the message
is being passively processed by fetchmail.
This causes the owner of the alias to never be notified on reponses
in cases where the message could be an alias update.
i.e. on any model where the alias applies.
Because the responses are assumed to have been authored by the owner.
As we do not actually care who creates the message records
and deciding the alias owner 'created the message' does not
actually make sense.
We make sure messages are created by odoobot even
if the message was sent to an alias address.
[1]: c676ed3ea906e99d27a6116cd77218c5ec95b416
[2]: af80c68ae5
task-3383275
X-original-commit: 96fe37d37c94c3d6f4642bd6c28d13fcd87075b7
Part-of: odoo/odoo#130798
Before this change aliases were assigned to the user creating them
The purpose was originally to reduce the number of records created by
odoobot however this leads to unexpected
behavior for the users who just wanted to create an alias without fuss
We make remove the default user such that any automated record
modification/creation will be applied by root instead of some
arbitrary user.
task-3383275
X-original-commit: 3edf18168b92545fc29e078a155494f2781adff6
Part-of: odoo/odoo#130798
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
In addition to finding the customer, sometimes we just want any partner on
a record, notably for VOIP. For that purpose we improve heuristic for
finding partner (fields or records). It introspects the model to find any
relational field towards res.partner. Note that as it is generic it does
not ensure the partner is a customer, just some partner.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Move 'mail' and 'phone_validation' helpers directly at model level, allowing
to rely on those methods in all models instead of only when inheriting from
'mail.thread' or 'mail.thread.phone'.
Those helpers are used to find primary email, phone numbers or customers in
flows involving sending emails or SMS. A default behavior exists that is
generally valid for most models. Method can then be overridden to implement
their own custom behavior.
Future commits will improve them and remove duplicated computation between
mail, phone_validation, mass_mailing and sms modules.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
The translations on Spanish (Mexico) are more active than on Spanish
Moreover, most other countries speaking a variant of Spanish are
located in Latin America and are closer to es_MX than es.
To solve this, when installing for instance es_AR, the translations
will be loaded in the following order:
1 es
2 es_MX
3 es_AR
In case a term is translated in both es and es_MX (and not es_AR), the
later will be used
closesodoo/odoo#121415
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This PR prepares the ground for the one introducing guests
for livechat visitors. Since our SameSite cookie policy
is Lax, the cookie won't be send on unsafe cross site
requests thus another mechanism will be introduced to
retrieve the guest.
This PR abstracts the way the guest is retrieved in order
to ease this transition as much as possible by overriding
the `ir_http._pre_dispatch` method in order to inject the
guest in the context if any.
part of task-3332628
closesodoo/odoo#129039
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit: Body content is the same as tmeplate
After: Body content is the same as the template
*: hr_recruitement, sale, survey, website_slides
closesodoo/odoo#128953
X-original-commit: 388e340a52fd5775c1702f8952a1e959fa5cef48
Related: odoo/enterprise#44309
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit implements a mixin, `MailTrackingDurationMixin`, that can be added
to a model with a `many2one` field. It computes the time a record spends in each
value the many2one field takes and stores it in a JSON field
(`duration_tracking`).
The primary use is with the StatusBarDurationField
(`widget='statusbar_duration'`), to compute and display the time a record has
spent in each stage in the form view statusbar.
To specify on what field the computation has to be done, the model that inherits
from this mixin has to specify `_track_duration_field`. (e.g.
_track_duration_field = 'stage_id')
Computation is based on `mail.tracking.value` messages, so tracking has to be
activated for that field.
Task-3032773
Part-of: odoo/odoo#108554
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
Before this commit, the data of all followers of a chatter were
fetched whenever `mail/thread/data` was called. This route is
called when loading the chatter for the first time, and whenever
the chatter must be reloaded.
When there are at most dozens of followers, it's not a big deal.
However, with thousand of followers, the route `mail/thread/data`
may become quite long, which made chatter barely usable with a
long loading.
This commit fixes the issue by showing only 100 followers at once
when opening the follower menu. When scrolling down the list,
it loads data of more followers.
Task-3293718
closesodoo/odoo#127966
Signed-off-by: Didier Debondt (did) <did@odoo.com>
A serialization error can happen when chatting with another
user from the company. To reproduce:
- Log into Odoo as User A
- Open another Odoo tab in the same window as User A
- In private mode log into Odoo as User B
- Send a message via chat from User B to User A.
A concurrent update happens in channel_fetched method when writing
on mail_channel_partner.fetched_message_id.
To fix that, update the field
through raw SQL using FOR NO KEY UPDATE SKIP LOCKED in select subquery.
This skips the row should it be already locked, which is fine
as we only need to first transaction in the queue to complete.
opw-3164584
closesodoo/odoo#128464
X-original-commit: 5e95bfc2a9e68ea7643ea436968dcad19fdeeff9
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Steps to reproduce:
- Install CRM and Helpdesk modules (for test purposes)
- Set a custom alias domain (e.g. "mydomain.com")
- Go to CRM > Configuration > Sales Teams
- Check that a team has en email Alias (e.g. "info@mydomain.com")
- Go to Helpdesk > Configuration > Helpdesk Teams
- Check that a team has en email Alias (e.g. "support@mydomain.com")
- Email your instance with the following `to` value:
info@mydomain.com, support@test.com
(notice second email does not match the DB alias domain)
- Go to CRM : A task has been created
- Go to Helpdesk : A ticket has been created
Issue:
The ticket in Helpdesk should not have been created.
Cause:
The message_route method does not check the domain of the email
address before creating the routes.
Solution:
If `mail.catchall.domain.allowed` system parameter is set, filter to
only keep the emails address that match the allowed domains (including
domain set in `mail.catchall.domain` system parameter).
The value of `mail.catchall.domain.allowed` system parameter should
be a comma separated list of domains. e.g. `example.com,example.org`
opw-3150972
closesodoo/odoo#128346
X-original-commit: 5b73428104789433fd65431f7631a2e9eb863b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Settings allow to change colors used in emails (primary and secondary colors).
Those are used for headers and buttons. They are currently shared with colors
used for base documents and reports layout: changing email colors change
documents colors, which is not expected nor clearly indicated.
SPECIFICATIONS
Split configuration: colors used in documents may differ from colors used in
emails. Duplicate color fields (primary and secondary). To ease setup when
updating documents colors, update mail colors accordingly. Inverse is not
true as we consider documents being the main configuration, and emails a
more fine-grain configuration.
Task-3346388
Part-of: odoo/odoo#123678
Backport of `_get_guest_from_context`.
Prevent crash when unexpected (not recordset) values are in the context.
Ensure the mere existence of a value (example integer) does not lead to
executing flows where an actual guest is expected.
task-2819597
closesodoo/odoo#127831
X-original-commit: 3d1890e88b99f059377d8b227b56d77798157397
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when posting a message with 3 attachments
`A B C`, the message displayed attachments in order `C B A`.
This happens because message format list attachments in order
of `message.attachment_ids`, which has no specific order.
This commit fixes the issue by ordering attachments in
`message_format` from the oldest to most recent, so that displayed
order in message matches the one from composer, which itself
matches the order of creation of attachments.
closesodoo/odoo#127830
X-original-commit: 53508effa66bca79aa872412333ca8578ca9b813
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, only logged notes could be edited in chatter.
With this commit, messages sent with "Send message" are also
editable.
Task-3380465
closesodoo/odoo#125939
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/120002
Commit above made a a structural change of code that
should not have changed the functional behaviour of
chatter.
In consideration of reducing query count footprint,
it replaced a `browse().exists()` by `search()`, as
`exists()` always perform a query whereas `search()`
may rely on cache and skip a query.
However, `search()` filters archived records, so this
change unintentionally removed the possibility to send
messages on archived chatter. Also the performance of
`search()` and `browse().exists()` are pretty much the
same, so the premise of changing it to `search()` seems
wrong.
This commit reverts this part so that this is the exact
same behaviour as before.
closesodoo/odoo#127518
X-original-commit: 43227ad2eaaeba3f6e3e6fae8b84728e0c33c59a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
* = im_livechat, test_discuss_full
According to stats from our production database, this query is 10 times
faster than the one generated by the ORM by using a `left join` rather
than `id in`.
closesodoo/odoo#125961
Related: odoo/enterprise#43635
Signed-off-by: Didier Debondt (did) <did@odoo.com>
This commit adds a GIF picker in discuss
app. GIF feature makes use of Tenor GIF API [1].
To enable GIF picker in discuss, you must provide
a Tenor GIF API key in the General Settings.
Then the GIF picker is visible in all channels
(chat window and discuss app), next to the emoji picker
button.
[1] https://tenor.com/gifapi/documentation
task-2365705
closesodoo/odoo#116060
Related: odoo/enterprise#41959
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Before this commit, when editing a message, it was not possible
to add new mentions.
This commit adds the support to add new mentions when editing the
message.
Note that mentions added from editing message won't notify them:
it's only at creation of message that mentioned users are notified.
task-3329714
closesodoo/odoo#126888
X-original-commit: 1fe935d273142064784b9ecff2fff1c34e91064f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Before this commit, when opening self-chat and trying to add users,
self id was duplicated with the chat partner id, leading to a crash.
This commit fixes the issue by removing duplicates in inviting users,
so that there's no longer a crash when inviting users in self-chat.
task-3381895
closesodoo/odoo#126605
X-original-commit: d101a82b97989d5c60c1b6dfbc5fa2143680bd3c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This PR make add a last used date to the canned responses
in order to know whether they are still usefull or not.
part of task-3332872
closesodoo/odoo#125909
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.
In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.
The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.
NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt
opw-3144519
closesodoo/odoo#126474
X-original-commit: e3a5b46c7b4f5030e165a6d943ec2275aea5d583
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
This PR fixes some issues present in the livechat demo data:
- anonymous name should be given to the channel, and should be the
name of the visitor not the one of the channel.
- odoobot should not be a member of the channel (done by default
when creating a channel but making those channels that are supposed
to be one-to-one channels a group channel)
At the same time, this PR fixes an issue with the thread model that
contained clear commands instead of null value.
part of task-3332872
closesodoo/odoo#126219
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Improve the _get_link_preview_from_url method to:
- Only load necessary data (only the <head> instead of
the whole page).
- Handle optional request session.
- Handle all image mimetypes.
- Add a fallback on the <title> tag when no og:title have
been found.
Moving the method out of the model to facilitate
its use as a tool.
Task-3234864
Part-of: odoo/odoo#122087
This commit moves and adapt the res.users.settings model from mail to base and
and allows to access and modify its content with web's user service.
This allows to access user settings without needing the mail module.
closesodoo/odoo#116005
Related: odoo/enterprise#38360
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, when deleting an attachment from composer,
an undefined message was inserted in the store.
closesodoo/odoo#125313
X-original-commit: ec814f14222509caa27d627a193e6eaebe9bbf60
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, a new unread message could contribute to unread
counter of conversation twice.
Steps to reproduce:
1. Log in as Demo and start a conversation with Mitchell Admin
2. Log in as Admin: if this is the first message in the conversation,
counter is correct and shows (1)
3. Log out as Admin
4. Send another message to Admin
5. Log in as Admin and notice that the counter is doubled
6. If the conversation was still open, counter is correct!
This happens because some notification are pending dispatch before
fetching messaging state initially. The counter at init_messaging
fetch takes into account the notification. However, when handling
the message notifcation, it's wrongly considered as a new
notification, thus incrementing the counter when it shouldn't.
This commit fixes the issue by fetching the last bus notification
when fetching init_messaging. Doing so allow to determine whether
a notification is newer or older than init_messaging state.
This helps deciding whether the counter should be incremented or not.
Task-3357960
closesodoo/odoo#124767
X-original-commit: 081ab772dece86f1b5a5d4b3f6227b4b311d9206
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
In [1] the order by `id ASC` has been removed from the
`_message_fetch` method. This is wrong since we want
to load the messages coming DIRECTLY after the given
id thus, this order is required.
In order to solve this issue, this commit ensures the
order of the messages returned by the `_message_fetch`
method is always in descending order as it was done
implicitly before [2].
[1]: https://github.com/odoo/odoo/pull/123664
[2]: https://github.com/odoo/odoo/pull/116666
task-3349175
closesodoo/odoo#124169
X-original-commit: 074a5fea5a7f08c7018620cb9b2b956b3a871344
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Didier Debondt (did) <did@odoo.com>
Prior to this fix, elements with background images were converted to
images via the html2canvas library. This made them work in Outlook at
the cost of several tradeoffs:
- the process was slow and asynchronous
- there could be no interactivity (links, buttons, etc.) in the
converted element
- responsive behavior was wonky: if only a slice of the image was shown
when it was converted (due to background-size cover behavior), the
rest was lost so if more width was needed in mobile, we would be
zooming on that slice, making it sometimes irrelevant and pixelated
This replaces all that with a conversion to VML, which is a vector
format supported by Outlook. This conversion is done only for Outlook,
which means that all other clients are getting the original background
element again.
There is a way to keep the background-size cover behavior in VML, using
the "aspect" attribute with value "atleast" but this only works on
v-fill elements and sadly putting the image on a v-fill element bugs in
Windows Mail (which is the default mail client on Windows 10 and 11) and
this client can't be singled out of mso conditionals. To get around this
issue, since this is only for desktop clients, we assume the width of
the screen to be large and mimick the cover behavior by cropping the
image to the target size. This allows us to put the image on the v-image
element and have proper rendering in Outlook and Windows Mail on
desktop.
Note:
When retrieving the image by URL in Python in order to crop it, we need
to ensure we have an absolute path. This is done - perhaps seemingly
naively - by checking if the URL contains '//'. Here's the reasoning
behind that choice. To check if a URL is absolute, we could use
`urllib.parse.urlparse` and check if it has a scheme but that would lead
to `www.odoo.com/path` being considered relative (and thus we'd add a
host to the URL even though there's already one). Instead, we could
check it it has a netloc but that would lead to the same issue since the
documentation of `urlparse` says:
> Following the syntax specifications in
[RFC 1808](https://datatracker.ietf.org/doc/html/rfc1808.html), urlparse
recognizes a netloc only if it is properly introduced by ‘//’.
Still, it would be more technically correct since `//some/path` would be
considered absolute (which it should be since it resolves to
`<current_scheme>//some/path`).
Base on that documentation, it seems that simply checking if the URL
contains '//' is pretty much equivalent to checking if it has a scheme,
with the double advantage that it's simpler and that it works for
`//some/path` as well. However, note that it doesn't solve the issue of
`www.odoo.com/path`.
In summary, here are the results with the current method:
```
http://www.odoo.com/path -> http://www.google.com/path // OK
some/path -> http://localhost:8069/some/path // OK
/some/path -> http://localhost:8069/some/path // OK
//some/path -> //some/path // OK
www.odoo.com/path -> http://localhost:8069/www.google.com/path // WRONG
```
X-original-commit: 9561ba31917024825705c876442139405e7a7957
Part-of: odoo/odoo#124465
X2many fields tracking was not supported in the implementation of
`mail` module:
* not needed in the past
* the logic was not hooked in the same place before. Now that it is
managed pre-commit, x2many values don't have to be handled as commands,
but can be compared as records.
* ...
The support was added for two specific models in specific modules, but
it's a good opportunity to clean that and to support it directly in `mail`.
Task-3316528
Part-of: odoo/odoo#121244
Thibault Delavallée