Remove quotes when name of a formatted email is also an email, as indicated
in tests. We still get two emails being sent for a given outgoing email
when the name part is an email but that would be difficult to avoid.
Task-3566542
closesodoo/odoo#141856
X-original-commit: odoo/odoo@d3cdaa6c18
Related: odoo/enterprise#50892
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Each failing of the test "activity menu widget: activity menu with 2 models"
was close to midnight. And that was actually the cause of the error.
Actually, when executing that test very close to midnight, the test activities
are set up for a day and the check happens the day after (actually a few second
after). As we check in this test "overdue", "planned" and "today" activities,
the tested value are not inline anymore with the test setup when switching from
a day to the next (passing midnight). For example, "today" activities become
"overdue" activities. To avoid that we patch the date to be far from midnight.
Task-3592798
closesodoo/odoo#141762
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
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
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
We add a test that checks the rendering of the activity view and the activity
popover with activities done.
We also add a test that marks as done an activity and verify that the activity
view is updated accordingly.
And we do a correction in the test "activity menu widget: activity menu with 2
models" (assert.ok(selectContaining... was always true as an array is always
returned and [] is true in javascript).
Task-3558929
Part-of: odoo/odoo#139373
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>
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>
Update counters after all changes. Notably storage of environment variables
(company, alias domain) during mail creation and sending process as well as
computing values depending on alias domain (e.g. reply_to, return-path) lead
to some additional queries to read companies and their alias domains.
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 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: 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
Composer tests now use the multi-company enabled model by default, allowing to
test company-dependent behavior. This has no impact on current tests, as there
is no company-dependent fields on composer model, and all tests are anyway
run into the main company (except multi-company specific tests, suffixed
by '_mc' generally).
We therefore also add some multi-company oriented tests to check notably
return-path or environment companies in various scenarios. Go until the SMTP
generation to test mail server choice, smtp_from and filtering, notifications
email.
Followup of odoo/odoo#136318 and odoo/odoo@3ffa1a0611 notably.
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>
* = 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
The purpose of this commit is to delete the legacy/js/core/time.js file.
We have therefore replaced all calls to time.js with the l10N/date.js utilities.
Part of task 3439226
closesodoo/odoo#138609
Related: odoo/enterprise#48918
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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
- Remove "channel" field in thread formatter.
- Pass `type` for all persona formatters.
- Remove some snake_case to camelCase conversions.
- Add support for inverse fields in discuss JS models.
Details:
1. [REF] mail: remove field 'channel' in thread formatter
This field was used for channel-specific fields, which made
sense when there was a dedicated Channel model that was modeled
with composition with Thread.
To simplify formatter of threads, it's best to flatten props
so that channel-specific fields are immediately available on
thread model. This will improve insertion of data with Threads.
This commit also makes the following other changes:
- remove `discuss.channel/legacy_insert` to use
`mail.record/insert` instead.
- Introduce `toData()` on record, which is helpful to have record
in data format e.g. to pass as a JSON.stringifiable object.
2. [REF] mail: slightly simplify Message.insert from notif
The handling of `mail.record/insert` for Message was handling
transition from starred non-empty message to starred empty message.
To simplify all record insert from server formatted data, the notif
data is just inserted in Message. The adjustment of starred counter
is managed at model level.
This is a prerequisite to significantly simplify all
`mail.record/insert` handling.
3. [REF] mail: rename 'res.users.settings' notifications
Before this commit, notifications related to changes of user
settings were using named notification `mail.record/insert`.
This named notification should be only used for Discuss data that
should be inserted in models. `res.users.settings` is not integrated
in Discuss model, thus it has no reason to use this named
notification.
This commit rename the notification name to `res.users.settings` for
these specific notifications. This prepares simplification on
handling any `mail.record/insert` notifications that should simply
call `Record.insert()`
4. [REF] mail: make dedicate notif for Thread/fold_state
This was using named notif "mail.record/insert", which should
be used to immediately insert data in models. This is however
a dedicated notification to imperatively manager chat window
state based on timing of receiving thread data.
This may eventually become a `mail.record/insert` in the future,
but right now it's much simpler to define it as its own named
notification, in preparation to simplify `mail.record/insert`
notifications handling.
5. [REF] mail: remove Channel in mail.record/insert
This is replaced by `Thread`, so that these data can be
immediately inserted in Thread model.
6. [REF] mail: simplify slightly Attachment.update()
Now that data containing commands is supported, we could
just assign with the command rather than destructure and pick
the dict data part.
7. [REF] mail: introduce assignIn() utils
This function helps reduce LOCs from using the "in" conditional
in sequence:
```js
if (a in data) {
this[a] = data[a];
}
if (b in data) {
this[b] = data[b];
}
if (c in data) {
this[c] = data[c];
}
```
To simply:
```js
assignIn(this, data, [a, b, c]);
```
8. [REF] mail: remove snake_case to camelCase conversion in models
They exist for the sake of keeping Python code snake_case and
JS camelCase. While it's good that each language have a community
that prefer syntax convention, when a codebase uses both languages
and they should work with the same data, it's not great to convert
snake_case to camelCase and vice-versa all the time.
Since server has authority over the data, the server chooses the
format for the keys. Most of them are snake_cased, therefore this
is usually the one we pick.
9. [REF] mail: rename Message.messageReactionGroups to Message.reactions
Easier to read, and matches relation name in JS model
10. [REF] mail: remove explicit assign of some many relations in Message
This reduce amount of custom code in insert(), in preparation to make
all models behave the same in response to inserting data.
11. [REF] mail: rename Thread.customName to Thread.channel_custom_name
To match server data field name, and avoid useless conversion in JS.
12. [REF] mail: simplify Message.insert for recipients
Have formatted data contain `type: "partner"` so it can be assigned
in relational field without adding `type: "partner"` manually in JS.
13. [REF] mail: introduce inverse field in discuss models
With this commit, fields in different models can be linked
together, so that one is mirror of the other field.
This simplifies some `onAdd`/`onDelete` that were added to
sync such fields, and this also simplifies insertion in
relational fields for discuss models that are identified
by records, such as the `MessageReactions` that is identified
by the message and the emoji.
14. [REF] mail: rename CannedResponse.name to 'source'
To make JS model and server data more alike.
15. [REF] mail: remove assignDefined in Persona model
So that eventually all model inserts use `Object.assign()`.
16. [REF] mail: remove 'last_message_id' from channel_info
At some point it was used to display last message in messaging menu.
This is already covered by `channel_fetch_preview` when opening the
messaging menu for the 1st time, so passing `last_message_id` in
channel_info is obsolete.
closesodoo/odoo#137750
Related: odoo/enterprise#48484
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
Test are updated because the wizard is opened instead of the activity form to
schedule a new activity and as the form view is only used to edit already
existing activities, default_res_id and default_res_model are no longer passed.
We defines date_deadline and date_plan_deadline in the schedule wizard because
those date are managed differently (default value, required or not, ...).
Task-3390865
Part-of: odoo/odoo#137969
'alias_user_id' field allows to set a user when creating records through the
mail gateway. This is however quite wrong and eases spoofing. The alias owner
is not the creator of any record, nor responsible.
Current possible ways of being owner / responsible of records created through
the mailgateway
* when you send an email to an alias: if you are recognized you are already
set as creating user and logged message author;
* it is possible to use alias_defaults notably to set fields like 'user_id'
if you want to be notified / responsible of records created through this
specific alias;
Those usages are therefore sufficient, no need to have another way to spoof
users. Moreover it is hidden in technical view of aliases, no model allows
to configure it by default. Moreover since odoo/odoo@3edf181 no default
value is given to alias_user_id as it adds more (ACLs / creator) issues than
really helping setting up mail gateway flows.
Task-3453482
Prepares Task-36879 (Mail: Multi-Domain Aliases)
closesodoo/odoo#138213
Related: odoo/upgrade#5259
Related: odoo/enterprise#48692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to try to detect and log 'email_from' invalid
values when sending emails based on outgoing 'mail.mail'. This implies
checking the returned messages when having a generic Exception when sending
the emails, as we distinguish two use cases that raise through a simple
raise: missing from and invalid from.
New failure types 'mail_from_missing' and 'mail_from_invalid' are also
added at 'mail.notification' and 'mailing.trace' level, as other failure
types.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#138202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Extract some test preparation, cleanup and improvements before gradually
adding features that impact tests.
Add tests about 'copy()' behavior in 'mail.alias.mixin' as it will be
impacted by multi-company enabled aliases.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#138202
This reverts commit 4573ca0c83eb63785016f4389a5157efb21fa9a4.
Because now, `display_name` is implicitly on every form (last breadcrumb
item). Then it will be queried by `onchange` calls. When we create a
new record, `_rec_name` can be `False` and the display_name will be a
technical one: '<model_name>,<NewId0x...>' which is uglier than the
previous situation showing 'New'.
Part-of: odoo/odoo#138061
Reorganize tests, perform some renaming. Tests stay as they are to ease
comparison through versions. We notably extract formatting related tests
into their own class, allowing to keep their setup only for those tests.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
RATIONALE
Currently when an ir.model.fields is removed all tracking linked to it is
lost. Indeed field is required and has an ondelete cascade attribute set
to it. However we should keep tracking values as those made sense when
used and one could want to have access to this information.
SPECIFICATIONS
When removing fields set the field to False instead. Add a new field to
store fields information allowing to keep name, type and groups information
to allow displaying removed tracking values. Use this field only when a
field is removed to avoid duplicating field information when not necessary
and polluting the table.
Task-3499067 (Mail: keep tracking when unlinking fields)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'field_desc' and 'field_type' from 'mail.tracking.value' model. Those
can be retrieved when necessary, as it is mainly used for frontend display
in Chatter.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Remove 'tracking_sequence' on tracking values in DB. Consider insertion order
should be done accordingly and display them based on ID DESC. Sequence is now
used only for order records to insert in DB. Feature is still the same (order
based on sequence) but without having to store the sequence itself. It was
never updated anyway.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Currently tracking an unsupported field type simply skips the field. As code
has been cleaned and natively support 2many fields we consider tracking should
be done only on supported fields. Otherwise people might wonder why tracking
does not work.
We now raise when the type is not supported, which is currently the case for
html fields. As they may contain lot of data it is better to think of a
specific tracking based on history / diff than logging old / new value.
When the field does not exist on model, instead of returning None we now
raise. Indeed return value was not consistent and 'None' is not something
people expect as tracking values. If the field does not exist tracking should
clearly say it, as it indicates a model issue somewhere.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
In old times, 'account' and 'project' supported 2many fields tracking. Then
it was moved directly into 'mail'. Thanks to precommit hooks and complete
record access for relational fields, it is now possible to track 2many
fields.
In this commit we cleanup odoo/odoo@167944cc93 that landed during work on this task and
add some tests to be sure it is effectively covered.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
SPEC 1: prepare all tracking values at same code place
Delegate all computation of tracking values into the 'create_tracking_values'
method. Curently part of it (currency field) is done in the caller. Better
split code per feature.
Method is also made private, as it is not required to expose it.
SPEC 2: cleanup tracking value formatting methods and calls
Code used to display tracking value can be simplified: remove unnecessary
wrappers, make code easier to read, avoid composition of field name but
use a mapping instead (easier to grep 'old_value_char' when it is effectively
used).
Ensure code always calls '_tracking_value_format' to ease future improvements
and have all formatting code being batch-enabled.
SPEC 3: simplify Chatter formatted value structure
'fieldType' is currently added in old and new values. As it is a field
property it can be moved higher in the formatting result to be included
only once. Also add 'fieldName', the column name, to the formatted results
as it will soon help various tool methods. Moreover it makes sense to have
the source of the tracking as the real column name, in addition to its
string and type.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
When possible, use '@users' decorator. Rename tests to better match their
main purpose, notably
* test_mail_track*: mail_track specific (specific fields, display)
* test_message_track*: overall behavior of 'message_track', notably subtypes,
template usage, ...
Add some additional tests and improve test coverage, as some field types
were not covered (date, datetime, text notably). Improve currency
check for monetary fields.
Move 'mail.tracking.duration.mixin' tests into the file testing mixins
linked to 'mail.thread', rename the Case class according to current test
guidelines.
Also starting from now, `MailCommon` flushes tracking automatically at
setup time, allowing to remove some custom flush done in tests. That way
tests are less prone to non deterministic errors. This implies some changes
in execution of tests, which means some updated query counters notably.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
With this commit, instead of `Record.insert()` before setting
relation with records, we can immediately pass record data.
For example:
```js
message.author = { id: 3, type: "partner", name: "Admin" };
thread.messages.add({ id: 10, body: "some-text-content" })
```
This is supported on all relational fields that define a target
model.
To make this work while drastically avoiding cyclic dependencies
in code, whenever data have to be inserted in relation, they are
pre-inserted with essential data, and then they are fully inserted
after being registered in the relation.
closesodoo/odoo#136539
Related: odoo/enterprise#47854
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, all mail templates were shared, which was cluttering the UI
for everyone.
Now, each user can have their own templates that they can edit and save. Access
is done through the mail composer wizard, where users can only access their own
templates and templates that don't belong to anyone.
Some groups are considered as admins and can access all templates in
Settings/Technical/Email/Email Templates:
- Sales Admin
- Project Admins
- Helpdesk Admins
- Accountants
- Event Admins
- Recruitment Admins
Task-2504439
Part-of: odoo/odoo#126049
* = bus, calendar, im_livechat, hr, project_todo, sms, snailmail,
test_mail, web, website_livechat
The current implementation often led to tests relying on DOM structure
to properly target the correct element with the text.
It is now easier to simply check if a parent contains some text.
closesodoo/odoo#136295
Related: odoo/enterprise#47770
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some tests are updated to lessen diff in future tests, especially about
aliases. Some tests are fixed as they are somehow incorrect (notably
in gateway testing) but currently passing as mail gateway is quite
permissive.
Add some tests preparing MC / alias domains configuration notably about
company / alias synchronization, which is currently only based on config
parameters.
Also update some tests by using fstrings which are generally more readable.
Finally move some tests to their right file / main testing class to keep
them ordered by main topic.
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#136318
X-original-commit: odoo/odoo@c18300e225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Thibault Delavallée