This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
Before this commit, when the user goes to project update of a project
with many tasks and some tasks are linked to some miletones of that
project the the `_compute_can_be_marked_as_done` could take more than
500ms depending on the tasks and miletones in the project (when the
project update of that project is loaded).
This commit fixes the performance by adding an index on `milestone_id`
field in `project.task` model.
Test case:
---------
The sql query made in that compute method took more than 600ms before
that commit.
With the index, the query takes less than 1ms.
X-original-commit: 47e02120b1aa5607a7fc528853629438cecf3e64
Part-of: odoo/odoo#114301
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: SEINLET Nicolas <nse@odoo.com>
This commit adds the possibility to display a properties field in a list
view.
How it works:
When a properties field is present in the arch of a list view, it will
not be displayed directly. It will display its properties as an optional
column. Now, we will find at the end of the dropdown of the optional
columns a section by record parent of the properties field. The proposed
sections will be the properties linked to the parent record of which at
least one record referring to it has been encountered during the
navigation in this list view.
(A parent record is the record storing the properties definition).
Limitation:
Multi-editing is not applicable on properties fields as you cannot edit
one property without modifying all the others.
closesodoo/odoo#112005
Taskid: 3105039
Related: odoo/enterprise#37004
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: mcm-odoo <mcm@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit changes some of the way that users will
work with subtasks in the project app.
Initially, it changes subtasks from a many2many to
a one2many field.
We also add the ability for subtasks to be viewed
straight from the kanban view by drawing a list of
them inside of the kanban box of the parent task.
task-3085016
closesodoo/odoo#112279
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: hr_skills, project
This commit improves the behavior of the ProgressBar field. Before 16.0,
views had a readonly mode, and to avoid having the inputs always visible,
the user had to click on the progressbar to enter into an edition mode.
Nowadays, this is redundant, and make it difficult to guess that the field
is editable. With this commit, the input is always visible, which also
allow to improve the template and the code of the component. The commit
delete unused props/options that were no longer used by the widget.
This commit also remove a legacy scss file that was still present, and the
style of the component has been moved to its own file. Some dead classnames
have been dropped, or replaced by bootstrap classes, reducing the size of
the scss file.
Tests had to be adapted, because some assertions were irrelevant, or were
triggering the click to enter edition mode.
task #3178958closesodoo/odoo#113002
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Rework of the hr.expense workflow so that:
- expenses paid by employee generate purchase.order
- expenses paid by company generate entry that look like payments
Main reason being that purchase.receipt are not active by default.
That makes the entry hard to find, holes in sequences, inconsitency
with payment states.
It also remove the refusal of expenses as this was dead / inaccessible code, only reports can be refused.
task-id: 3126550
[community](https://github.com/odoo/odoo/pull/110518)
[enterprise](https://github.com/odoo/enterprise/pull/36090)
closesodoo/odoo#110518
Related: odoo/upgrade#4266
Related: odoo/enterprise#36090
Signed-off-by: Laurent Smet <las@odoo.com>
In this commit:
- project tasks kanban view: if partner_is_company, we display partner_id
else commercial_partner_id -> this information is useless so we decided to
display partner_id in both cases.
- manager_id is not used in any view -> drop the field
- when creating a task by mail, email_from is set to the sender email then will
be changed depending on partner_id and parent_id, the field name is not significant
as it change and no more contain the original email sender, it's also a duplicated
information that can be got from partner / parent -> delete the field and create
a new partner if no one already exist with the same email.
- when project.analytic_account_id is changed, only tasks that have the same old
analytic_account_id will follow the name value -> we decided to change the behavior
and apply the new value for all tasks.
- project_analytic_account_id not used in any view and in only place in python
-> delete field
- project.project: partner_email, partner_phone are not used in any view ->
delete field
- project.task: partner_email not used -> delete field
- ancestor_id is no more used in any view or python reference as it's a complicated
field to understand by users -> remove ancestor_id from project.task and remove also
ancestor_task_id that is related it to it in timesheet context and replace it with
parent_task_id which is more simpler to understand by users.
task-3103701
closesodoo/odoo#110101
Related: odoo/enterprise#37246
Related: odoo/upgrade#4269
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the default `stage_id` group in the
'All Tasks' list view, as it is causing performance issues
closesodoo/odoo#113435
X-original-commit: 759d7b1a30841535de57c19954eff3507dd61eff
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
This commit, is part of a series of commits that aim to simplifie
the concrete fields API.
In this commit we will remove update prop from concrete fields. Now each
field will directly use this.props.record.update to make changes, and
handle the save in fields that need to (e.g. priority). As a consequence
of this, the record props need to be mandatory.
task-id 3179751
Part-of: odoo/odoo#112792
The field email_from is a computed stored field. Let it compute for
the email_from instead of taking the one from the orginal task
closesodoo/odoo#113107
X-original-commit: 22079d6433d4025f7f92f260bb6f01ba836dcc34
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The goal of this task is to ease the deletion/archiving of recurrent
tasks by giving the user the option to either continue
or stop the recurrence. The two main use-cases are:
\- You have a recurring task for a weekly meeting.
Next week, the user will be on time off. You are thus deleting the task.
However, you would still like tasks generated for the following meetings
and to keep track of the previous meetings.
\- You have a recurring task for a weekly meeting with an employee
that has just been fired. You are thus deleting the task and
you won't need this recurrence anymore.
(You may or may not want to keep track of the previous meetings.)
The main issue we are currently facing is that we need a task that acts
as a template for the recurrence to continue. This means that a user
cannot delete all of his tasks without breaking their recurrence.
Consequently, we will be using a "task template" for each recurrence,
which will only serve technical purposes and be invisible to the users.
When the recurrence is stopped, the task template is deleted.
This simplifies the technical and functional implementation as the user
won't be able to modify the template themselves.
\- Added task templates to recurrences in the data.
\- Deleted "all tasks" option form recurence update and changed "this
and following tasks" to "this and future tasks". Most of the time, the
user is going to update the most recent task, and it doesn't make
any functional sense to update past ones.
\- Same options for delete and archive.
\- No recurrent subtasks allowed anymore.
\- `date_deadline` is copied. We compute it by adding the delta between
the create date and the `date_deadline` of the template to the next
recurrence date.
\- Added filter to several view not to display task templates.
task-2937565
closesodoo/odoo#98088
Related: odoo/upgrade#4232
Related: odoo/enterprise#30416
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
Enable recurrence feature.
Go to Project > Office Design > Customer Review.
Enable recurrence on this task > Change month to year.
Issue:
Crash.
Cause:
`_get_next_recurring_dates` is called without a `repeat_month` arg.
Is is supposed to be a string which is going to be found in MONTHS keys.
Except it is False and so it is not in the list.
Fix:
If we don't receive it, deduce it from `date_start` arg.
closesodoo/odoo#112506
X-original-commit: 566c4904129dc7e81458871656d9b20b19b36246
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
This commit add a mechanism to ensure that someone could never save
changes from an history that diverge (in case there is a partition in
the RTC network or a person A was disconnected while another person B
saved changes that were not transmitted to person A).
task-3002163
closesodoo/odoo#112099
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit remove the legacy implementation of the data export
dialog, which wasn't used since the removal of the legacy list
view. This also allowed us to finally remove the data.js file,
which contained the "legacy legacy" implementation of the model
(DataSetStatic, DataSetSearch...). This was deprecated since v11.
Part of task 3168640
Part-of: odoo/odoo#111809
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
On SO confirmation:
- If all of the following conditions are met,
set the end_date of the Subscription
as the repeat_until date of the Task:
The Product is recurrent and creates a Task,
The Task Template is recurrent,
The end_date field is set on the Subscription.
- If all of the following conditions are met,
apply the Subscription's recurrence to the Task's:
The Product is recurrent and creates a Task,
There is no Task Template on the Product.
- If the Subscription is closed, set the recurring_task
field of the related Task to false.
task-2868306
closesodoo/odoo#92696
Related: odoo/enterprise#27953
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since https://github.com/odoo/odoo/pull/106015, the action `project.action_view_my_task` contains a domain
to filter on the current user's tasks. The default filter that was previously used
to achieve the same purpose is therefore no longer necessary, but was forgotten because of
another bug that removed it when `project_sale` is installed.
This commit removes this filter.
X-original-commit: b908425f886beeee5959313c3b92b546635ee110
Part-of: odoo/odoo#111789
This commit hides name of user from many2many avatar user of
activity view similar as kanban view so it'll display many2many
tags properly in activity view.
task-3132890
closesodoo/odoo#109855
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
You cannot set the Default Analytic Plan for projects in the settings.
Expected behaviour:
You should be able to set the default plan, like any other settings.
Steps to reproduce:
- Install Accounting, Project, (Timesheets if you want to test
project creation with an auto-created analytic account)
- Settings > Check Analytic Accounts
- Try to change the Default Plan in Settings > Project
- Upon saving, the change is lost
Reason for the problem:
The `analytic_plan_id` in the project's `res.config.settings` is
related to the same field on the `res.company` model.
The `analytic_plan_id` that is set on the company upon installing the
project module is a non-stored computed field, which makes a call to a
`_get_default` -> the field cannot be set. It will always return
the first default plan in the sequence.
Fix:
Since the field isn't stored (which would have worked if it was),
we use `ir.config_parameter` to write and read to it, per company.
In master we should just add a `store=True` and write a migration
for it?
Affected versions:
- 16.0
- saas-16.1
- master
opw-3127638
closesodoo/odoo#111635
X-original-commit: 11b0e2556ce824048bb4c760893b05e98537d171
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
Before this commit, when the user wants to edit the parent task and
clicks on Search more button, the search view has no project by default
however, the default project to display in the search view could be the
one set on the task.
This commit adds a default project in the search view and this project
will be the one set on the task in which the user wants to set a parent
task.
closesodoo/odoo#111125
X-original-commit: 8c3a4e7dff719b8f47ed289aabb4405a401655a4
Related: odoo/enterprise#36348
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since odoo#106015, the "Project" field is missing from the list view
opened when clicking on "Add a line" in the "Sub-tasks" or "Blocked By"
tabs in the task form view.
This commit readds this field.
X-original-commit: 925a57a41c335f76a0f2c354b3bb2999e0d970bf
Part-of: odoo/odoo#111125
Before this commit, the default group by on task list view in Field
Service app is stage as it is the case in Project app, this behavior is
not wanted, the list view in Field Service app should have no group by
by default. Also, the default group by in My tasks should be personal
stages and no default group by should be in the list view of All Tasks
menu. Finally, the parent task has been removed in the main list view
instead of displaying in debug mode.
This commit fixes the list view in Field Service to avoid having any group
by by default and also changes the default group by `My Tasks` and `All
tasks` menu. It also adds the parent task field in the main list view
of task and that field will be displayed if the "Sub-tasks" feature and
the debug mode is enabled.
X-original-commit: e8aa2177d5640e9c366fa685651de1b85416705c
Part-of: odoo/odoo#111125
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, when the user drags and drops a task from a stage
to another one in the kanban view of tasks of a project, the kanban
records in the destination stage will be re-sequenced and this
re-sequence will re-render the kanban. For this reason, the
`onWillUpdate` hook in the control panel will be trigger many times
and each trigger will fetch the last project update.
This commit will remove the `onWillUpdate` hook to avoid re-fetching
the last project update when a change is done in the kanban view and
so, the last update of the project will be just fetch when the
component is mounted since the last update is not impacting when a
task changes stage.# Please enter the commit message for your changes.
closesodoo/odoo#110961
X-original-commit: 6117f41f52c45710d313c128bbce1d364dc40b93
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Add a constraint preventing the user from switching the project from company
if the partner doesn't belong to that company, and vice versa.
task-3126301
closesodoo/odoo#109464
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit project simplified view was not pretty because
of some alignment between different section/fields and width of
name field is not as expected.
This commit fix layout of project simplified view to make UX
better.
task-3102445
closesodoo/odoo#108151
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In a previous commit https://github.com/odoo/odoo/pull/98660,
we implemented `_search` method to search by `is_favorite`.
Unfortunately, this method looks for any order item starting with
'is_favorite' and so it could include 'is_favorite_gnagnagna'.
closesodoo/odoo#110745
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- Display 'project title' label and add placeholder on the quickcreate
in project.project kanban view
- Project.task calendar view popover : The literal value of the status
is replaced by a colored dot representing it.
- project.task portal form view : The SOL field is displayed in the list
of timesheets entries if some of those entries have a different SOL as
the one set for the task. The SOL name is made clickable and redirect
to the sale order portal view if the user has access to it.
closesodoo/odoo#103434
Task: 3024151
Related: odoo/enterprise#32860
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
- Description: before this fix, some tips of the project tour poped up
in other apps when the tour was not finished. With this fix, those
particular tips are only displayed in the project app.
- Implementation: Some triggers used in the project tour are generic
class that are also used in other modules (in this case, classes
related to the chatter). When leaving the tour at those steps, the
tip in question will pops up every time this class appears in other
apps (i.e. often for classes related to the chatter). To fix this, the
parameter extra-trigger is used for tour steps related to a generic
class.
closesodoo/odoo#110716
Task: 3024151
X-original-commit: c8f86844a427e0f9665b6f9c5e9e182795fb809e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done the following changes:
- Project tags should be vertically centered
- Rename share readonly for project.project form view
- add demo data while add tasks in a folded stage to the sub-tasks and blocked
by notebooks
- add demo data for archived tasks to the archived project
- change the name of the 'rating page done' webpage to 'Thanks for your Feedback'
- use the avatar widget for the employee
task-2976074
closesodoo/odoo#105904
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since the conversion of the list view to owl, the relative field size
has not been reimplemented. We have decided not to support it anymore.
So we will remove all its uses.
The relative width consists in adding a width attribute with a
value. This value corresponds to the weight of the field, the higher
it is, the more space the field will take. This size is only used when
the list is empty.
Example of this:
<tree>
<field ... width="2">
<field ... width="1">
</tree>
The first field will take 2x more space than the first one when the list
is empty.
closesodoo/odoo#110382
Related: odoo/documentation#3375
Related: odoo/enterprise#36020
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Install project app.
- Active Sub-tasks feature in config settings
- Create task with parent task
- Green the kanban state
- Modify the parent task
Issue:
The kanban state changes when we change the parent task in the task.
Fix:
We avoid the recomputing kanban state.
Why issue occurred:
When we change the parent task _compute_project_id is called and sets the project.
the _compute_kanban_state method depends on the project. So reset the kanban state.
task-3141855
closesodoo/odoo#110492
X-original-commit: 0393cffa71821ba32af8e9ba54225275647c4e70
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The mail code had to override both new and old form views to add the
chatter feature. Since we converted (almost) all uses of the legacy
form view to the new owl views, the old override is no longer necessary.
This commit removes it, and also removes the 'legacy_form' entry in the
registry so all screens should fall back to the new form view, which is
stable.
closesodoo/odoo#110168
Related: odoo/enterprise#35924
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Owl last update fixes the leaking `this` in rendering context of
templates called with `t-call-context` [1]. Since [2], we use the
`t-call-context` directive to control the rendering context of
templates compiled from an arch (e.g. in form and kanban views).
We can now better control what people use in archs, where we don't
want them to access js implementation details, as `this` is no
longer available.
However, the component instance still needs to be accessible in
the compiled template. We thus add the `__comp__` key in the
rendering context. Since we do not want people to access it in
archs, we add a check in the view validation that this string
isn't used in dynamic attributes.
[1] https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6
[2] https://github.com/odoo/odoo/commit/4c5b867ff6b0b674cb83d1a1262ae354ebaa6d57
X-original-commit: 264f313012aa99449d1576ae1110252c13755142
Part-of: odoo/odoo#110196
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Change 'auto_delete_message' into 'auto_delete_keep_log' that has the inverse
meaning. Indeed it is unclear what 'auto_delete_message' really does. It is
used when automatically removing emails sent through mass mailing, to know
if message created through inherits are kept or not. Purpose of keeping them
is to have a log on the document. Deleting the message therefore removes the
log.
In this commit we change the meaning to something positive, keeping logs being
clearer when choosing which option to activate. Functional usage of the field
itself does not change with this commit.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Raphael Collet