When mailgateway receives an incoming email being a reply to a thread but
containing a recipient being an alias linked to another model, it is
considered as a forward to that new alias. It therefore skips the reply
step in routing and applies rules related to new thread, aka checking
all recipients.
Consider this use case: receives a email on a task from "project@domain"
project being the alias of the project which creates new tasks when not
routing replies. Reply / forward it to "project@domain, sales@domain" in
order to transfer it to the sales team (sales alias creates new leads).
As this is a forward, both aliases are evaluated, leading to a new task and a
lead which is not what we expect.
We solve this issue by removing alias linked to the ignored reply model
when considering recipients.
PR #46764
Task ID 2121551
closesodoo/odoo#46784
X-original-commit: 7cff7787cb42cc9d3d0cb4c5af41a9f09d59d1ff
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
/!\ This commit is a manual forward-port of two PR targetting originally
11.0: #40442 and its fix / partial revert #41042. /!\
Purpose of this commit is to check all recipients of incoming emails when
trying to determine the route to apply. Notably
* an incoming email should be considered as a write to catchall only if all
recipients are catchall. Catchall + a valid alias should take the alias
into account;
* an incoming email sent to the bounce alias should be considered as a bounce
even if another valid alias is in recipients and whatever the order. Indeed
it indicates an issue and bounce is considered as more important;
* forward to an alias linked to another model should check all recipients
and not only the first one. Otherwise reply_alias, forward_alias is
considered as a reply whereas it should be considered as a forward when
considering all recipients;
Tests are added according to those specifications.
Please see original PRs for more details about the content, the comments
done on it and the various discussions.
PR #46764
Task ID 2121551
X-original-commit: df00bd2d3bddf9a2b56e8554380669025e146d21
When the `select` returns nothing more than ids that are already known, there is
no need to make it at all.
This removes one query from `_read` every time it has to fetch only fields that
are stored in a different table (o2m, ...), which happens all the time when
reading a stored field first (triggering prefetch) and then reading a o2m.
The query that is now removed was used to check access rules, but the trick is
to use `check_access_rule` to verify the rules in python instead.
Part of task-2061122
closesodoo/odoo#36263
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order
as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created.
This causes duplicate entries in the mail.notification table, and can
crash when an old unique constraint is still present in that table (from
earlier Odoo versions)
To prevent this, we deduplicate the notifications and order by notification
type to get 'email' first in case the user have different notification
type ('email', 'inbox').
How to reproduce:
- Create a first user test1
- Create a second user test2
- Merge the contact test1 and test2
- Create a customer customer
- Set the user test1 as salesman
- Create a new sale.order with customer as partner
Add a test to reproduce the pathological scenario
Solution
add distinct on partner.id and order by partner.id,
users.notification_type
closesodoo/odoo#45386
X-original-commit: 00f36c60e4790c8f5341cbc4f2c67e22e6d68f87
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
The customizable "out of office" text was removed from the editable views as
part of task-2053585, but some places in the code were still using it, even
though it was never set anymore.
This commit removes the obsolete code.
Part of task-2171864
closesodoo/odoo#44968
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
How to reproduce
================
Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.
This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.
Fix
===
In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.
Task ID 2061760
PR #36845closesodoo/odoo#44765
X-original-commit: e94349ed65e05a40af6e690e366de81fc5aa6725
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
This commit prevents sending a notification within Odoo when a
message is posted from a mailing channel to a user whose notification
management preference is set to "Handle by Emails".
Task-ID 2033302
closesodoo/odoo#36000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
Purpose
=======
Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist
closesodoo/odoo#43830
Taskid: 2176445
X-original-commit: 82d2d581a2590a9c782cbc71b5005a4198b70d77
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit 976e560a87.
Even if it didn't looked like a bad idea, this need some more thinking.
This new version of query count creates random failure of runbot builds.
closesodoo/odoo#43820
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Query counts weren't adapted to recent performance changes.
This commit updates the different query counts to make sure
any commit changing the query counts knows it and does it on purpose.
Some query counts may vary between community and enterprise
and therefore have a higher value than needed in community version.
closesodoo/odoo#43202
Related: odoo/enterprise#7682
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Revision on https://github.com/odoo/odoo/commit/a55c78836f172dba1cfa6db3df0e927a9c7e6471
Before this commit, marking all messages as read from Discuss inbox
did not update the UI correctly, hence requiring a page reload.
This bug comes from a typo in the commit above, which passed a list
of mail_notification instead of message ids, so that messages were
handled as marked as read by the web client.
Task-Id 2158452
closesodoo/odoo#43109
X-original-commit: 3cc03ee3db90c310dc60fe7ea18e0e6abe741ffa
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Purpose of this commit is to give a way to access to company email and catchall
with formatting. Those will be used in various automated emails. Indeed
currently several templates use either ``company_id.partner_id.email``,
``company_id.email``, or even don't provide fallback values.
With this commit from a company record people will be able to use
* a correctly formatted catchall: ``"My Company Name"
<catchall_alias@catchall_domain>``
* an email_formatted field like partner email_formatted that is either its
partner-related email_formatted value, or formatted catchall if its partner
is not correctly configured;
Various calls to mail creation are updated accordingly.
Task ID 1853147
PR #32243
This is a performance fix. It avoids the cost of XML/HTML translations
for fields that may not be necessary when prefetching fields on records.
This patch marks such fields as non-prefetchable by default.
The code that changes the attribute `translate` on HTML fields (from
`translate=True` to `translate=html_translate`) has been adapted to
allow the setup of textual fields to mark the field as non-prefetchable.
Jairo Llopis made a comparative benchmark: evaluating `name_get` on
`event.event` records. The method needs the field `name` and without
the patch, the prefetching mechanism reads the translated HTML field
`description` as well. This patch speeds up the benchmark from 5800ms
to 800ms (see https://github.com/odoo/odoo/pull/37967#issuecomment-538364011).
closesodoo/odoo#40771
X-original-commit: e5ee5e5b65f85d66c8d59594ead9eece172c4282
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Pedro Baeza <pedro.baeza@tecnativa.com>
Co-authored-by: Jairo Llopis <jairo.llopis@tecnativa.com>
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Now that all tests using old ``BaseFunctionalTest`` and ``MockEmails``
classes are updated we can safely remove them.
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test message post
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test message management
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test mail message
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test mail gateway
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test mail channel
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test_message_composer, test_message_track and
test_mail_activity.
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test_mail_followers, test_mail_mail,
test_mail_template.
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update tests to new tools / asserts / helpers / classes defined in mail
and test_mail. Notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
In this commit we update: test_discuss, test_invite, test_ir_actions and
test_odoobot.
LINKS
Task ID 2068986
PR #38070
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in application tests or force them
to write custom quick and dirty tools and asserts. Purpose of this merge
is therefore to move tools classes and mocks to mail directly and use them
in various sub modules.
SPECIFICATIONS
In this commit we add ``TestMailCommon`` that will be the class for all test_*
modules linked to mail features. It is build upon tools made available in
mail tests (mocks, tools, asserts) and give the functional basis for mail
tests.
This commit also introduces ``TestMailMultiCompanyCommon`` that is a small
multi company testing class build on ``TestMailCommon``.
``TestRecipients`` class is kept as it creates some testing partners, used
notably for notifications and recipients.
Future commits will gradually make tests use this class instead of the
``BaseFunctionalTest`` that will be set to retirement.
LINKS
Task ID 2068986
PR #38070
The tracked field is now a relation to the corresponding ir.model.field.
This prevents potential privacy issues should the field be deleted or renamed.
closesodoo/odoo#39232
Taskid: 2088634
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
A patched method was not unpatched. Which triggered issues in a staging
master branch trying to untie a bit mail tests.
closesodoo/odoo#40099
X-original-commit: 5dbf4c56765c3661eb2dca24e90bc0b420918e9a
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
New performances test looks non deterministic, sometimes break with
28 queries instead of 25. This commit temporary pump up query count
to avoid staging fails, further investigation is needed.
closesodoo/odoo#39132
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Currently there are some high-level tests that trigger composer creation,
call or send_mail action. However it is always a good idea to have some
performance tests only for some parts of mail application.
In this commit we also fix some naming and remove unnecessary variables
as a side dish.
closesodoo/odoo#38475
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Somehow followup of dbb6cfdbf8 . Purpose is
to use formataddr from tools instead of manually handcrafting the full
email address format. Indeed the tools one correctly encapsulates and
format name and email.
Task ID 2068986
Before this commit, when assigning a user onto a record,
through the field user_id, the email was sent
in the current user's language
After this commit, it is sent in the partner's language
OPW 2060898
closesodoo/odoo#38142
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Reorganize tests, notably
* put composer with template tests in with composer tests;
* put post with template tests with post tests;
* put tracking multi company test with tracking tests;
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Split cc tests to either discuss or mail gateway tests. It allows to remove an
unnecessary file.
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
Reorganize tests, notably
* put message_post related test in test_message_post;
* have only composer related test in test_message_compose(r);
* put alias tests in test_mail_gateway;
* move some discuss tests to post tests as they are linked to notification
details, not really Discuss features.
LINKS
Task 1958697
PURPOSE
In order to rewrite some tests, remove low-level tests and add coverage
first step is to reorganize a bit test_mail content. Several tests cases
are spread among several files and finding back some feature coverage
tests is not easy.
SPECIFICATIONS
* put channel moderation tests in test_mail_channel;
* rename resend to message management;
* rename multi company test to redirect tests:
LINKS
Task 1958697
Thibault Delavallée