Before this PR cache control header for avatar was set to no-cache which is not
the right value.
This PR mark the avatar routes response as immutable when a unique string is
present. We also use the partner write_date as unique string when possible.
task-3551636
closesodoo/odoo#141326
X-original-commit: 3de4f1f1225229cbdb0512df5790ce491f04ea7e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To limit performance impact of the systray, we fetch by default only the last
1000 activities. That value can be configured with mail.activity.systray.limit
config parameter. Note that this can also improve a bit the readability of the
other activities view (for the standard activity view a pager is already
present).
Task-3562098
Part-of: odoo/odoo#139917
When scheduling plans on employees, activities may be assigned to people who
don't have access to the record, but they still need to mark them as done. And
as marking as done (action_done on mail_activity) triggers a message post on
the related record, that action cannot be executed by a user without access to
the record.
We change that here to allow user having delete/archive right on the activity,
to be able as well to mark it as done (as the activity is archived/deleted at
the end of the method _action_done, the user must at least have the right to do
that to be able to mark as done the activity).
Task-3562098
Part-of: odoo/odoo#139917
When scheduling plans on employees, activities may be assigned to people who
don't have access to the record. It was managed locally in HR through a dummy
model aggregating activities. However, it was removed and we replace it here by
a generic solution that adds an entry in the systray: "Other activities". When
clicking on that entry, it displays a list view of the activities assigned to
the user for which he has no access to the related record. Those activities
were not visible to the user before.
Technical note: to allow displaying such records, we have modified the custom
acl defined in python to allow users to read activities assigned to them even
if they don't have access to the related record.
Task-3562098
Part-of: odoo/odoo#139917
Before this commit, we used to rely on duplicates of streams and the
presence of streams to know if a session was streaming.
This commit changes this and make it so that we now use streaming
activity flags instead.
This is a prerequisite for https://github.com/odoo/odoo/pull/132153 as,
similarly to webRTC "unified plan", the SFU keeps the same streams for
the whole lifespan of a connection.
closesodoo/odoo#140053
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
We do the following improvement:
- some wording changes
- the activity templates can be edited directly in the list view instead of in
a popup except in hr because sub module add too many field to be edited in
directly in the list view.
- when scheduling a plan, the due date of the created activities are computed
as the plan_date_deadline + activity type delay and if the plan_date_deadline
is not specified, as today + activity type delay.
- there were 2 res_model fields in the mail_activity_plan_view_form that was
causing a selection box to appears on many form where the model shouldn't be
selectable. We remove one of them here.
Task-3558929
Part-of: odoo/odoo#138998
Before this commit:
Channel was not getting unpinned after being deleted
After this commit:
- Channel gets unpinned for all the channel members after being deleted
- If a user leaves channel/group then all of the messages of that channel/group
are removed from the user's history/starred/inbox channel.
Task-2814440
closesodoo/odoo#139972
X-original-commit: 4767d6001d15628768388bcac98c04ab185040c8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Make partner_id and guest_id properly exclusive.
Allow creating a channel member from its form view.
closesodoo/odoo#140272
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
It is sometimes desirable to completely remove a field
from the automated tracking message
when setting a custom message that already covers the change being made.
Add a filtering method on threads to allow models to selectively
hide tracking values from emails and messages.
task-2974500
closesodoo/odoo#109606
Related: odoo/enterprise#31795
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
---------
Previously, when receiving an email with several attachments, we created
1 invoice that contained all the attachments.
Objective
---------
We want to create several invoices depending on the attachments received.
No invoice should have more than one PDF document.
No invoice should have more than one XML document.
Other attachments should be placed in seperate invoices (except for the
first invoice that can contain 2 attachments: ex. image and PDF).
Solution
---------
Update the _extend_with_attachments to behave like such.
task-3526248
closesodoo/odoo#140196
Related: odoo/enterprise#49779
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Currently both incoming and outgoing emails are using the same 'email'
message_type. However both flows are not linked in any way.
Purpose of 'message_type' is to distinguish who generated the message.
In this case incoming emails are generated by the mailgateway while outgoing
emails are generated by mailins e.g. using the composer in mailing mode.
We now distinguish outgoing emails from incoming emails by using a specific
type for outgoing emails. Addons are updated accordingly.
Default 'message_type' value when removing sms/snailmail/whatsapp is now
'comment' instead of 'email', as default value of messages should be
comment as discuss is the main source of messages.
Task-3285720
closesodoo/odoo#139814
Related: odoo/enterprise#49597
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1], guest is added to the channel immediately instead of
waiting for the guest name to be set. Since the guest is not in
the context when posting je "join" message, the author of the
message is the public user instead of the guest. This results in
an incorrect message ("public user joined the channel") since the
frontend relies on the author to set the name. This commit fixes
the issue by adding the guest to the context.
Steps to reproduce:
- Go to a channel
- Copy the invitation link
- Join the channel with this link
- The message is incorrect
[1]: https://github.com/odoo/odoo/pull/138330closesodoo/odoo#139892
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Unwittingly broken by the removal of `__implements__` in
a6d601dc4e, these lints don't run
correctly with the old pylint, allowing new errors to creep in since.
closesodoo/odoo#139605
X-original-commit: 99cec73f585c8759142a707b06934d9c23aa5478
Related: odoo/enterprise#49473
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
So that `Message.insert()` in JS becomes trivial, as it doesn't have
to infer the author of message to current user.
closesodoo/odoo#139501
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Commit b05e7e4da0 rightfully removed the _compute_name dependency on
context keys (a bad idea for stored computed fields), but this change
could lead to UX frustrations (Server Action names getting reset all the
time despite what the user may have used as a name before) and UX issues
(e.g. triggering a recompute by accident at module removal that could
reset all 'code' action names to 'Execute Code').
This commit simply removes the automated naming feature from the base
module and moves the logic to the base_automation module - and only
computes automated names based on the link with an automation rule or
not (so 'standalone' server actions need a name given by the user at all
times).
Task-3450200
Part-of: odoo/odoo#138804
- Slight reword of the 'type/state' field labels for server actions
- Re-ordering of 'type/state' values
- Form view changes
- Allow hiding model in display_name of ir.model.fields base on context
key (avoid technical details when they are not needed)
Task-3450200
Part-of: odoo/odoo#138804
Before this commit it is impossible to find the qweb error when you preview an email template.
closesodoo/odoo#139668
X-original-commit: 1f373de5f218a1f43015f4f80e60d1da0188d6b5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit introduces a new optional feature in the chatter.
Users can request translation from the Google Cloud Translation API.
Documentation: <https://cloud.google.com/translate/docs#docs>
Adding the key in settings will instantly enable the feature for all
users of the database and consumption is not measured nor limited
by Odoo as it is natively supported using the Google Cloud Console.
Translation values are stored in the database to reduce cost as
much as possible. Therefore, translation values are automatically
garbage collected every 2 weeks to prevent database pollution.
Task-3338165
closesodoo/odoo#126555
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
New fa-bell icon to manage notifications according to that channel only
Options:
Mute (+choose time period):
No longer see the unread status: the bold text disappears and the channel name fades out.
As if you are not a channel member anymore.
Receive messages but without sound + only need action counter (grayed).
Add a crossed-out bell icon next to the channel or user name to indicate that the channel is muted
All messages: all messages sound + need action counter
@Mentions: only mention sounds + need action counter
Nothing (Discord-like): No sound + need action counter
By default: all messages
task-3328665
closesodoo/odoo#136405
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are used in Odoo codebase there is no usage anymore
for the old config parameters. So long and thanks for all the fish !
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Update settings to configure your company's current alias domain instead
of the global 'alias.catchall.domain' configuration parameter. As domain
configuration is globally done per company, this is now a related on the
company. Advanced configuration and management can still be done manually
in settings.
Field 'external_email_server_default' triggering display of mail configuration
is moved to mail. It is defined in 'base_setup' but used only in mail hence
moving the field to be coherent.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Currently alias search is done only on 'alias_name' field. Now that alias
domains can be multiple we have to be able to search on complete alias
email definition e.g. when checking destination aliases of incoming emails
in mail gateway.
We add a new 'alias_full_name' field that is computed based on alias_name
and alias_domain_id.name. It is stored so that search is possible on it.
Allow to search on 'alias_full_name' from the 'mail.alias.mixin(.optional)'
by making 'alias_email' field searchable, based on 'alias_full_name'.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are multiple and can be linked to companies it is
easy to end up with configuration where an alias is using a domain of
CompanyA while the owner and/or target record belongs to CompanyB. We
want to avoid that situation and strengthen company separation.
When changing alias domain of an alias check that it is not used in another
company than the one define on
* the owner record (using owner fields like the 'project.project' for
'project.task' creating aliases);
* the target record (using update fields like the 'mail.group' for group
aliases that routes emails to a specific group);
If the new alias domain is linked to a company that is different from the
company of any related record, raise an error as it could lead to invalid
multi-company setup and record creation.
If the new alias domain is different from the company domain but is not
used in any company it is a valid configuration. It is just flexibility
offered by multi-domains aliases.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
As 'alias_domain' is now dynamic and not based on a configuration parameter
it makes sense to be able to change it when having several alias domain.
We now allow writing on 'alias_domain_id' in 'mail.alias.mixin(.optional)'.
Users may now change the alias domain of the alias coming with the mixin
when they have write access on the record.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add 'mail.alias.domain' information on alias model. Aliases do not use global
configuration parameters anymore. Instead they are linked to an alias domain
e.g. 'sales' linked to 'mycompany.com' alias domain: 'sales@mycompany.com'.
It is now considered as a different alias compared to 'sales@mycompany.in'
which has the same alias_name but a different alias domain.
Constraints and checks are added, as
* uniqueness of aliases is now checked inside a given domain;
* an alias name must not clash with its domain bounce or catchall;
* a combination of (alias_name, alias_domain_id) must be unique;
Crm multi-company environment is also updated to match the new alias domain
behavior.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from is also moved on this model, allowing an higher
level default from computation for mail servers when having knowledge of
alias domain environment. Filtering configuration based on default_from_filter
is kept as an ICP as it is mainly used for odoo-bin with smtp-host.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
Currently only base modeling and computation is done. Their usage is about to
be gradually added in mail stack.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
This may have an impact when trying to find an outgoing mail server based
on from and filter, as first match wins when checking matching filter on a
bunch of mail servers.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
* = bus, crm_livechat, hr, mail_bot, test_discuss_full, test_mail,
website_livechat
Now that livechat uses guest, we can write proper ACL for channel and
channel member to check if the current user/guest is a member.
This allows removing most sudo in code and to simplify search domains.
Remaining sudo in discuss folder have been reviewed and commented.
task-3394829
closesodoo/odoo#138330
Related: odoo/upgrade#5295
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Also impacts mass_mailing_sms, test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
A few adjustments are also included to update for IAP api v3.
Also, adapts and includes new tests.
Task-2560666
Part-of: odoo/odoo#133392
As a step to simplify model insert from python. All data are
formatted in a way to make data insert trivial in JS models.
closesodoo/odoo#138760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Name was hard to grasp what it means, when in practice it refers to
showing discuss failures in messaging menu. The "group" part just
refers to a failure being conceptually uniquely defined so that it
sometimes group notifications together as a single failure entry
in the messaging menu.
This rename will help simplifying insert flow with this model.
[REF] mail: slightly simplify Notification.insert()
Format `persona` so it can be immediately inserted in JS model.
[REF] mail: simply Notification/Failure.insert
[REF] mail: introduce computed fields on discuss models
Some models have no concept in server, so the formatted data require
specific handling to make some client-side specific models. This is
notably the case with `Failure` model, which is used to group
failure notifications per model for the specific showing in UI.
In order to simplify update so they consists to simply adding data
from server, these models should be inserted automatically depending
on changes from inserted data. Since these models come from
relational fields that must be computed outside of server data, we
add support to computed fields: such relational fields can have their
value automatically computed based on the state of the current
record.
[REF] mail: remove Record.atomically and Record.onChange
These were added to reactive seeing intermediate state in models,
which were caused by `RecordList.sort()`.
This commit removes them and adapt specifically `RecordList.sort()`
so intermediate states during sort is not exposed in the actual
value of the many field.
Part-of: odoo/odoo#138760
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* = calendar,test_discuss_full, test_mail, test_mail_full
Methods can be downgraded to channel_info when called by RPC.
This increases the simplicity to use these methods in python.
closesodoo/odoo#139341
Related: odoo/enterprise#49326
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To allow to search records having "done" activity (archived) assigned to
someone, we have modified the search method of the field activity_user_id (in
the activity mixin) so that it matches also responsible of archived activities.
This field is mainly used when coming from the systray to display user
activities including "done" ones but could be also used in custom filters.
We have also modified the default domain when fetching record for the activity
view so that it matches records having at least one activity, archived or not.
This prevents to load more records than necessary to display the activity view.
We also adapt the test accordingly.
Task-3300854
Part-of: odoo/odoo#138135
The system tray has been simplified:
- only one clickable area per activity group
- by default, a click on an activity group open the list view, except for some
model (ex.: journal entries, project, task, documents where the activity view
is opened). This can be defined per model using the _systray_view attribute on
the model.
- the clock icon providing access to the activity view has been removed. As it
is the only action, we also remove "actions" returned by systray_get_activities
in res_users.
- the KPIs are no longer clickable
The tests have been updated (for example, because we open the list view instead
of the kanban view) and one removed "activity menu widget: activity view icon"
as we only have one clickable area now and no more icons.
Task-3300854
Part-of: odoo/odoo#138135
We add the option to keep the completed activities to allow the user to keep
track of the past action, especially the uploaded files which are displayed
along the completed activities. This feature can be activated per activity
type and is disabled by default.
We also improve the activity view to give a better overview of what has been
done and what is still to be done and by whom.
We also add tests for those new features:
- check activity data for the views (server-side test)
* Details about the activity view improvements:
** Improvement of the column header:
- progressbar: previously, only visible activities were counted in the
progression bar. Now all are counted.
- activity counter: instead of displaying the total count (next to the
progression bar), we display now a ratio as 2 numbers (only if keep done is
enabled):
** Improvement of the activity cells:
- add assignees in activity cells of activity view (limit to 2 having the
activity with closest deadline, if more a + is displayed). Note: to avoid
spacing between avatar, we add the optional props noSpacing to the avatar
component.
- add done activity in activity cell popover
- increase by 50% the popover height
- display done activity cell in grey
- instead of displaying the activity count if greater than 1, we display a
ratio ongoing / activity count. Note: we don't display the denominator if all
activities are done or all are ongoing.
** Progress bar filter
The activity filter is slighly modified. Previously, when clicking on a color
of the progress bar, all cell with a different color where hidden (ex.: if we
were clicking on the green area to filter planned activities, red cell which
represents overdue activities were hidden even if there was also a planned
activities for this record and activity type). Now we also display cells with
other "color" if there exist for that record and that type an activity
corresponding to the filtered "color".
Technical note: mail_activity.get_activity_data returns now for the activity
types a list of dictionary instead of a list of list. This simplifies the
reading as we can now uses name instead of index (type[1] becomes type.name
for example).
Task-3300854
Part-of: odoo/odoo#138135
Improve link preview code
* remove useless code indirections;
* improve performance of link creation, cleanly support batch-creation (could
lead to 98+5 URLs to the same domain creation within default 10 seconds
instead of 98+1 but we feel it's ok);
* name methods according to ORM;
* use tools for html empty;
Also cleanup link preview tests: concatenate tests when possible, improve
setup, use real-life scenarios (using 'message_post' notably), remove useless
data creation.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
There is a o2m / m2o link between mail.message and mail.shortcode. However
this link is not used: 'messages' (m2o from shortcode to message) is never
set. Anyway there is no usage of this link: shortcodes are replaced in
message body and that's it.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
'email_formatted' on 'res.company' model depends on its formatted catchall
and its underlying partner formatted email. However we do not need to
give 'partner.id.email_formatted' trigger in the compute methods as it is
not stored and thus do not need to recompute it for every change of linked
partners in DB; it is valid for the current transaction. It allows to lessen
invalidation of computed fields.
Task-3557985 (Mail: Message cleanup (shortcode, link))
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138938
Didier (did)