Prior to this, there was no way of knowing when a new device logged
into your personnal account.
Adding the new version of the authenticate function, user's will now
automaticly receive a mail containing informations on a new connection
made to their account. This system uses a mail template sent
automaticly on a new connection if the user has activated 2FA and if
his device his not in the trusted devices of his account.
task-3191567
closesodoo/odoo#115362
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit escape was needed to use a Markup object as a
parameter, hence loosing the fallback mechanism in translations
>>> escape(_("Order %s has been confirmed")) % Markup("<a>%s</a>") % order.name
Markup("Order <a>SO42</a> has been confirmed")
Now it is possible to explictly give a Markup object to the gettext call
>>> _("Order %s has been confirmed", Markup("<a>%s</a>") % order.name)
Markup("Order <a>SO42</a> has been confirmed")
Part-of: odoo/odoo#139316
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Now that alias domains are used in Odoo codebase there is no usage anymore
for the old config parameters. So long and thanks for all the fish !
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
This may have an impact when trying to find an outgoing mail server based
on from and filter, as first match wins when checking matching filter on a
bunch of mail servers.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Due to current implementation of mocks context is lost when accessing methods
'connect' and '_find_mail_server' of IrMailServer. Indeed self is replaced by
an instance of IrMailServer and code relying on context could not be called as
planned.
This commit aims at doing a custom mock so that we can correctly rely on self
and context in those methods. This is necessary for incoming changes in mail
notably to allow testing SMTP feature in multi domains environment.
Logged information when having failed SMTP check is improved: we now also
log found From in order to ease debugging failing tests due to invalid from.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
When a company is created and then archieved there will be
tracebacks upon acessing res.companies records because the company
is not active and in _compute_parent_ids at company.parent_ids[0]
an empty recordset will be returned since the company is inactive
With (active_text=True) the company is returned in the recordset
even being inactive.
opw-3565757
closesodoo/odoo#139527
X-original-commit: b15975739810fe0c94ae5965cef3038ac54a58ba
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
png images not shown on ir.attachment kanban
Attachment that use db_datas have no checksum by default, which is used
to compute the stream's http ETag. Skip updating the ETag when it is
missing and determine freshness using the Last-Modified header instead.
closesodoo/odoo#139498
X-original-commit: 2d43bbae72fddf17e7d9045e90dbc070b2f57a19
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Currently, bulk-importing translations for non-module loaded data is hard
1. PO file import works fine, but exporting a PO template for non-module loaded
data is near impossible (since PO exports will only export entire modules)
2. Import of translated values during csv/excel file import is not supported
This commit fix the issue by improve 1 which reuses the translation export
wizard for modules to export translations for non-module records. So that user
can export translations for selected records with a domain and import the po
file after translating
[DEBUG MODE] Settings -> Translations -> Export translations -> Export Type
("model") -> Select `Model to Export` and `Model Domain` -> Export
The framework will
1. create external ids for records without external ids
2. export translations for stored translated and inherited translated fields
closesodoo/odoo#138531
Task: 3463505
Signed-off-by: Raphael Collet <rco@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Significantly improves the usability and the result of the populate for
base models and channel/member/message.
- make populate of base models re-entrant
- adapt size to values that make sense:
- small shows something relevant, and can be quickly ran several times
- medium is fast enough to be usuable but big enough to highlight
performance issues
- large is... still not to be attempted
- avoid conflicting conditions that either make no sense or can lead to
crashes when populating the data or running the database
- better spread of data in channel/member/messages
closesodoo/odoo#139269
X-original-commit: 73a5e322f6e250569ee1942d678f8a4f87616bd7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose:
--------
The "KanbanPropertiesField" has been renamed to "CardPropertiesField".
For consistency, the key "view_in_kanban" of the properties definition
is renamed to "view_in_cards"
Task-3458627
Part-of: odoo/odoo#132578
The new method should be used to generate an SQL object that represents
how to order by a field in an SQL query. We introduced the auxiliary
method _order_field_to_sql() so that one can specify some SQL for
ordering by a given field with a simple method override.
Part-of: odoo/odoo#138019
We take advantage of SQL objects to discard the use of domain operators
'inselect and 'not inselect'. Indeed, as we now support SQL objects at
the right-hand side of a condition, one can replace conditions like
(lhs, 'inselect', (query, params)) by (lhs, 'in', SQL(query, *params)).
This commit also adds tests that ensure the correct behavior of the
adaptation of the implementation.
Part-of: odoo/odoo#138019
The new method should be used to generate an SQL object that represents
the value of a field in an SQL query. Later this method will add
metadata to SQL objects, and that metadata will be used to determine
which fields to flush before executing some SQL code.
Part-of: odoo/odoo#138019
For very large bits of SQL code with potentially repeated terms, it is
useful to use named parameters instead of positional parameters:
sql = SQL(
"SELECT %(column)s FROM %(table)s WHERE %(column)s IS NOT NULL",
table=SQL.identifier("foo"),
column=SQL.identifier("foo", "bar"),
)
Part-of: odoo/odoo#138019
This commit improves the general feel when creating or displaying base automations
The improvement relies mainly on correctly labelling the fields
task-id-3450200
closesodoo/odoo#135932
Related: odoo/enterprise#47609
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The first intention of this commit was to remove ´@extend´ but
it actually makes sense to remove ´.oe_left´ and ´.oe_right´ classes.
Since grid we can avoid "float" elements (see .oe_subtotal_footer)
and we only have to remove this class.
For the other case, we have to use ´.float-start' and ´float-end´
to replace ´oe_left´ and ´oe_right´.
closesodoo/odoo#139199
Related: odoo/enterprise#49211
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The current used version of wkhtmltopdf manages is frozen to 0.12.5
because some features used by odoo are only available in this version
using a patched qt.
Anyway, it become difficult to keep this version up to date, especially
with Ubuntu Jammy and updates of the dependencies used by wkhtmltopdf.
More than that because of qt related issues, wkhtmltopdf maintenance
will end soon.
Adding a test to check some caracteristics of pdf reports may be usefull
to check that current version is still working, and eventually to find
an alternative solution.
This test checks that pdf reports contains the expected headers and
footers elements with the correct page number (2 record of 2 pages)
This also check that the pdf is in the expected A4 format.
Future test may check other formats, margins, layout,
page size/pagebreak combination, (table of content?), ...
This test may also check performances and existing limitations.
closesodoo/odoo#136626
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In the context of branches, you need to be able to select taxes of
an ancestor company on an invoice/bill, even when you don't have access
to the ancestor company.
In order to do that, we relax the restriction when searching with a
`parent_of` or `child_of` on a related field, so that it also includes
ids of related field records you don't have access to. This should not
be a problem, since in the end the search will return records of a
model restricted by its own access rules.
task-3503204
closesodoo/odoo#138942
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Once a branch company has some data associated with it, it can't be
deleted anymore. Since the branches could only be opened in a dialog,
it was also impossible to archive them.
In order to allow (un)archiving a branch, we added a stat button on the
company form to show the branches in a list view, where people can
(un)archive them.
task-3503204
Part-of: odoo/odoo#138942
Following 116879e17e81657f48a7d11780d8d30715ecc68f a few improvements were needed to make it more
complete.
task-3484125
closesodoo/odoo#137522
Related: odoo/enterprise#48563
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the status bar field could be displayed in 2 ways:
- in small screens: as a dropdown
- in larger screens: as an inline list of buttons
This commit centralizes both of these approaches into a dynamic display
that fits the available space:
- the current stage is always displayed;
- previous stages are displayed behind or contained in a dropdown if not
enough space;
- next stages are displayed behind or contained in a dropdown if not
enough space.
Task 3336856
closesodoo/odoo#124267
Related: odoo/enterprise#48706
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
To avoid developers to update the dict of `_events`
in their overrides, to not alter by mistake
the default behavior.
Using a frozendict will force them to create a copy
of the dict.
closesodoo/odoo#123261
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This commit is a preparation for the new page from template feature.
In order to make it possible for new page templates to be customizable
at several levels from themes, it was decided to create several layers
of primary templates.
Those templates are build from the descriptions found in manifest files
under the new `new_page_templates` key.
The same principle is also applied for configurator pages (described in
manifest files under the `snippet_lists` key) because we noticed that
some of the changes that were made in themes for some blocks were not
supposed to impact the "drag'n'drop" version of the block, but only
the version used inside the pages generated by the configurator. (E.g.
connecting shapes between blocks)
The manifest entries now have the following structure:
```py
'snippet_lists': {
'somepagename': ['s_block_name', ...],
},
'new_template_pages': {
'somecategoryname': {
'sometemplatename': ['s_block_name', ...],
},
},
```
This commit finds those entries in the manifests and creates the
following primary templates:
- `s_block_name`: already exists, this is the block that is drag and
dropped using the website builder
- `configurator_s_block_name`: specialization of `s_block_name` used in
all pages generated by the configurator
- `configurator_somepagename_s_block_name`: specialization of
`configurator_s_block_name` for that specific page
- `new_page_template_s_block_name`: specialization of `s_block_name`
used in all new page templates
- `new_page_template_somecategoryname_s_block_name`: specialization of
`new_page_template_s_block_name` used in new page templates of that
specific category
- `new_page_template_somecategoryname_sometemplatename_s_block_name`:
specialization of `new_page_template_somecategoryname_s_block_name` for
that specific template
For the template pages defined in `website` it also creates primary
templates that assemble `t-snippet-call`s of the most specific block
templates. Those templates are named
`new_page_template_sections_somecategoryname_sometemplatename`.
task-3381714
Part-of: odoo/odoo#126719
The issue with the t-cache (discribeds with a test in previous commit)
is that the key/value can be anything. It can be based on other t-cache
(assets in the example) but could be anything else.
The proposed solution will clear the t-cache when ANY other cache is
cleared. This is similar to the behaviour when the t-cache was
introduced (single ormcache)
Also sligly improve logging to precise what was cleared
closesodoo/odoo#138647
X-original-commit: aa69fa9f8efed0da45c601e5d57ce252446e376f
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
State code is shown instead of state name
in company details for Thailand companies.
opw-3493307
closesodoo/odoo#138576
X-original-commit: 6a47980364e4ceeb5a77b4f7e2f2a9475872275e
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Test HTML being inserted for the utils tests was not cleaned at the end
of the tests.
X-original-commit: 092cee52b343665ea3ca90e4f4aa302318a763b5
Part-of: odoo/odoo#138549
Prior to this commit, lazy-loaded bundles weren't pregenerated,
potentially causing non-deterministic test failures when the
generation process took too long. Plus, each Python test loading these
bundles necessitated their regeneration.
With this commit, the lazy-loaded bundles are now included in the
pregenerated bundles.
task-3493014
runbot-24842
closesodoo/odoo#134464
Related: odoo/enterprise#46985
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
before this commit, if profiling is enabled in the db,
and on trying to validate a sale order, a traceback is
shown
* enable profiling
* confirm a quotation
traceback:
Failed to render QWeb template : <div style="margin: 0px;
padding: 0px;">
<p style="margin: 0px; padding: 0px; font-size: 13px;">
introduced in: https://github.com/odoo/odoo/commit/016f26a9315c693bdeb894725898c2cf725d8989
here the options['ref'] is coming as the email template
body and it is failing on try to do int of options['ref']
after this commit, no traceback wont be shown on
confirming sale order, when profiling is enabled
closesodoo/odoo#138357
X-original-commit: 01548aff72b031389a7563948bb12bc3abb07bfc
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This commit renames calendar's attribute quick_add to quick_create
to be more consistent with other views.
closesodoo/odoo#138042
Related: odoo/enterprise#48677
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the PR [1], quick_add can be both a boolean and an id:
0 = without quick create
1 = with quick create and simple dialog
other number = with quick create and custom form view dialog
This is not great to have both behavior in a same attribute so this
commit split them back in two attributes as it was before [1].
It's easier to understand when we want a quick create and which view
to use in the dialog.
[1]: https://github.com/odoo/odoo/pull/122923
Part-of: odoo/odoo#138042
The summary is a short char field. It should not contain carriage
returns.
The description is the longer text field.
Remove unnecessary spaces in both.
Automatically dedent the description to avoid this issue poping up
again in future modules.
closesodoo/odoo#138214
Related: odoo/enterprise#48695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Purpose of this commit is to try to detect and log 'email_from' invalid
values when sending emails based on outgoing 'mail.mail'. This implies
checking the returned messages when having a generic Exception when sending
the emails, as we distinguish two use cases that raise through a simple
raise: missing from and invalid from.
New failure types 'mail_from_missing' and 'mail_from_invalid' are also
added at 'mail.notification' and 'mailing.trace' level, as other failure
types.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#138202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This reverts commit 4573ca0c83eb63785016f4389a5157efb21fa9a4.
Because now, `display_name` is implicitly on every form (last breadcrumb
item). Then it will be queried by `onchange` calls. When we create a
new record, `_rec_name` can be `False` and the display_name will be a
technical one: '<model_name>,<NewId0x...>' which is uglier than the
previous situation showing 'New'.
Part-of: odoo/odoo#138061
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
Thomas (thbe)