Before this PR, all this localisation was written in spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#110938
Task-id: 3149182&
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The fiscal device is refered to as the 'fiscal device' in some places,
and 'control unit' in others. This commit changes the references to the
fiscal device to always be 'fiscal device'.
This commit was accidentaly dropped when fixing a forward-port rebase
https://github.com/odoo/odoo/pull/109434, and has thus been reintroduced
in v16 in its own PR.
closesodoo/odoo#110182
X-original-commit: 9049516a0d45ae537f976622f2709e0c098a3003
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
When unlinking or writing a tax report line, the related tags that are no longer relevant were not archived.
We now archive tags if they are still used in account.move.line and display a banner
in report that let the user know there might be a problem and invite him to correct tax tags.
closesodoo/odoo#111287
Task: 3084028
X-original-commit: 8fb35df6225f8c8f7c3aa7fec56acb3bec23d25f
Related: odoo/enterprise#36432
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
In the forward-port to 15.0 of https://github.com/odoo/odoo/commit/b4cd54a3c9227370667913ff2e170e24539c6328 the migration folder was renamed from 5.1 to 15.0.5.1, which causes the forward-port to 16.0 to not take into account this migration.
This change renames the folder back to 5.1, such that the migration will run in 16.0 as well.
Related to task-2993087
closesodoo/odoo#111280
X-original-commit: 86343618a4d6bd7f8e30c30fefdc0f1c2c73f315
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Install MX CoA
"Cash" and "Bank Suspense Account" are missing the tag
"Transferencias bancarias moneda extranjera" account is using the wrong
tag
opw-3033611
closesodoo/odoo#111273
X-original-commit: 4860a77a51f72bbb51b435766733b3c0a74c9a32
Related: odoo/enterprise#36422
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Prior to this commit and on Firefox 109, clicking on a link while in
edit mode on the website app would trigger a traceback.
This is caused by the fact that the LinkPopover widget is contained
inside the iframe while use the ClipboardJS global defined in the top
window.
Indeed, ClipboardJS checks if the target (the button to copy the link)
is an HTMLElement. To do so, it uses the "instanceof" keyword. However,
the __proto__ (what is used for computing instanceof) of the target is
different depending on the browser.
For Chrome, the HTMLElement's __proto__ depends on which "document" it
was created. On Firefox, when attaching an element to a parent, it will
switch __proto__ to the one from the frame from which it is attached.
To fix this, we use the ClipboardJS from the element's instance window.
In any case, using instanceof when working with iframe is a bad idea,
see [1]. In this case, the fix is made because ClipboardJS is an
external library.
Steps to reproduce:
- Download Firefox 109+
- Go on Website and switch to edit mode
- Click on a Link : A traceback appears.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof#instanceof_and_multiple_realmsclosesodoo/odoo#111266
X-original-commit: 732848f2b52bea4ebae18cb5adedf581d5112aa6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Checking company_id=False on records having a required company is useless and leads to more complex queries.
closesodoo/odoo#111197
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Update of taxes could create name collision due to uniqueness of
(name, company, scope, type) on taxes.
We add "[old]" before the tax name to avoid this problem.
closes odoo/odoo#111124
Related: #108571
X-original-commit: e50be0ed9d8ae32f85380b9239de7f3c93d71a93
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
Before this PR, all this localisation was written in spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#109147
Task-id: 3119934
Signed-off-by: Laurent Smet <las@odoo.com>
Before this PR, all this localisation was written in Danish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#111044
Task-id: 3151027
Related: odoo/enterprise#36310
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
when bill to is registered person but ship to is unregistered person then we need to set this
X-original-commit: c53ff49428df2ae02183f7d0eb2c3fbf7f2d108f
Part-of: odoo/odoo#111248
The previous commit solved the issues for the Belgian, ... case, but not
for l10n_latam_invoice_document.
We saw two extra problems we solved:
- As the name is readonly you can not even store the new name easily, so
we needed a force_save on that field.
- As the _compute_name is inherited in this module as well, there is a
logic that recomputes the name when the document type is changed and the
invoice is in draft to recompute that initial value.
However, when you confirm and the date gets set, that logic
is also triggered, while we do not want to recompute but keep
our old document number.
closesodoo/odoo#111294
X-original-commit: 7edee80545daf29b3a46947838a23e1f4458f12d
Related: odoo/enterprise#36434
Signed-off-by: William André (wan) <wan@odoo.com>
Before:
- Create a new sales journal
- Create a new first invoice
- Do not put an invoice date yet
- Change the name from 2023/000001 to e.g. 2023/000010
- Confirm the invoice
- The name will change back to 2023/000001 (which is not the wanted behaviour)
After:
We avoid the change back by adding a condition in the _compute_name, which
is triggered by the invoice_date being set while confirming.
X-original-commit: e31c5767c894a92d22fa8201bc1ccf34b052a336
Part-of: odoo/odoo#111294
This commit adds an attribute in kanban and list archs that
fixes performance issues.
Some tables are very huge and depending of the searched domain,
the search_count made in web_search_read takes much more time
than the search_read. For 10M records, the search_count could take
more than 10x the time of search.
This commit allows to set the count_limit in the arch to override
the hardcoded 10k value.
closesodoo/odoo#111284
X-original-commit: 699215ec9a71b8c9b6a53fe96e924a400d216729
Related: odoo/enterprise#36431
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
The aim of this commit is to fix an issue where the settings fields for the Indonesian localization were visible in all companies of a database.
Context:
In a multi-company environment, a company may have its fiscal country set to Indonesia and have the Indonesian localization activated, but this should only affect the options shown in the accounting settings for that specific company.
Previous to this commit:
When a user activates the Indonesian localization, the settings fields for the localization would be visible in the accounting settings for all companies of the database.
After this commit:
The settings fields for the Indonesian localization will now only be visible in the accounting settings for the specific companies located in Indonesia.
closesodoo/odoo#111285
Task-id: 2854025
X-original-commit: 045e18a624e9261b8650c71cc9999126320648ff
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
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>
To reproduce the issue:
1. Install [Accounting] on Apps
2. On [Settings],
- [Users & Companies]>[Companies]: add a company with country Belgium
- Set the company to the Belgian one
- add French, set the language to it
- [General Settings] - check the [Companies] section
Desired behavior: Correction of VAT label
Impacted versions: 14.0 up to master
opw-3104416
closesodoo/odoo#111243
X-original-commit: f740cbeed106b5e04538128c861151039751ac1d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
With the new 16.0 feature that open any form in edit mode, the html
editor was trying to connect in collaboration each time a record was
opened in a form view that has a collaborative html field.
The peer to peer connection could trigger a lot of rpc because of it's
communication through the bus.
This commit reduces the number of rpc by only trying to connect to
the collaboration network when the user focus the html editor.
task-3151577
closesodoo/odoo#111247
X-original-commit: 9d7aecec811699199e270a5096f00d5cb6f0b15d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
SPECIFICATIONS
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
OTHER CHANGES
Improve 'message_notify' to behave like 'message_post' with attachments.
Add some parameters to the notification process to lessen a bit context
usage.
Improve wording of recently added features.
Improve test coverage of recently modified features.
Cleanup hr_recruitment_survey field naming and file organization, done when
fixing a bug not really related to this branch.
Fixup mail template preview wizard, some rare bugs when previewing notably
attachments.
LINKS
This PR is build on previously merged content that originated form this PR.
See notably odoo/odoo#99482 / Task-2710804 (Mail: Clean MailThread API).
Task-3093257 (Mail: The Composer Update)
Task-2088884 (Mail: Use editable computed stored fields in compose
Prepares Task-3149286 (Account: Cleanup account.invoice.send wizard)
closesodoo/odoo#107356
Related: odoo/upgrade#4243
Related: odoo/enterprise#36387
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Followup of odoo/odoo#95623 (introduce scheduled message notification) as well
as odoo/odoo#99482 (support scheduled datetime from template to composer in
both comment and mailing modes).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
It is still using some outdated classes for margin. Layout was a bit
broken, especially the "Preview as PDF" helper-like line.
Task-3093257 (Mail: The Composer Update)
Task-3149286 (Account: Cleanup account.invoice.send wizard)
Part-of: odoo/odoo#107356
Due to new composer, it is a bit less necessary to create them on the fly
randomly. Some quick code cleaning is performed to better understand code
and variables. Notably 'default_get' override was a bit messy and should
not return unwanted values.
Task-3093257 (Mail: The Composer Update)
Task-3149286 (Account: Cleanup account.invoice.send wizard)
Part-of: odoo/odoo#107356
'applicant_id' name is misleading as one could think it is a m2o. Better
name it 'applicant_ids' to better highlight it is a o2m. Moreover it
avoid conflicts with default value 'default_applicant_id' propagated from
some views (notably jobs kanban view).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Update query counters now that fields are editable computed fields. Some
counters are higher as the usage of composer in code is now closer to the
usage in view, with fields being correctly computed. Some other counters
are a bit lessened, but it globally stays the same.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
PURPOSE
Purpose of this task is to remove the _onchange_template_id method on composer
model. Split it into editable computed stored fields. It gives a better control
of value generation and avoid having to call the onchange when composer is
invoked in code.
SPECIFICATIONS
Remove onchange as it is not used anymore. All fields have been converted.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``subtype_id`` in compute method.
It is currently always set to be a 'comment' subtype. However in mass mailing
mode it is not used, as we do not use the value. Better void it directly.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``force_send`` in compute method.
It is currently computed in a default_get override.
It is set to True in mass mailing mode (send directly by default) and in
monorecord comment mode (send notifications right now). Batch comment delays
notification to use the email queue.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``attachment_ids`` and reports
(``report_template_ids`` on template that generates reports) in compute method.
Computation is based on template and composition mode. In monorecord comment
mode, template is used to generate attachments based on both attachment_ids
of template, and reports coming from report_template_ids. Those are generated
based on the current record to display. As template generation returns a list
of tuples, new attachments are created on the fly during the compute.
In batch or email mode, only attachment_ids from template are used on the
composer. Reports will be generated at sending time.
When template is removed, attachments are reset.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``partner_ids`` in compute
method.
Computation is coming either from template, either from context. When having
a template it uses its 3 fields 'email_cc', 'email_to' and 'partner_to' in
monorecord comment mode. Emails are converted into partners, creating new
ones when the email does not match any existing partner. Composer does not
deal with emails but only with partners.
When having a template in other modes, no recipients are computed as it is
done at sending time. When removing the template, reset it.
When not having a template, recipients may come from the parent in comment
mode, to be sure to notify the same people.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``scheduled_date`` in compute
method.
Scheduled_date computation is coming either from template, either reset. When
having a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``model`` and ``res_ids`` in
compute methods.
Model can be set from parent or using 'active_model' context key frequently
used as the composer is most invoked from list or form views.
Res Ids computation may come from parent in comment mode, if set. It takes
the parent message's res_id. Otherwise the composer uses the 'active_ids'
context key, unless it is too big to be stored in database. Indeed when
invoked for big mailings, 'active_ids' may be a very big list. Support of
'active_ids' when sending is granted in order to not always rely on 'res_ids'
field. When 'active_ids' is not present, fallback on 'active_id'.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``mail_server_id`` in compute
method. Copy value from template when updating it, if set on template. When
removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``body`` and ``subject`` in
compute methods.
Subject computation is coming either form template, either from context.
When having a template with a value set, copy it (in batch mode) or render
it (in monorecord comment mode) on the composer. Otherwise it comes from
the parent (if set), or computed based on the generic '_message_compute_
subject' method in monorecord comment mode, or set to False. When removing
the template, reset it.
Body computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONSS
Improve composer to correctly compute fields ``reply_to(_force_new)`` in
compute methods.
Reply_to computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template reset it.
Reply_to_force_new computation depends on model. If it does not inherit from
MailThread, avoid replies to be considered as thread updates, they will instead
follow the routing rules (alias, ...).
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``email_from`` and ``author_id``
in compute methods.
Email_from computation is coming either from template, either from context.
When having a template with a value set, copy it (in batch mode) or render it
(in monorecord comment mode) on the composer. Otherwise try to take current
user's email. When removing the template, fallback on default thread behavior
(which is current user's email).
Author computation is not controllable from the template currently. We therefore
try to synchronize it with the given email_from (in rendered mode to avoid
trying to find partner based on qweb expressions), or fallback on current user.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``auto_delete(_keep_log)`` in
compute methods.
For auto_delete, computation is coming either from template, either from
composition mode. When having a template, its value copied. Without template
it is True in comment mode to remove notification emails by default. In email
mode we keep emails (backward compatibility mode).
For auto_delete_keep_log, it is used only in email mode. It is used to keep
the core message when unlinking sent emails. It allows to keep the message as
a trace in the record's chatter. In other modes it has no use and can be set
to False. When auto_delete is turned off it has no usage.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``record_name`` in compute method.
Computation is coming either from parent message, either from the record's
display name in monorecord comment mode. In batch mode it makes no sense to
compute a single record name. In email mode it is not used anyway.
Computing it in composer allows to benefit from its computation to give it to
the message created afterwards during message_post.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
When using the mail composer in comment mode on models that do not inherit
from mail.thread, the post is transformed into notification process. Instead
of calling 'message_post' on the records (which would crash) 'message_notify'
is called, using MailThread as abstract class (which creates notifications
without having to inherit from mail.thread).
However some parameters from the composer are not supported when calling
'message_notify'. This commit fixes it and adds tests accordingly.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
This field will be used to remove low-level asserts using existence of
'message_post' on a given model instead of correctly checking the
inheritance on mail.thread.
This is going to increase a bit query counters but those queries should
be fast and have no real impact on performances.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
In some cases, a given user may create a message in behalf of other people.
This happens for example
* when calling message_notify to send notifications in a given flow, while
setting author_id to someone else (e.g. appointment flow who send invite
as notification, using the event responsible as author);
* when using templates with email_from set which may update the author_id
to match the email_from;
Notably with message_notify the current user may create a message he cannot
read afterwards, as he is not the author (as in 'author_id' field value)
and cannot read the message even with access on related record (as it is
a 'user_notification').
In this commit we relax a bit the 'read' rule on mail.message to allow reading
a message the user created.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
When posting a message, author is added in followers in order to receive
answers. They also do not receive its own messages, to avoid being notified
of something they just posted.
However the real author is not always the message author. In this commit
we better define this author
* when current user is active, real author is the current user. It means
posting on behalf of someone will send answers to you, not to the
spoofed partner;
* when current user is inactive, real author is the message author. An
inactive current user means the post was probably done as sudo, aka
in the mailgateway or frontend. In that case we don't want to add
odoobot in followers, but the actual message author;
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Currently notification process called notably by message_{post,notify} does
not notify message's author by default. Rationale is that as he typed the
message he is already aware of it.
However in some cases we want to skip this step, notably when messages are
generated in the name of the author and when we want him to be notified if
he should.
This is currently controllable through a context key 'mail_notify_author'.
In this commit we add an explicit parameter propagated through the notify
process, allowing to remove some context key usage and instead use real
parameters.
Note that all context keys usage cannot be removed as it is not always
possible to propagate this parameter.
Followup of odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Method 'message_notify' is a simplified version of 'message_post' to use
to notify people of something, without posting on a document. It creates
a "user notification", a specific kind of message.
In this commit we make 'message_notify' process attachments like posting
does. That way the API is more similar between those two methods. Moreover
it allows to give 'attachments' to notify. Those are then transformed into
real 'attachment_ids' and converted if they come from the composer.
That way the mail composer can be used in notification mode with attachments.
This happens notably when using a template on a record that does not inherit
from MailThread. It is a classic usage of 'message_notify' which allows
notifying on documents that have no chatter, notably technical or admin
oriented models.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Replace them by admin, which should globally be the same as employee. Testing
with system is a remaining of old times, when bichons were running freely in
the court.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Maximilien (malb)