How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Context
In a previous fix https://github.com/odoo/odoo/pull/83276
, the `_notify_get_reply_to_formatted_email` method was introduced
to prevent edge-cases where the cypthon `email` library might incorrectly
fold the “Reply-To” email header.
We identified an other corner case where DKIM signature verification
might fail on the recipient’s end depending on the tech stack used to
verify the DKIM signature vs the one used to DKIM sign it on the
sending end.
This might be related to how RFC5322 and RFC6376 interact with each other :
In RFC5322 defines folding white spaces as follows :
```
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
with obsolete FWS = 1*WSP *(CRLF 1*WSP)
```
While RFC6376 uses :
`FWS = [*WSP CRLF] 1*WSP
`
Based on this, it seems that for proper header content folding,
the specifications expects at least one WSP (space or tab) before a CRLF.
Currently when using the `email` cpython library to handle email
objects, we observed that when the header value for the “Reply-To” is
longer than 68 characters, it will return a folded string representation
adding a linebreak after the colon.
Example:
`Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n`
Notice that the there is no WSP between the colon character an `\r\n`.
It seems that in this corner case, certain DKIM verification tech stacks
(from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to”
header as empty, while others correct for it (Gmail). This in returns leads
to the DKIM signature verification failing.
As it is impossible to test every possible combination of DKIM tech
stacks in the email ecosystem and that until the `email` cypython library
handles this corner case correctly, this fix tries to preformat the
“Reply-To” more defensively.
We also print a warning log if the `record_email` alone is longer than
68 characters (as it will not be folded), inviting the user to shorten
it to prevent DKIM verification issues.
Unit test fixing:
- shortened alias name to prevent the 68 character
limit from being triggered during the test_notification_reply_to_batch
performance test (as we are not testing the 68 char here)
- changed language in test_mail_message_values_fromto_long_name
to reflect the new 68 character limit and mutted
logger, as it now print a warning message
Considerations for the future
This PR only prevents the “Reply-To” from being malformed. In theory,
the miss-folding could happen to any email header constructed using the
`email` cpython library. In practice, the probability of the “To” and
“From” being affected is low, as they usually don’t exceed a total of
78 characters as per RFC.
Nevertheless if the future shows that this might be a bigger issue, one
should think about:
* On Odoo side: add a more robust header value formatting applied to all
affected headers before the email gets sent out
* On Python’s side: work with the `email` library maintainer to find a
longterm solution
opw-3826296
fixed test and conflicts in 17.0 FW
closesodoo/odoo#161014
X-original-commit: 894f981d04195861e757c052b7d10155cb5975b4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Outlook and similar Windows based systems use windows-874 for encoding
Thai characters which is not natively known by Python.
Simply aliasing the Windows encoding as cp874 adds support for this
encoding.
opw-3684161
closesodoo/odoo#161117
X-original-commit: 65d4c2507e762dc273a02a2e2215c49a5976568d
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Some of the non canononical timezones are not present in Ubuntu Noble,
it would be a better practice to only use canonical timezones in data
and tests.
Note that this is not a real fix for all cases since the database that
ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have
the issue with timezones already in database.
One of the possible fix would be to manage that during upgrades, but
this isn't a verry flexible solution since upgrade are meant to manage
chyange of version, not change of server. If an old 17.0 versions needs
to be moved to a Noble server, this won't work.
Another solution would be to install package like tzdata-legacy that may
keep the old timezones but it is not the only think since TAI-10 are
also in this package. This solution is not ideal because non canonical
timezone will still be shown in the dropdown. We would need to filter
them.
A last solution would be to add the support for those old timezones by
monkeypatching the lib. This way, only new timezones would be shown but
non canonical one won't crash when used. This is not ideal either
because we may need to keep this for a while. But in combination with
the upgrade solution, it may work proprely.
Part-of: odoo/odoo#160842
- Create a Partner who is a valid Peppol participant
- Clear their UBL format - they are still displayed as valid (Bug 1)
- Create an invoice for that partner and confirm it. The Peppol state changes to 'ready'
- Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant
- Reset the invoice to draft, confirm again: the peppol move state is still `ready`
1. Do not set a participant as valid if a peppol-incompatible edi format has been selected
2. Only save Peppol move state if it's processing/done already. Otherwise, let users clear it by resetting to draft.
(until we implement giving them control over this field)
opw-3784945
closesodoo/odoo#159852
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When we use the `|` (or) version of this rule the ORM generates two
sub-queries when checking the company. This causes sub-optimal and in
some cases really bad planning for the queries and thus PG takes hours
to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one
sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in
better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
closesodoo/odoo#159123
X-original-commit: 1b5c41f36801fb886ec591f29dba42787d698526
Related: odoo/enterprise#59378
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
The way we cache the image is not right when that image is not on the
current record. For instance displaying a partner/user image. The unique
key used is not related to that record.
Introduced by https://github.com/odoo/odoo/pull/97544closesodoo/odoo#157199
X-original-commit: d127ec26d8e8d42c0e25668797cbd0f37203dc52
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: fja-odoo <fja@odoo.com>
Side effect due to a combination of odoo/odoo#124182 making field_id not
required to keep trackings when removing fields, and odoo/odoo@9c9552fd20
where field is used to find model when computing groups instead of message
in case the tracking is logged on a model different from the field model
e.g. accounting.
Steps to reproduce:
1. Install project_enterprise in saas-16.4
2. Create a task and update some values for Date deadline
3. Upgrade to 17.0
4. Try to open the task in the upgraded DB.
We get an error:
```
ValueError('All tracking value should belong to the same model.')
```
The reason is that `date_deadline` field is removed during the upgrade
and thus `fields_models` is empty in
https://github.com/odoo/odoo/blob/0649134444fa6b26de1c8c25d7c4a3f70c6d64e0/addons/mail/models/mail_tracking_value.py#L120-L121closesodoo/odoo#156571
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In odoo/odoo@9c9552fd20 a support of tracking value belonging to another model
than the message has been added. In such cases the formatting method written
at odoo/odoo#124182 fails as it expects a single model for all tracking values
it receives. When field is removed 'model' is False, and we fallback on
mail_message model.
Part-of: odoo/odoo#156571
`_message_auto_subscribe` relies on `_get_subscription_data` to know who
is subscribed to what. This method uses a raw SQL query but doesn't flush
the relevant records beforehand.
This is not an issue in most normal cases, but if followers are edited manually
for example in order to merge existing records. It may cause issues when
assigning a user to the record after merging, as the this will attempt to add
them to the list of followers automatically, when they already were on it.
task-3713472
original issue in opw-3634410
closesodoo/odoo#155139
X-original-commit: d1b0e46f7d3034c400ba3c60f343c21c68aa011e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
How to reproduce:
- Install CRM with demo data
- Configure one activity type to keep done activities
- Go to CRM and chose a kanban column with a green status (only planned
activities for that state)
- On a lead of that column, add an activity of the type chosen above with a
deadline in the past
- When going back to the kanban view, that column has the overdue status (red)
- Mark that activity as done
- Reload the kanban view
The kanban column has still the status overdue (red) while there are no more
overdue activity in that state.
With this fix, after reloading the kanban view, the header displays the correct
status summary. In the example above, the kanban column header is green.
While adding test, we have noticed that the 2 methods _read_group_groupby and
_search_activity_state were computing the activity state differently leading to
inconsistency. Actually, the newly added test was failing because the
read_group was returning 2 overdue records while only one was. We correct this
here as well by using the same computation in the 2 methods.
Technical note: archived activities were returned when grouping by
activity_state because that part was done in SQL and not taking into account
the recently added active field. While adding it in the "_read_group_groupby"
method, we also add it in "_search_activity_state" to avoid the same problem
when searching on activity_state.
Task-3732333
closesodoo/odoo#153274
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Go to activity view.
- Schedule an activity for one record. (Say 8 records are available)
- Schedule an activity for the second time. (Again 8 records are available)
- Try to schedule an activity for the 3rd time. (Only 2 records are available)
Issue:
Since 7682286, the existing props of activity model are being passed as params
while scheduling an activity. Currently, `["activity_ids", "!=", false]` is
being pushed to the domain of activity model in order to display only those
records on which activities have been set. As a result, after you schedule
activities more than once, `["activity_ids", "!=", false]` domain gets applied
and the list of records available for scheduling activity is restricted from
the third time onwards.
Fix:
This commit passes the props from searchModel as params to the 'load' method
while scheduling activity, instead of existing props, to ensure that the
existing params are applied as well as all records are accessible for
scheduling an activity, in `searchCreateDialog`
(i.e.["activity_ids", "!=", false] condition is not added as domain).
Task : 3721750
closesodoo/odoo#155700
X-original-commit: 339df084567206cff8a5487bbe9dec249671244a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Khushi Patel (khpa) <khpa@odoo.com>
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3084943: Event: Improve communication scheduler scalability
Part-of: odoo/odoo#155717
Co-authored-by: Stéphane Debauche <std@odoo.com>
How to reproduce:
- Install hr with demo data
- Create a user without access to hr and turn it into an employee
- Create a user for Abigail
- Assign Abigail as manager of the new user
- Click on "onboarding plan" in the chatter of the new user
- Then in the dialog, click on "Schedule" button
You get the error "Assigned user test has no access to the document and is not
able to handle this activity." because the new user has no access to the record
employee on which those activities are scheduled.
As activities for which the user has no access to the underlying record are now
displayed in the systray (with no access to the record), we remove the check
that prevent assigning an activity to a user on a record he has no access to.
Technical note: before odoo/odoo#149965, activities scheduled manually were
created with the flag "automated" set to True and when this flag is set the
check that ensures that the user has access to the record is skipped. With
odoo/odoo#149965, as the "automated" flag is set to False when scheduling
activities manually, an error is trigerred if the user has no access to the
underlying record. Here we always skip that test and mark the method as
deprecated because the user can see the activity no matter the access he has on
the underlying record.
Task-3598836
closesodoo/odoo#155576
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
__getitem__() of BaseModel, reset the prefetch set of the recordset.
Fix _compute_activity_date_deadline, to batched the reading of
activity's deadline.
closesodoo/odoo#154860
X-original-commit: ef7226aaa2f0ad135133fe27bdf1414b7ebf2a92
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps:
- Go to any event with tickets and using the ticket confirmation
template, sending 'after new confirmation'.
- Confirm a new attendee.
- An email is sent but the chatter only shows the attachment and the
subject, with no body.
Issue:
Chatter should show full content of the email.
Reason:
Above 16.2+ the 'body' is not implicitely set when genrating the
template in ``mail_template.send_mail()``. As discussed with RETH, when
requesting the 'body_html' for a template, setting the 'body' solves the
problem.
opw-3562438
closesodoo/odoo#151930
X-original-commit: 0a3d4b10a7c81d05d9bf6864b0b9a2f48f09b2a0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a 'scheduled_date' is given to posting API notifications are delayed.
They are send using a cron running on a schedule model. However SMS are
not respecting this parameter. This is now fixed.
We also use sql.now() instead of datetime.now() when checking notification
delay. This leads to values that are consistent through the transaction
and avoid non deterministic behavior.
This leads to fixing a global mock of "cr.now" that has unexpected side
effects in composer tests. Indeed now that the scheduled notification checks
cursor now instead of datetime now this global mock leads to some notification
not being sent. We now mock cr.now() only for creating records, allowing
to effectively test templates using create_date for dynamic scheduled date
computation.
closesodoo/odoo#150911
Related: odoo/enterprise#55052
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
One of our customers is receiving emails with headers and attachments
encoded using the "iso-8859-8-i" charset instead of "iso-8859-8" which
is natively supported by Python. Both encoding are using the same
character set[^1] and only differ in the way the text is rendered on
screen[^2][^3] which is not revelant for Python.
Add an alias for iso-8859-8-i so that the emails that this customer
receive stop failing in Odoo. Note that there is a PR opened on
CPython for exactly that, see [bpo-18624].
opw-3653210
[bpo-18624]: https://bugs.python.org/issue18624
[^1]: https://encoding.spec.whatwg.org/#legacy-single-byte-encodings
[^2]: <data:text/html;charset=iso-8859-8,hello%20%E0%E1%E2%E3>
[^3]: <data:text/html;charset=iso-8859-8-i,hello%20%E0%E1%E2%E3>
closesodoo/odoo#150467
X-original-commit: 5a025467a605ca4fa963b79bae254c823518d54c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
How to reproduce:
- Install contacts
- Go to any contact
- Schedule an activity on the contact by clicking on "Activities"
The flag automated of the created activity is set to True which shouldn't be
the case (you can check either in the DB or by adding the field with studio).
The same happens when scheduling plan, scheduling activities on multiple
records in the view list or a plan on multiple records.
This fixes the problem by modifying the activity schedule wizard so that it
always creates activities with automated flag set to False.
Note that that flags is used to distinguish activities created manually from
those created automatically. Some flows automatically cancel automated
activities (e.g. cancel 'validate my ticket') but those should probably not
cancel user defined activities (e.g. 'ask customer to pay'). That's why we must
ensure that activity created manually have that flag set to False.
Task-3691827
closesodoo/odoo#149965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Default_from on alias domain is currently managed like bounce or catchall.
We consider it is always only a left-part of an email address that should
be completed with alias domain name.
However and notably at migration default_from could contain a complete
email address. In that case better be defensive and keep the domain part
of the value.
Task-3690919
closesodoo/odoo#149887
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
'_redirect_to_record' is used notably when accessing 'mail/view' controller
used notably with email notifications ('See Document' link). In order to
try to avoid multi company issues a call to '_get_mail_redirect_suggested_company'
is performed in order to find the record's preferred company.
However it is defined on 'mail.thread' which means the redirect crashes if
invoked using a non thread record. This is quite rare but may happen with
models using a mailgateway implementation similar to 'mail.thread' without
inheriting from the mixin (see 'mail.group' model added in Odoo 16).
This limitation is present since a long time but is now more present since
odoo/odoo@f4523fcd92 .
Task-3689459
closesodoo/odoo#150309
X-original-commit: 9a366dcdb789d0f160871ee4d29a463e2641ca26
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A model can specify a preferred company (cid) when redirecting someone from a mail
link.
Before this commit, this cid was taken into account when redirecting only if the
user is logged in.
With this commit, even if the user is not logged in, the redirect link will take
that preferred cid into account.
opw-3613144
closesodoo/odoo#149254
X-original-commit: e70a27d820d94dba7e8c45865ddc5fbc46f9f26f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Adrien Milis (miad) <miad@odoo.com>
Fix various use case of HTML encoding / escaping in mail flows. Depending on
functional flow HTML entities could appear as they were not correctly
managed as valid HTML.
Notably when managing attachments in '_process_attachments_for_post' we
should return Markup-ized HTML to be sure it is considered as valid in
other post processing.
Task-3675159 (Mail: correctly escape HTML when updating content)
Task-3619348 (Mail: propagate markup flag when processing attachments)
closesodoo/odoo#148769
X-original-commit: f4bf63077d4129807e00e15b833e47623869491f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some printers incorrectly specify the content-type of PDFs as "pdf" instead of
the correct "application/pdf." To handle this situation,
an alias has been introduced, treating content-type "pdf" as "application/pdf."
[Reproducing original bug]
1. run odoo with documents module
2. prepare email file
2.1 create email with a pdf attached
2.2 export email to .eml
2.3 modify content-type of the pdf from "application/pdf" to "pdf"
3. send prepared email to odoo to inbox-financial alias (the default one
creating documents)
4. Go to documents, observe that the created PDF is blank!
[Motivation for fix]
Since:
1. Odoo uses the Python built-in module for parsing emails*
(the actual issue lies outside Odoo code).
2. "pdf" is not an accepted MIME type according to current norms
(https://datatracker.ietf.org/doc/html/rfc6838#section-4.2).
It's not an actual Odoo bug.
However, redirecting this issue to the appropriate printer manufacturer and
waiting for a fix may be time-consuming, hence the proposed fix.
*function parsing email with the Python built-in module
https://github.com/odoo/odoo/blob/407ea60796a2b18eb02f5569e1cfab9f1163a572/addons/mail/models/mail_thread.py#L1282
opw-3462260
closesodoo/odoo#147363
X-original-commit: e95a19341536e442239a7e940089d7f66ab9f534
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
Activities made on the archived record are not shown in the activity
system-tray menu.
After this commit:
Activities made on the archived record are shown in the system-tray
activity menu.
task-3458597
closesodoo/odoo#146462
X-original-commit: d6d91b4f86d3d0ef954160a9de6e42a1bc4e184f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Summary
-------
Currently, duplicating a journal results in the new journal's mail alias
name overwriting the original's.
Steps to reproduce
------------------
* install `account_accountant`
* duplicate the "Vendor Bills" journal
=> you should see that the alias name of the new journal overwrites the
alias of the original journal.
Cause
-----
When duplicating a journal, the new journal inherits the alias of the
original. Because of this, a specific code segment intended to generate
missing aliases for new sale/purchase journals, inadvertently modifies
the name of the alias.
opw-3597349
closesodoo/odoo#143771
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Install project app.
- Go to task view from specific project.
- Open activity view.
- Set an activity on any task.
- Click on "Schedule Activity" button.
Issue:
- User able to select all tasks instead of tasks from
that specific project as it is working for first time
user opens that view.
Cause:
- Domain of `SelectCreateDialog` became empty when
load calls from other activity view actions.
Fix:
- Pass props in load method call to have default data as
it is when calling load method.
task-3293310
closesodoo/odoo#143721
X-original-commit: fd96a43af96ef6706680a97d19a184c6e4aad6fb
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
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
Thibault Delavallée