Since 16.0's 0501bbd62e fields with groups are now removed from the view
instead of being set as invisible.
Scenario:
- template user has group "Access to export feature"
- create a new user while being in debug=0 mode
- save
=> the users don't have the group "Access to export feature" set,
because the corresponding field is not in the view. If the same scenario
was done in debug=1 mode, we would get the group set.
Solution: duplicate the field that are inside base.group_no_one section
and have them be invisible if someone is not in debug mode.
note: before the fix, added assert fails because there is missing groups
in the newly created user.
closesodoo/odoo#121097
Note: issue observed when working on another ticket
X-original-commit: 9deb1e6aa902a09c4fd6a91ecbd34a89b9c98f98
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
before this commit:
after #109858
The method `update_field_translations` won't directly call the `write`
As a result, when changing the translation of fields from translation dialog,
the orm cache won't be cleared, and translations won't be updated in views
even after refresh the page
after this commit:
when users translate fields and refresh the page, the new translation can be
updated in new views
opw-3267024
closesodoo/odoo#120602
X-original-commit: 8d8dbab203fe7c153522dcb2a420d97dc4adaadb
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
This test will help making stats on routing_map generation performances
This will help to mesure the time for the main `None` routing map as
well as for website1, the idea being that it would be possible to
mutualize a part of this computation between routing maps.
closesodoo/odoo#120591
X-original-commit: 6646fa7e2ef64e5f060bf38b0d85bf1188d79e4f
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit if a computed field is already in cache, but not its
dependencies, `fetch` would fetch those dependencies.
This commit ensures that fetch checks first if a computed is in cache
before fetching its dependencies.
This commit also follows dependencies of computed fields, if they depend
on other computed fields.
Finally, this commit consolidates `fetch` and `search_fetch`:
they should use the same heuristics to know which fields to fetch.
closesodoo/odoo#120001
X-original-commit: 6b680c463956f929db10d4c3058c36112a67e674
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
*: web + adaptations in base, fleet, hr, hr_expense, hr_recruitment,
loyalty, lunch, mail, mass_mailing, note, project, stock, survey,
web_tour
**Foreword**
Since d19037e141 the rootnode class attribute for form/list views was
copied two times:
- on the o_view_controller div
- and on the root node of the view renderer.
Examples:
<form class="foo">...</form>
gives
<div class="o_view_controller o_form_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="foo o_form_editable ...">...</div>
</div>
</div>
and
<list class="foo">...</list>
gives
<div class="o_view_controller o_list_view foo">
<div class="o_control_panel">...</div>
<div class="o_content">
<div class="o_list_renderer foo ...">...</div>
</div>
</div>
**Issue**
This could lead to confusion and also unexpected styling issues.
See this PR #119815 to read a message JS Framework team has received.
See also another a fix that had to be made for x2m fields: 980244fa8
**Introduced Changes**
- in the form compiler, the root node attributes are no more copied to
the root div node of the compiled template the form renderer receives
- the root div node generated by the form compiler now has the
"o_form_renderer" class, which was removed during the recent form view
refactoring.
- the list renderer no more adds the root node class attribute to its
"o_list_renderer" div
- the X2ManyFieldDialog has been adapted too
- since View, X2ManyField & X2ManyFieldDialog both need to compute view
classnames derivated from the arch root node, an util has been
introduced to avoid duplicating code
- the whole codebase has been checked and adapted.
Related: odoo/enterprise#40418
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
As ir_cron_trigger are only processed for active crons, we should
not create them for inactive crons to avoid bloating the table.
Account_edi tests needed to be adapted to make sure the cron
ir_cron_edi_network is set up as active during the tests.
Backport e79b1a7: ([IMP] base: Garbage collect ir.cron.triggers)
closesodoo/odoo#118844
X-original-commit: a62275430e21f9e7e510913ac9afb25943da525b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
This commit add a new `odoo.osv.expression.prettify_domain` function
that can be used to format a domain as a string with the correct
indentation.
Example:
['&', '|', ('name', 'like', 'Jack'), ('name', 'like', "O'Neill"),
('function', '=', 'Colonel')]
Becomes:
['&',
'|',
('name', 'like', 'Jack'),
('name', 'like', "O'Neill"),
('function', '=', 'Colonel')]
closesodoo/odoo#118067
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Rationale
---------
Given the following domain:
['|',
('company_id.name', 'like', 'BE'),
('company_id.city', 'like', 'Brussels')]
The ORM would generate the following SQL query:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."name" like 'BE'
) OR "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company"
WHERE "res_company"."email" like 'help@odoo.com'
);
Which is sub-optiomal as the WHERE clause of the two subqueries could be
regrouped inside of a single query like so:
SELECT "res_partner"."id"
FROM "res_partner"
WHERE "res_partner"."company_id" IN (
SELECT "res_company"."id"
FROM "res_company" WHERE (
"res_company"."name" like 'BE'
OR "res_company"."email" like 'help@odoo.com'
)
);
Postgres-wise, it is faster to execute the latter query than the former
one. This commit is about optimizing the ORM so that it generates
queries where the WHERE clause of compatible subqueries are grouped
together.
Technical solution
------------------
The solution explored by this work is to replace the regular relational
field accesses (over a dotted path) by a new `any` operator that look as
follow:
(relational_field, 'any', domain)
For instance, the above `('company_id.name', 'like', 'BE')` leaf becomes
`('company_id', 'any', [('name', 'like', 'BE')]` using `any`.
Having a domain as right-hand-side allow for the combination of the
domains of same compatible relations:
[('company_id', 'any', ['|',
('name', 'like', 'BE'),
('city', 'like', 'Brussels')])
Having combined domains allows for generating better SQL queries with
minimal changes to the expression parsing algorithm, which can only
translate a single leaf at a time to SQL. With the new `any` operator,
it is still a single leaf but the right-hand-side contains the merged
domain, thus the combined SQL WHERE clause is immediately generated.
task-id-3234671
Part-of: odoo/odoo#118067
Co-authored-by: Raphaël Collet <rco@odoo.com>
This commit hads a few tests that report the existing behavior (before
merging subqueries WHERE clauses).
task-id-3234671
Part-of: odoo/odoo#118067
Co-authored-by: Raphaël Collet <rco@odoo.com>
a new context `prefetch_langs=True` allows ORM to prefetch all translations of
translated fields while fetching.
For example
The activated languages are 'fr_FR' and 'nl_NL'
In the database the value is '{"en_US": "English", "fr_FR": "French"}'::jsonb
after fetch with `prefetch_langs=True` the raw cache value will become
{'en_US': 'English', 'fr_FR': 'French', 'nl_NL': 'English'}
closesodoo/odoo#116947
Signed-off-by: Raphael Collet <rco@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
__Current behavior before PR:__
The size of an image field is guessed using the field name. For instance, an image field with `field_name = "XXXX_123"` is resized to 123 pixels when fetched.
This is can be an issue if a user creates an image field using studio in a form view.
If the user sets the label of the field as "Image 1", the technical name will become `x_studio_image_1`. Therefore, the image field will be resized to 1 pixel width.
__Description of the fix:__
Refactor the `image_guess_size_from_field_name` method to return `(0, 0)` when the field name starts with `x_studio_`.
__Steps to reproduce the issue:__
1. Open a form view (of any model)
2. Open studio
3. Add an image field with label "Image 1" (notice the technical name becomes in `x_studio_image_1` in debug mode)
4. Close studio
5. Upload an image on the created field
6. Save... The image is resized to 1 pixel width
opw-3242084
opw-3249632
opw-3253133
closesodoo/odoo#118960
X-original-commit: 3318f0e67da40983f52595aba933d8c8fd0f5cc5
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Many templates use the company logo that is set by default on
database creation. As that logo is clearly a placeholder and the user
isn't necesserely prompted to update it. It's possible for a user to
inadvertently start sending emails with "your logo" placeholders
plastered all over.
This removes the default logo of the company and removes it from
templates conditionally.
The logo isn't simply replaced with a transparent PNG as the templates
set a fixed height for the logo, which would look weird.
task-3067315
Part-of: odoo/odoo#106307
before this commit:
record = env['model.name'].browse(id)
if record doesn't exist in the database and call
record.translated_field_name = value
Then _get_stored_translation will raise
TypeError: 'NoneType' object is not subscriptable
after this commit:
like write non-translated field, the value can be written to the cache, but not
the database and no error will be raised.
Note: The feature is only for the original ORM 'write', if the 'overriden write'
reads other fields of the non-existing record, a MissingError will be raised.
closesodoo/odoo#119202
X-original-commit: 3ba7ca28a68acccb8eb25f117900c1aa1980264a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
The `_read_group` was designed to be used by the web client to
efficiently compute aggregations grouped by one or more fields.
However, more and more developers have been using it from the backend
to make computations more efficient (avoid doing the aggregation
in Python). Unfortunately, the API was designed for the web client,
which added a lot of boilerplate when used in the Python (list of
dict with misleading key name choices).
`_read_group` was created to improve the performance of read_group
for backend use (4ef0c00b4b), but didn't
change the API and based the implementation on read_group itself.
Rewrite `_read_group` from scratch with a new API to make it easier
to use from the backend (see the method documentation). Also, split
the method to make it easy to override and add custom behavior.
Part-of: odoo/odoo#110737
Making a test post_install using @tagged should always remove the
at_install tag.
The main reason for that is that runbot split config select if an
at_install or post_install tests should be executed is using negation:
`--test-tags -post_install`. The reason for that is that giving a positive tag will
replace the "standard" tag and non standard tag could be executed if
giving `--test-tags at_install` (without negation)
Since runbot tests in parallel builds, one of them using
`--test-tags -post_install` and the other `--test-tags -at_install`,
a test that is both post install and at install wont be executed at all.
Also, a tests with both tags will be executed twice
in a normal flow, usually not intended.
The correct way to make a test post_install is to use
@tagged('post_install', '-at_install')
closesodoo/odoo#118969
X-original-commit: d1db306b212d4abb5b2faab9e56c8e83b85c53b9
Related: odoo/enterprise#39966
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Precommit hooks would stock data until a call to ``cr.flush`` was made.
Notably, this happens when the ``assertRaises`` method is called.
Functions were applied on records already cleared from the cache.
This change adds a cleanup call for `TransactionCase` as it keeps
the same cursor for all tests. Cursor precommits can now
be safely executed inside tests.
Task-2834304
Forward port of #117555closesodoo/odoo#118290
X-original-commit: ff5d0c75fcea5842c5236b1b3f7480ef5a3dc415
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
The co-model field in `IrField` view is accepting Related Model name
even if it is invalid. And replaces the invalid model name with `_unknown`.
This causes KeyError `display_name` when trying to create or read a record.
To fix that we are adding Validations for the Related Model field when it gets
updated from UI side.
sentry-3933471439
closesodoo/odoo#118052
X-original-commit: e4f7798fd5a5cccd5d385f535fbc21264cb6948b
Signed-off-by: Rémy Voet <ryv@odoo.com>
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
Steps to reproduce the bug:
Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)
1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.
Bug:
The VAT of C = VAT of A, however VAT of D did not change.
When syncing the commercial fields of a partner, we also sync his childs.
PS: Due to function _compute_commercial_partner, the commercial partner is always updated for
all the childs.
So the condition child.commercial_partner_id != self.commercial_partner_id
is never satisfied in function _children_sync and the commercial fields were
never updated.
opw:3111493
closesodoo/odoo#115932
X-original-commit: df87448f2a39eead079cffea566cd760a8918542
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: kmagusiak <>
Bug
===
When the from_filter of an outgoing mail server contains a domain
(e.g. company.com), and when the system parameter "mail.default.from"
is a full email address, with a different domain name
(e.g. notification@example.com) we concatenate both value which produce
an invalid email (e.g. notification@example.com@company.com).
Instead, we always give the priority to the from_filter, and fallback
on "noreply" for the local part when needed.
Task-3230917
closesodoo/odoo#115890
X-original-commit: bf02481de9932de2e0246ac36fcf59f37a89b511
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Improve the portal user deletion by preventing timeouts and
avoiding several rollbacks causes.
Specifications
==============
- Move the portal users deletions from autovacuum to its own cron.
On big databases such as odoo.com, deleting a res.users takes
more than 1 minute. Move the whole process into its own scheduled
tasks.
- Commit the deletion at each user. As said previously the deletion
can be expensive, so commit what has been done to avoid having to
delete the same user again in case of rollbacks or timeout.
- Delete the user and the partner separately. If the partner is used
in a sales order for instance, the unlink is possible for the user
and not the parner. It allows to unlink the user and keep the
partner in case it cannot be deleted.
- Re-call the cron into another transaction in case there are too many
users to delete, instead of waiting next call, that is supposed
to occur the day after.
Taskid: 3222941
Part-of: odoo/odoo#114656
During revision 415525cecc
the code comparing the connections without password has been
dropped, for an unknown reason.
Because of the above, and the fact psycopg2 alter the password
with 'xxx' for security reasons, the connections recycling was
no longer working as expected, and was recycling less connections.
closesodoo/odoo#37005
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue: when use t-if to display text and use mutli line, the white-space
are removed.
```
<div>
<t t-out="nb"/>
<t t-if="nb == 0 or nb == 1">product</t>
<t t-else="">products</t>
</div>
```
is rendered:
```
<div>
3products
</div>
```
closesodoo/odoo#114986
X-original-commit: 3150a3769ff4d762c0e52dab31a70b59292c1bcc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
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
The test-file is used by some dev to run all test classes from a file.
But test-file is always post install and doesn't always have the same
behaviour of a normal test execution.
This commits modifies the module test tags behaviour to be able to
give a file.
closesodoo/odoo#113850
X-original-commit: 5aff8cf22ab0cbac7a9a3cebf39860f55617f79e
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Odoo Test environments requires to modify many parts of the unittest
TestCase, Suite and Result.
The main initial reason is to **avoid to postpone result at the end of
the test suite**, because even if it is convenient to have all errors
visible after the tests in some case, odoo logs adds information during
the execution that can be useful to debug when a test fail, to have
context for an error. (see **OdooTestResult**)
We are also fixing the stack trace comming from a unittest and since
there is no proper way to hook inside the TestPartExecutor, a dirty hack
injects anoter result on the outcome to manage the error and complete
the stack trace. This was also a way to avoid to postpone subtest logs
at the end of the test case (see _ErrorCatcher)
`_feedErrorsToResult` was used to test the test suite behavior since
there are many customization and this is quite fragile, especially if
unittest changes behavior in other python version.
**Python 3.11** introduced python/cpython#664448d8 That, in a way, goes
in the same direction of the changed introduced with _ErrorCatcher:
immediately feed errors to resut instead of postponing it. But this also
removes `_feedErrorsToResult` that was used to test this behaviors, as
well as other ones.
Since odoo should remain multi-version, this amount of changes on the
initial behavior become to complicate to keep cross-version and the
(already in our mind for a while) solution to **vendor unittest** will
help to simplify most of our test code base.
This commit modified the vendored unittest files to simplify them as
much as possible to suite our needs.
Since the runner is still the unittest one, we need to inherit from
unittest.Testcase in order to have the right type.
This also means that we still have access to all TestCase methods
without overriding them all. This is convenient for assertion methods as
an example but the initial idea is to vendor our own version of TestCase
to avoid having trouble to adapte our miscommunications to future python
versions. A trade-off must be done to chose what should remain in our
code base. The idea is to keep logic closely linked to our changes in
our code base, mainly around the run method, but also addClassCleanup
wich need to be vendored for python 3.7, but assertions methods are
independent. Any logic can be moved fom unittest to our
vendored version in the future if needed.
X-original-commit: 9a5d1ea54be49e4cc8208c33e76a6bbd2414d5d0
Part-of: odoo/odoo#113850
Babel 2.10 (provided in Debian Bookworm) changed the `medium` format at
least for fr_FR and zh_CN.
This commit adapts the tests in order to work with both versions of
Babel. A custom format is used as our unit test is made to test that our
formating methods works, not the way the Babel formats.
X-original-commit: b77eb98bbf6bc937efb7941802c0794ae3622094
Part-of: odoo/odoo#113354
Install a database with many langs, arab, french, english, ... Keep
english as the default lang. Start a shell and validate a sale-order
using the superuser. On the web client, the sale order has been
validated in arab instead of in english.
In 16.0 the `context_get` method was changed to ensure there was always
a lang set in the returned context. It used the following fallback
order: context > request. The solution was partial because in case there
was no request to extract a lang from, no lang was set on the context.
In a recent 16.0 fix (f2523c4a), the mechanism was changed to fix the
previous problem. The fallback order became: context > request > first
installed lang. This solution is sub-optimal because the first installed
lang isn't always the best pick. e.g. when you have a mostly english
company but that arab is installed for some website pages, arab is
selected instead of english (the langs are alphabetically sorted)
In this work, the fallback order is changed once again:
1. The lang set on the user's profile if activated
2. The best lang extracted from the user's browser if activated
3. (new) The lang of the user's current company if activated
4. (new) English if activated
5. The first lang (ordered by ISO code) if any
6. English
The 3rd should cover most of ill-cases. For the 4th step, we assume that
english is prioritaty to other installed langs when no lang standout.
closesodoo/odoo#113186
X-original-commit: 03134bf7cb1e3d63f3be435fbc734e6198ca029b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.
closesodoo/odoo#113039
Task: 2759019
X-original-commit: c3745be816b1bf9ecd38184307452f93326ef36f
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Since python/cpython#18544, unittest mock is not able to properly find
the "odoo.tools.config".
When trying to patch the `options` dictionnary, it leads to
`AttributeError: module 'odoo.tools.config' has no attribute 'options'`
In order to have the tests
working in python <= 3.11, we have to import the config module and patch
the options in place.
Part-of: odoo/odoo#112450
In 15.0 this was supported. It may be also handy when editing views to
momentarily set the groups to `""`.
Steps to reproduce:
1. Install Odoo 15 locally
2. Edit or create a view with `groups=""` for some component
3. Upgrade to 16.
It fails.
Empty groups was allowed in 15.0 we want to ensure this is not broken
unintentionally anymore, such a new test was added.
Muted logged to hide the warning (also present in 15.0):
```
2023-02-08 11:09:18,697 506777 WARNING test_16_gr odoo.addons.base.models.ir_ui_view: The group '' defined in view does not exist!
View error context:
{'file': None,
'line': 3,
'name': 'foo',
'view': ir.ui.view(242,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(),
'xmlid': ''}
```
closesodoo/odoo#112246
X-original-commit: 4379dce95edcc34a8e97e73a3bdaa2e20fdc79a8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit adds cumulated optional attribute to the graph view rng
definition.
`cumulated` graph attribute is used, defined and tested in PR #97394.
closesodoo/odoo#111880
X-original-commit: 5be91c78c687cc2ac8fd3f9a94e4e8ef2b951efa
Signed-off-by: Dardenne Florent (dafl) <dafl@odoo.com>
Before this commit, there is no way to "void" model translations, i.e.,
discard a translation and let the value fall back on the 'en_US' value.
The API of methods write() and update_field_translations() can only
overwrite the translations for the specified languages.
After this commit, calling update_field_translations() with a falsy
value except the empty string discards the corresponding translation
value, and let the value of the field in the given language fall back on
the 'en_US' value of the field.
X-original-commit: 5434fb845c393327db377abf872c448f4860a7d3
Part-of: odoo/odoo#111869
Warnings show up when using a recent pylint. It's only a fraction of
what e.g. pycharm flags as "local variable might be referenced before
assignment" but seems a good idea to fix anyway in prevision of
possibly eventually updating the reference pylint.
closesodoo/odoo#107968
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
On our saas, when users configure a mail server, they can't use anymore
the "odoo.com" configuration (which is stored in the odoo-bin argument).
To allow them to continue using the SMTP CLI configuration, we add a
new "smtp_authentication". When this authentication method is chosen,
all the "connection" fields of the mail server are ignored, and the
connection information are taken from the odoo-bin arguments. So they
can choose the from filter of this SMTP configuration, the priority...
Task-3061882
closesodoo/odoo#106297
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Brieuc-brd