Purpose
=======
Ensure that the names of the UTMs models (campaign, medium and source)
are unique.
If not, generate automatically an unique name.
The name field is no more translatable; it makes no sense to translate
a technical which will be added in the URL, and can even cause issues
(the UTM record is not recognized because of the translation).
For the campaign, we keep a "translatable" name which is called
"title".
For the UTM source, use a mixin to generate automatically the name of
the source based on the content (_rec_name) of the record. So we remove
the override of create / write / copy in the different models and
ensure consistency between those models.
Task-2245823
closesodoo/odoo#60501
Related: odoo/enterprise#21882
Related: odoo/upgrade#1863
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
This commit consolidates UTM usage across all applications.
Global purpose is to avoid having undesired side-effects, such as unlinking an
utm.source/utm.medium/utm.campaign and at the same time cascading the deletion
to various records without noticing.
SPECS
ALLOW MORE PEOPLE TO CLEAN UTM RECORDS
Currently, not even the system administrator can delete utm.mediums and
utm.sources (he can only delete campaigns).
These were considered as "technical records", but allowing some cleanup is
a good idea since these records are often automatically generated and can
create a lot of unnecessary noise in the database.
That's why we now allow the following groups to delete all UTM records
(sources, mediums and campaigns):
- group_system
- group_mass_mailing_user
- group_social_manager (enterprise)
PREVENT DELETION
For some use cases, removing an utm.source/utm.medium/utm.campaign would
cascade delete the related record, which was unintended / hidden side effect.
These combinations were secured by preventing to unlink:
- mailing.mailing source_id field
Trying to delete the utm.source will throw an error message
- mailing.mailing medium_id field
Trying to delete the utm.medium will throw an error message
- hr.recruitment.source source_id field
Trying to delete the utm.source will throw an error message
ADDING CLEAN ERROR MESSAGES
When trying to delete an UTM record that is linked with ondelete="restrict", we
improved the error message to give a clear explication to the user, e.g:
"You can't delete these UTM sources as they are linked to the following
mailings in the Mass Mailing APP, and deleting the source would break the
statistics: Newsletter"
SPECIFY 'ondelete' strategy
For a lot of uses of sources/mediums/campaigns, the 'ondelete' strategy was not
specified, leading to the confusion of "is this really how we want to handle
this?".
A lot of ondelete="set null" have been added in various field definitions to
ensure that this is the desired and logical strategy we want for that
specific model.
PREVENT REMOVING HARDCODED UTM RECORDS
In some functional flows, UTM records are hardcoded using their direct
record reference.
This is notably the case for the recruitment process and its creation of
aliases, and for the Email / SMS Marketing flows.
As deleting them would break these flows, we prevent their deletion in a
"api.ondelete" method.
ENFORCE NEW RULES WITH TESTS
A lot of python tests have been added to make sure we enforce the decisions
taken here above.
LINKS
ENT PR odoo/enterprise#19048
Task-2459480
closesodoo/odoo#72239
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A similar fix was originally done in [1], where the access to `env` was done
before the parent dispatch.
The issue was then reintroduced with [2], where the `env` was possibly accessed
again after the dispatch. This works most of the time, but in the rare case
where the session is destroyed during dispatch, which is the case on
`/web/session/destroy`, accessing the environment after that point will crash.
This issue didn't manifest before [3], because the `env` was always initialized
during `checked_call` when calling the `clear` method on it (since `env` is a
magic property). After that commit, the `clear` is not called if not necessary,
therefore it might happen that the `env` is never initialized. This leads to the
crash when trying to initialize it for the first time after the `db` attribute
has been cleared during the destroy, since a `db` is required to initialize it.
The current fix aims to prevent the crash. As opposed to [1] that actually kept
the tracking fields by fetching them before the dispatch, it is decided on this
commit to voluntarily lose the tracking fields when destroying the session,
because keeping them would require too much refactoring for a fix in stable, but
we also feel that it makes sense functionally: those tracking fields were maybe
used for a specific purpose in the original database, but they might mean
something completely different on another database.
[1] 6780597f2d
[2] c78de22a09
[3] f6d56afba0closes#42260closesodoo/odoo#42314
X-original-commit: 2ac11ce7a3f36a1572d886bc872facf339cb6516
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
std-odoo