Set report layout to DIN5008
Activate French language
Have a customer C with language set to French
Create a sale order to C
Print quotation
Some terms in the resulting document are left in english
As this layout is specific to some localizations (Germany, Switzerland &
Austria) we have the translation for the languages of these countries.
(German, French and Italian).
opw-3103361
opw-3089274
closesodoo/odoo#110120
X-original-commit: 85389ca353c6dcc0b639299628c7c24f08c3e26e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
- Install two languages;
- Install Accounting;
- Active 'Default Terms & Conditions';
- Select 'Add a Note';
- Click on the translate button;
- Answer 'Ok' when asking for saving the settings before modify the
translation;
- Save or Discard the translations;
- Save the settings.
Before this commit, a backtrace is raised. This issue raise because we
create twice the settings record. One before opening the translation and
the second time juste before saving the settings. This is a normal
behaviour in settings, as we consider the settings view as always new, a
new record is always created. But, only the last one should be sent to
the python code on the resId array.
opw-3109677
closesodoo/odoo#109803
X-original-commit: 5394f4c82829f8c7e6aaf73ddb1590f316f87ee3
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit fix the test when different localisation are used to make sure that the public pricelist is used.
Before, when pos_pricelist test was done and some localisation were installed, it could lead to test failure because the default pricelist wasn't correct on the partners.
closesodoo/odoo#109698
X-original-commit: 53e942fd84549a04af2f9257ec3e80633b4f59ea
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Before this commit, the size of the dragged row was shrunk during
the drag and drop. Now, columns have correct width and the layout
is preserved.
closesodoo/odoo#110193
Task: 2731998
X-original-commit: 27d17c3a9ea241d05b2ffc468094117012bc0a27
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Edit CRM -> Leads dashboard
- Edit filter "Period"
=> There is no period offset for the pivot 2, 4 and 6, despite the
fact that these pivots have a period offset defined in the json
data
This is because the field matching migration was not correct. It did
not take "offset" field into account.
Task-id 3138590
closesodoo/odoo#110221
X-original-commit: 2217c10ba771ece4a4d0d0485ce2f24b13754244
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Release notes: https://github.com/odoo/owl/releases/tag/v2.0.3
- fix: compiler: correctly escape backslashes when emitting block string
- fix: reactivity: don't subscribe to keys when making reactive
- fix: t-call-context: fix capture making component available in ctx
- fix: t-call-context: make `this` unavailable in rendering context
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
closesodoo/odoo#110196
Forward-port-of: odoo/odoo#109976
Forward-port-of: odoo/odoo#109788
Related: odoo/enterprise#35939
Signed-off-by: Géry Debongnie <ged@odoo.com>
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
Before this commit, the confirmation dialog was opened
only when the user clicked on an action button.
Now, the dialog is also shown when the user clicks a
menu item in the navbar.
Of course this dialog is shown only if the user has
changed a setting.
closesodoo/odoo#110194
Task: 3102800
X-original-commit: a180178bfd73d6e5f95ee5a9e9cdc1b0d64fc574
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- website settings, set "Display Product Prices" to "Tax Included";
- apply a tax A to a product;
- with Accounting app, create a fiscal position
which maps tax A to tax B;
- realize the ecommerce flow with a public user.
Issue:
We notice that the `/shop/product` page
does not have the correct fiscal position.
Cause:
We use the geoip in `/shop` but not in `/shop/product`.
opw-3078766
closesodoo/odoo#110197
X-original-commit: cb850a4ef8352a358b1c7d73a67e4e25ba0b4e38
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
We were trying to evaluate the domain of a date filter when no chain was
provided in the field matching instead of returning an undefined domain
like for the other types of filters.
Task 3114332
closesodoo/odoo#110131
X-original-commit: 6eddb4b684d5c233b650f86fd8b26dcb8af4ca2d
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
When posting an invoice to the fiscal device, the currency rate is
calculated from an invoice line by dividing its balance by the lines
subtotal. This is because the balance in the database will be in
KES (Kenyan shillings), whereas the currency on the line can differ.
From v16.0 onwards the way that a line is retrieved in order to
calculate the currency rate incorrect. When (for example) an invoice has
'Section' lines, then a division by zero is attempted (resulting in a
zero division error).
This commit amends the line so that the first line of the previously
assigned 'lines' variable is used instead. This variable contains only
valid invoice lines (non-zero, non-display type etc). It is already done
this way from v15.0 onwards (up to v16.0).
closesodoo/odoo#110210
X-original-commit: 4e0374fd095ea5e65e8ce311d133fca066e3ee6a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
. Change the decimal accuracy of the product price to 6
. Create a storable product and set the Vendor Tax
. Create a purchase order with that item.
. Set the unit price to have 6 decimal places. E.g: 9.406250
. Change the demand quantities to 10
. Confirm the purchase order.
. Edit the purchase order and change the demand quantities to 7 (<10)
. When you save, a new return order will be created
Bug:
Merging the two stock moves fail because the unit price is different
and the unit price is different because in the case of taxes we recompute
the unit price from untaxed amount which is rounded using the currency price_precision
Fix:
removed the unit_price from the keys used in matching which require an
exact equality and added a comparaison on the lowest precision
opw-3011342
closesodoo/odoo#110206
X-original-commit: f9ee1a22eb94e7ffcefd0023fc89150f8de73006
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce
* Create an analytic plan with the domain as `invoice`
* Create an analytic account for the above plan
* Create an analytic distribution model and include condition as account prefix (4000), and product.
* Create a sale order, confirm and create an invoice
Issue
During the conversion from the Sale Order to the Invoice, the
analytic plan is not applied
Cause
The analytic distribution is set even where there is none. Therefore,
the compute is not trigger
opw-3109003
closesodoo/odoo#110202
X-original-commit: fd5249ea8687f24e7c9c2a2a3bcbb8cc14333efd
Signed-off-by: William André (wan) <wan@odoo.com>
Previously in https://github.com/odoo/odoo/pull/88644/commits/a57be884ee625ab2d67b65f0ece0b8e9b1620369
we restricted the subcontractor locations (property_stock_subcontractor)
to locations with the new setting `is_subcontracting_location=True`. The
purpose of this new setting is primilarily to support the
mrp_subcontracting dropshipping use case though, therefore we want to
keep the previous freedom of allowing users to choose any location as a
subcontracting_location. There are some routing and filtering
errors/confusion that can occur if a user selects a location that isn't
marked as `is_subcontracting_location` (or sets this value to false
after already assigning it to a subcontractor), but since this has not
been reported as an issue in the past, we expect users to properly
configure these fields accordingly.
Part of general bugfix task: 2985735
closesodoo/odoo#110200
X-original-commit: d86df2b9cef742b6cadd294f57a855634768d039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
After the creation of a statement line, all involved amounts/currencies are available on the accounting entries.
After that, we don't need to perform any further conversion rate that could lead to inconsistencies since the currency rates could be updated multiple times a day.
This commit adds a new helper to retrieve such amounts from the accounting entries.
This method is only used from the enterprise edition.
closesodoo/odoo#110195
X-original-commit: f214fc319db12d69ee71e25336ef7b21aa9c2e3b
Related: odoo/enterprise#35938
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
For some unsure reason, a client had a non-null quick_edit_total_amount on a journal entry which resulted in a traceback.
The traceback appears because tax_totals is not defined for journal entries. However, the code should not have reached this statement. The first conditional statement of the method is not sufficient in such cases where the quick_edit_total_amount is not null, therefore we add another stronger condition on the quick_edit_mode too.
The only possible way I could reproduce this was by using Studio:
- Activate the Quick edit mode in Accounting
- Studio
- In the journal entry form view
- Remove the invisibility and readonly conditions of quick_edit_amount_total
- Fill in this quick amount
- Traceback
Ticket 3128200
closesodoo/odoo#110183
X-original-commit: 56e0a1e8fa5121408b0744531b5c5e5765c727aa
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
This reverts commit 15865cffb5 introduced
in odoo/odoo#93840.
This change was causing issues with applications received from job
boards (like LinkedIn), the same partner is assigned to the applicants
and changing the email address of one of those applicant was repercuted
on the partner and thus all the applicants.
closesodoo/odoo#110171
X-original-commit: 72c62dbf157dfb353caf13a228921e3f81036885
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since the migration to Bootstrap 5 (at [1]), the tooltip for the
background position overlay was no longer disposed when toggling the
overlay back on.
This meant that new tooltips kept being added and could lead to a very
confusing user interface.
This was fixed for legacy widgets at [2] but the tooltip for the overlay
is a specific case.
This commit makes disabling the overlay also dispose of the tooltip.
Steps to reproduce:
- Edit a website and drop a cover snippet
- Toggle the background position overlay (by clicking on the target
icon)
- Close the overlay (discard, save or click on the editor)
- Change the Parallax option from fixed to Top to Bottom (this is just
so that the previous tooltip is clearly visible after the next step)
- Toggle the background overlay again
=> The old tooltip is still present and a new one is visible
[1]: https://github.com/odoo/odoo/commit/1fcd098af5fa18e848c66bb83bdceb6ba0308512
[2]: https://github.com/odoo/odoo/commit/3c01b1cd77adec146b1a90f96bb1223a2108678b
task-3119958
closesodoo/odoo#110170
X-original-commit: 2ddffeef579baf47ff117b133a9d4fbf12108a2c
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit:
On removing link, all classes were removed including non-button link classes.
After this commit:
Only remove link related classes and remaining classes are preserved by
creating span.
Task-2930767
closesodoo/odoo#103602closesodoo/odoo#110169
X-original-commit: 0057b7983b5da42328187f42729b6648002fb2be
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit if you had a single course
and tried to open courses page on website, course
would stretch and fill in whole page.
it is tied to a bootstrap lib update. On bootstrap 4 col-xx-x has
max-width attribute and because of that it wasn't a problem before.
Now bootstrap 5 uses normal width attribute and flex-grow class
just ignores it.
This commit fixes that so that course behaves similar to how
it was in previous versions.
Task-3128895
closesodoo/odoo#110167
X-original-commit: 3171260cc1458e0789268c1425d332d4082743f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose of this task is to cleanup usage of main mail.thread post methods and
helpers as well as composer usage and code. Achieve this by removing or
cleaning deprecated code, simplifying flow / API, improving composer support
of templates, rewrite composer code, ease batch support.
In this task we notably
* cleanup input / output as well as default values for message_post as well
as 'with view' and 'with template' helpers. Those are now cleaned and
two main helpers are introduced: post with source (view or template)
and mail with source (view or template), depending on main notification
style.
* rewrite and improve template code generating values from the template
definition. It is now cleaner, delegated into sub methods and made
more efficient in batch mode, notably when computing or creating
recipients;
* rewrite and improve composer code generating values for either posting
either sending a mass mailing. It is now better separated into a static
rendering and a dynamic rendering;
* supports a batch post on documents, instead of being limited to a single
res_id and improve overall code to be batch-enabled;
* support scheduled_date from template;
* support multi reports templates;
* perform various code cleaning, rewriting in order to achieve both a more
readable code, easier to override and understand as well as better tested
and documented;
* cleanup configuration of composer. Use fields, better define and update
their value. Don't add them in UI but allow more fine-grain usage, notably
when invoked in code;
METHODOLOGY NOTE
Several points are linked to different tasks. A big PR containing a cleaning
and some improvements in the composer behavior, usage and definition allowed
to ease testing and review.
This PR is build on previously merged content that originated form this PR.
See notably (but not limited to)
* account, mail, sale: properly locate code
Task-2792146 - odoo/odoo#106658
* various: cleanup alias usage and empty list help overrides
Task-3074358 - odoo/odoo#105992
* clean parameters propagation in post methods
Task-2726501 - odoo/odoo#82167
* rating send request api cleanup
odoo/odoo#106024
* empty list help cleanup
Task-3074357 - odoo/odoo#105992
* rendering mixin options and usage cleanup
odoo/odoo#106072
* improve exclusion list mail logging
odoo/odoo#106568
* linting and cleaning
odoo/odoo#106025
Next step will be to improve composer fields to be editable computed fields
and remove the onchange and hard-to-predict code. Translation support will
also be improved, as well as some performance bits.
LINKS
Task-2710804 (Mail: Clean MailThread API)
Task-2993872 (Mail: Support scheduled date in all composer flows)
Task-3035101 (Mail: Support batch-posting from composer)
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Task-2868153 (Mail: Allow multi-reports mail templates)
Task-3132710 (Mail: Configurable composer)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#99482
Related: odoo/upgrade#3856
Related: odoo/enterprise#31017
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Update counters now that all changes in this PR are validated.
Main observations
* batch mode is improved: few tests effectively run on a real batch of
records but in those use cases there are more gains due to better batch
management of values rendering and recipients management;
* posting using a view does not call the composer anymore in all situations
allowing to gain a lot of queries by not creating a composer and calling
a dummy onchange on it;
* various small gains in various tests, notably linked to usage of low-level
reference fetch and various small code tweaks;
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#99482
Currently when using the composer excluded emails are computed when the target
model inherits from the blacklist mixin. This behavior can now be deactivated
through a new field 'use_exclusion_list', like what has been done in SMS
composer.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
Currently when using the composer to create a mass mailing emails are sent
directly, unless scheduled date is in the future.
With this commit it is now controllable through a field like what has been
done on SMS composer. Its default behavior is the same as before
* posting on a monorecord: force send notification emails;
* posting on multirecords: use the queue (force_send=False parameter given
to message_post and propagated to _notify_thread);
* mass mailing: use force send to send emails directly;
Usage of mail_notify_force_send context key is also removed when possible
as it is a standard parameter of posting API.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Correctly update 'auto_delete' field
* add missing update in onchange, to either take value from template, either
fallback on default_get values as other fields;
* in comment mode, actual value for 'auto_delete' is True by default. Composer
value was not used and bypassed by a context value being True by default.
Context key support is removed, correctly replaced by the composer field
value itself;
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
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
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Remove 'is_log' field on mail composer. Indeed its usage can be globally
replaced by using the 'note' subtype when posting. It is now better matching
the result of using the log a note mode of chatter.
Posting with a False subtype_id already automatically converts it into a
note subtype in 'message_post'. It is now done directly at composer level
to lessen magic and have more control on final output.
In case of outgoing emails subtype has no usage, as notification process is
not called. It is therefore forced to False when creating the mail records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Purpose of this task is to correctly support scheduled_date from template on
both comment and mass mode in the composer.
It is currently mainly supported at template level, when using a template
to directly send emails. In this commit we add a field on composer that
takes the value from the template, and propagate it to the mail or messages
created when validating it.
As most template fields it can contain inline template code to be rendered
dynamically on target records, hence using a char field. Its rendering
is done using template that calls _parse_scheduled_datetime. It allows
to have an UTC and timezone agnostic value.
SCHEDULED_DATE SUPPORT
When posting a comment, scheduled posts uses the 'mail.message.schedule'
mechanism that creates the message but send notifications later.
When sending a mailing, emails have a scheduled_date set. As the 'send'
method does not check for scheduled_date (only the cron queue) we have
to filter emails scheduled in the future before calling the 'send'
method.
Task-2993872 (Mail: Support scheduled date in all composer flows)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Use the new 'res_domain_user_id' field to use in combination to 'res_domain'
on composer to delegate res_ids computation to the composer instead of relying
on res_ids or active_ids. Records to mail are not stored inside a domain.
Set auto_delete values directly when invoking the composer instead of hacking
the generate mail values. That way we delegate more to the composer itself.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Remove deprecated "mass_post" option from composer. It is either a comment
(using message_post) either a mass mail (creating emails). Mass post was
anyway nor used nor really supported. It will be replaced by supporting
having a comment on several IDs (batch comment mode, posting a message
on several records instead of being limited to one as currently).
This cleaning also allows to remove the 'notify' field that was an option
used for mass_post. All this should be supported through subtypes and
correct choice of post / mass mailing.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
When trying to use the composer without related records in comment mode
message_post raises, as record is mandatory (ensure_one). In this commit
we make this raise explicit in the composer itself, in order to be able
to assert the behavior.
In mass mail mode, having no record to mail is possible and the composer
simply skips the mail creation. Indeed when doing mass mailing, notably
with crons, records might have been updated / removed and the composer
should not crash, just produce nothing.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to cleanup context usage in composer
* remove now dead 'custom_layout' context keys that was present mainly for
compatibility until Odoo v15. You should now correctly use default value
for 'email_layout_xmlid' field like every field;
* remove 'mail_auto_delete' context key, not used anywhere in codebase.
Auto-delete field of composer will be improved soon so that setting it
as every field will replace the context usage;
* remove usage of self._context, to use self.env.context;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Purpose is to rewrite value generation as code is messy with a lot of dict
updates, rewriting key on top of existing keys until reaching the final value.
In this commit we better split computation, to have computation that is static
(currently, posting a comment as composer holds final code) separated from
dynamic computation (posting a mass mailing, as rendering is done based on
qweb or inline template value).
It allows to better understand how composer and template fields are used when
sending emails or posting messages. This commit should not change anything
functionally, even if some values are weirdly computed. Future commits will
improve support of composer / template fields, notably through computed field
and less cross computation.
Also split sending methods: do a mailing in batch in case of mass mailing
(allowing commit per batch), and simply loop on records to post a message
in case of comment (or mass post).
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Now that template generation methods have been cleaned we can cleanup calls
done in composer. We notably
* make methods private, improve their naming and docstrings;
* better support input / output of asked fields;
* be more coherent with composer fields and template fields usage;
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Composer Onchange to Editable Computed Stored)
Part-of: odoo/odoo#99482
Purpose is to ease understanding of those default values and prepare move
towards editable stored computed fields by rewriting a bit the code to better
understand its purpose.
While being at it, some tests introduced recently are moved at their right
place now that everything is ready to rewrite the posting API and the
composer. Some tests are added to ensure notification-specific methods are
called along with the newly-introduced '_message_compute_subject', aka methods
to add custom header and custom mail values.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in compo
Part-of: odoo/odoo#99482
Purpose of this commit is to move methods to better prepare future changes.
Currently onchange code, value generation and tools for email management
are mixed, which leads to the file being quite messy.
Separate methods generating mail or message values, from methods doing
data marshmalling.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When computing recipients based on template we generally create new partners
based on emails. This is due to the mail framework managing mainly partners
and not low level emails.
This code is currently sequential: fetching or creating partners one by one
based on found emails, for each record. This is highly inefficient when
sending emails on a lot of records based on templates.
Purpose of this commit is to improve code and performances by batching. We
do queries in batch: one search for all records, create partner in batch. This
leads to code being a bit more complicated to correctly remember and dispatch
again emails and partners to the correct records.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract fields generation on template for fields
not belonging to recipients or attachments in sub-methods. Code is cleaned to
better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
First sub method is dedicated to 'scheduled_date' which is dynamic and has its
own post processing (to be UTC agnostic as expected by ORM). Second one is
dedicated to static values coming directly from template without rendering.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract attachments generation on template in
its own sub-method. As it contains code specific to attachments, better
have it separated from the main global generation method. Code is cleaned
to better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to improve recipients generation on template.
Code is cleaned to better support parameters and be easier to call. It
can now be called independently from the main ``_generate_template``
method. Docstrings are updated.
Changes
* removed support of ``tpl_force_default_to`` context key used to somehow
simulate the check of "use default recipients" (??)
* removed support of ``tpl_partners_only`` context key used to force to
find or create partners based on emails generated by the template. It
is replaced by a parameter to propagate;
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Currently some value are always computed and added even if not asked by the
caller. As asking a template to render some fields is now used notably for
a subset of fields (subject and body, from / to, ...) there is no need to
automatically add other irrelevant information.
Main callers already filtered out returned results (notably composer). However
better avoid computing / rendering unnecessary stuff directly at template
level.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to prepare further improvements in template and
composer rendering methods. First step is to
* make them private;
* correctly name parameters (notably rename fields to render_fields to avoid
collision with odoo.fields);
* remove the "single / multi" mode. This is a relic of old implementation
when rendering was done mainly record by record and sometimes by batch.
Now everything should be batched;
* split some lines to ease future diff in upcoming commits;
* improve some docstrings;
Next commits will rewrite and split parts of ``_generate_email``.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
'email_from' fields are not necessary on 'sale.order.cancel' and 'survey.invite'
as anyway we always use the current user's email and field is not present in
form view. Override of default_get to raise about invalid email_from is not
necessary as anyway it raises when posting the message. Giving author_id to
message_post is sufficient as it computes email_from based on author when given.
Add 'render_model' in views, as it is part of the domain given to 'template_id'
field of composer mixin. When missing, also add 'lang' and 'template_id' that
come from the render mixin.
Use '_render_field' when possible instead of '_render_template' as its API
is simpler and uses field definition for rendering parameters.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
A method ``_message_set_main_attachment_id`` exists to handle main attachment
reference, used notably in discuss and accounting. It is now called inside
``_message_post_after_hook``, so that it is part of the post processing after
having posted the message. Its API has been updated so that attachment_ids is
now a real list of ids, which is clearer.
A wrong override of '_message_post_after_hook' dealing with parameters is
cleaned while passing by.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Notification method 'message_notify' is sometimes used as a standalone method
to send notifications. In that case it is called directly on MailThread
abstract model, notably when there is no context record or when it does not
inherit from 'mail.thread' directly. This is done mostly in technical models.
However in that case some model-specific code is not called, notably methods
computing default subject. In this commit we improve some calls to be sure
notifications have content enough to be understandable.
When possible, we also redirect the notification method on real records
inheriting from mail.thread, enabling a more complete process.
See community PR for more details.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Andrea Grazioso (agr-odoo)