psycopg2.extras.execute_values was introduced in PR #101237
however it pypasses the override logic for cr.execute. As a result
1. --log-sql cannot log these queries
2. assertQueryCount cannot notice these queries
...
This commit create a new api cr.execute_values to support the same SQL feature
without losing the override logic for cr.execute
closesodoo/odoo#131190
Related: odoo/enterprise#47374
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Create a vendor bill with a specific attachment (on ticket)
Go to vendor bill list view
Select the created bill and another one
Print > Original Bills
Traceback due to unhandled ValueError on pdf read
opw-3498898
closesodoo/odoo#135320
X-original-commit: adf4c91f3f696ee849577e345d40e24d59d452f4
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This commit adds `target=download`, as `target=self` adds some unwanted
visual effect. In other words, the "block UI" is never unblocked when
some actions are triggered. This is specific for "Download" actions as
the download is correctly executed, but the page is never `unload`.
e.g.:
```python
action = {
'type': 'ir.actions.act_url',
'url': '/web_enterprise/partner/%d/vcard' % record.id,
'target': 'self',
}
```
Note:
We can't use "'target': 'new'" as it creates a bug in Mobile Apps.
When The Mobile Apps create a new "Tab/Page", they do it in a new
sandboxed browsing environment, so the user isn't logged in and the
resource isn't accessible anymore.
Task ID: 3435131
closesodoo/odoo#134436
X-original-commit: 08db3deb3336f0c1ff9fe2703ebeb8ea5b5aeb3d
Related: odoo/documentation#5822
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Only available in Python 3.9, and for now at least Odoo remains
committed to supporting Python 3.8.
And it's not actually necessary: `literal_eval` supports ast node
input, because internally it just `ast.parse`s the input then
evaluates it, giving it an AST node just skips the parse step.
closesodoo/odoo#135302
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
fix typo to log correct error message when the imported file is badly formatted
X-original-commit: 75606b0f92a26b64ee281792dfa32d47f135f46d
Part-of: odoo/odoo#135277
before this commit:
translations updated by `update_field_translation` api cannot be detected by
t-cache and some cached data whose model overrides `write` with an extra
'clear_caches()'
Step to reproduce:
- Create a mega menu, select any template, `Odoo Menu` for the example
- Install another language on the website
- Go to the translated version of your website and enter translate mode
- Change "Camera" in the mega menu to something else
- Save
The change won't be replicated, looking like it did nothing.
From there, removing or adding `edit_translations=1` in the URL will
use different cache version of the page's views and you will see the
outdated value on one and the correct on the other one.
after this commit:
`update_field_translation` will call `write`
it does the following 4 important things
1. mark field as modified
2. execute logics in the override `write` method
3. update write_date if needed to support t-cache
opw-3305117
X-original-commit: 2beb466668e4eb80d7c3ca3947445fb1cb141cff
Part-of: odoo/odoo#135277
When creating a new company, SUPERUSER_ID is not added in `user_ids`.
Therefore, when installing a new module, the newly created company
is not in `self.env.companies`, which leads to an issue when
computing `company_id`.
Steps:
- Install Accounting module
- Create a new company with any localisation
- Delete the tax closing entry
- Try to install `stock_account` module
-> Error: `_check_company` failed
With this commit we add the company newly created to
the superuser's `company_ids`
opw-3488788
closesodoo/odoo#135276
X-original-commit: 771fdaf25eefdc30443e96b03b029346bebb50be
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This commit reworks a little bit the backend assets to remove a
bundle and thus save a call at webclient startup. The bundle
"assets_backend_prod_only" existed only to allow to add files in
production, but not in the tests (typically, the file that spawns
the webclient).
This commit introduces a new bundle "web.assets_web" that contains
"assets_backend" and the few files that we only want in production.
In the /web page, we now load "assets_web" instead of
"assets_backend" and "assets_backend_prod_only". In the /web/tests
page, we keep loading "assets_backend", which is now directly
included into "web.tests_assets".
For the sake of consistency, this commit also renames the dark
mode bundle "dark_mode_assets_backend" into "assets_web_dark".
closesodoo/odoo#135204
Related: odoo/enterprise#47316
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
According to standard flow when a record is created by user we do not make
a model data entry and if he does any changes in standard record we change the
noupdate to true on conditional bases to keep the data same while upgrading
but in the case of user created record where there is no model data entry the
engine should consider it as noupdate true but without the model data entry
select query gets null resulting into engine considering it false and the update
case are designed to consider true or else so for null case it falls under else
part hence creating issue in product_template name and cowed website menu
So,we have updated the case accordingly.
closesodoo/odoo#135218
X-original-commit: 880538db4ac4833322e57adb3b4d8239eb382547
Signed-off-by: Raphael Collet <rco@odoo.com>
- If default language of website is not en_US then it's
translation will be lose after upgrade as till now we are
considering en_US as a default language for all the records.
- In this commit, we have added translation for website which
is having different default language.
Opw: 3186741, 3418725
X-original-commit: 2575dff9362ba6dd2a97db8911ac8b867b126e08
Part-of: odoo/odoo#135218
This way, we avoid spamming the log each time new constraints are added in the constraint's table.
closesodoo/odoo#132681
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
before this commit, the uninstall and upgrade option is not
shown in the kanban.
introduced in: https://github.com/odoo/odoo/commit/5b68871097df5e7a13966dee4c650d1f34f9e7c1
* open apps kanban
* click on kanban menu(3 dots) of installed app
* upgrade and uninstall button is not shown
after this commit, the upgrade and uninstall button will be
shown in the apps kanban menu depending on the state of
the app
closesodoo/odoo#135132
X-original-commit: 90184ff280b4225522797528af51a32591eb5347
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
For model_terms translated fields if a translation for a lang(fr_FR) has never
been defined
before this commit
when update translations for both en_US and fr_FR, the new translation for fr_FR
cannot be saved.
after this commit
new translations can be correctly saved when en_US and fr_FR are updated at the
same time.
closesodoo/odoo#135103
X-original-commit: ef4b195eeac178a14eb47f4e6cc61ddc97f78866
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
before this commit, in the import translation
wizard, if user try to import a file
currently it will show any file types to
upload even though supported formats are
csv and po
after this commit, if user try to import a
file only csv and po files will be shown
closesodoo/odoo#128807
Signed-off-by: Raphael Collet <rco@odoo.com>
Description of the issue/feature this PR addresses:
Prior to this, when multiple currencies with the same symbol where to appear
in a same document or be sent from a country to another with the same currency
symbol, the only information the recipient had was
the currency symbol leading to lack of clarity.
Desired behavior after PR is merged:
This set of two PR has for objective to give the user the possibility to edit
the symbol curency that is displayed everywhere so that if he feels like the
documents and views are lacking clarity, he can improve it.
This was already an option before but only when the debug mode was active.
This commit has the purpose of moving the currency symbol option out of the debug mode section and put it in the right column of the currency form view.
Adding this, the "Symbol" option is moved out of the debug mode.
task-3484335
closesodoo/odoo#133554
Related: odoo/enterprise#46527
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
With input 'name email@domain.com' (missing chevrons allowing to clearly spot
the email part) 'getaddresses' returns ('', 'name email@domain.com) i.e. the
whole input is considered as being the email.
To improve the heuristic we can add a fallback by recalling 'getadresses'
on the input with spaces replaced by commas when it found only an email and
no name. The new email will be split into sub pairs allowing to find the real
email and various name parts, allowing to make a new name / email pair.
Emails should not contain spaces thus this is coherent with email formation.
This fallback actually comes from a specific code done in '_parse_partner_name'
of Partner model. Supporting it directly at tools level make the behavior
coherent for all models.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@18c71edf59
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
As of rfc5322 section 3.4.1 local-part is case-sensitive. However most main
providers do consider the local-part as case insensitive. With the introduction
of smtp-utf8 within odoo, this assumption is certain to fall short for
international emails. We now consider that
* if local part is ascii: normalize still 'lower' ;
* else: use as it, SMTP-UF8 is made for non-ascii local parts;
Concerning domain part of the address, as of v14 international domain (IDNA)
are handled fine. The domain is always lowercase, lowering it is fine as it
is probably an error. With the introduction of IDNA, there is an encoding
that allow non-ascii characters to be encoded to ascii ones, using 'idna.encode'.
Also remove usage of 'email_re' in mailing email check. It is too restrictive
compared to real formatting we support (or try to). Valid outgoing emails
were directly canceled, notably when containing unicode.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@3ce5fb3072
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When having multi-emails input in an email field, 'email_normalized' field is
currently 'False', as they expect the field to contain a single email. This
has several drawbacks
* searching partners or fetching information based on emails does not work as
most tool methods use 'email_normalized' which is False (see e.g.
'_message_partner_info_from_emails', '_mail_find_partner_from_emails'
or 'find_or_create');
* blacklist is not available as it is based on 'email_normalized';
* mass_mailing wrongly considers those emails as invalid and cancel their
mail and related trace, as it tries to skip sending emails to invalid
emails;
Be more defensive and use first found email in case of multi-emails field.
Other emails are ignored. It is already an improvement that does not break
flows in stable and allow more emails to be sent.
before
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: False
after
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: raoul1@raoul.fr
A side effect is that it helps finding back some partners, as indicated in
tests where less phantom partners are created. It also helps suggested
partners / emails flow in discuss.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@90218186c5
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
Move tests currently in mail about helpers defined in 'tools/mail.py' directly
into base. No need to test it in mail, there is no specific override or
behavior change compared to base.
Regroup partner related tests in base into 'test_res_partner'. This breaks
part of test history but it helps knowing which features are tested.
Task-2612945 (Mail: Defensive email formatting)
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
RATIONALE
Add tests related to not standard usage of email field. Two main use cases
are tested here
* formatted emails: `"Full Name" <email@domain.com>` stored into the 'email'
field;
* multi emails: `email1@domain.com, email2@domain.com` stored into a single
'email' field;
Additional tests: tests with unicode / ascii / case / wrong formatting are also
added to check the support in normalize and format methods.
IMPLICATION
Email field is generally managed as "containing a valid email". This means
it is sometimes used as it in 'formataddr' as well as to perform searches or
identification checks. Example of issue: partner 'Raoul' has a formatted email
like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to
from: "Raoul" <"Raoul" <raoul@raoul.fr>>
-> which is incorrect (but often dynamically corrected by email servers);
Email field holding multi-emails are not normalized, as current normalize
is done only if the field holds a single email. It means
* no easy finding based on 'email_normalized', e.g. various tools like
'_mail_find_partner_from_emails' or 'find_or_create' do not find partners
based on this email;
* no exclusion list management;
* issue with formatting, like
to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr>
-> which is incorrect (but often dynamically corrected by email servers);
USAGE: OUTGOING EMAILS
Those use cases currently generate faulty outgoing emails. This is valid for
recipients ('email_cc', 'email_to') as well as author ('email_from').
For formatted emails: `email_to` is formatted again based on name and email
which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`.
Note that multi emails without formatting may work as it leads to email_to
`"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email
servers correctly send multiple emails. It depends on their fault
tolerance.
USAGE: FIND BASED ON EMAIL (NORMALIZED)
When searching for partners (e.g. using '_mail_find_partner_from_emails' or
'find_or_create') normalized version of input is used.
In case of multi emails sanitize is 'False', as normalization expects a single
email in the field. Therefore no partner is found. In processes that do a
"search or create" (e.g. using a template on a record) this leads to creating
a new partner (or several partners in case of multi emails) each time.
USAGE: OTHER FLOWS
Other flows are build on top of '_mail_find_partner_from_emails' / 'create'
of outgoing emails and are impacted by formatted email / multi email usage.
Those include notably
* mass_mailing: '_message_get_default_recipients' should be defensive to
give correct values when creating mailing emails;
* mass_mailing: faulty emails is based on normalize and multi-emails are
considered as faulty and ignored;
* after post hook: '_message_post_after_hook' tries to link messages without
author (but email_from) with newly-created partners, when partners are
created from chatter. It is therefore impacted by those corner cases;
* marketing_automation: built on top of mass_mailing and suffers from the
same issues;
USAGE: UNICODE
Unicode in emails should be supported. 'formataddr' and IrMailServer notably
received fixes to support unicode. Some check performed on email addresses
fail when unicode is involved, which leads to some emails not being sent
while they could.
SPECIFICATIONS
Add tests related to those corner cases. Also add tests for computation of
`email_formatted` field of Partner model. It currently generates wrong email
values for the same corner cases (multi emails, formatted emails).
Tests are also added for the computation of `email_normalized` field used
notably for blacklists. It is not computed currently when being in multi
email mode which prevents from any blacklist mechanism as well as make
email finding harder. `_mail_find_partner_from_emails` tool method is also
tested with multi email as it uses the same heuristic as normalized email
field.
Tests are also added for mass mailing, when having to mail documents that
have a partner with formatted emails / multi-emails, or that have an email
field with formatted emails / multi-emails.
Also restore a test removed at odoo/odoo@afcb734908 while it should have been
updated to state that email addresses containing non-ascii characters are
supported.
Add some tests for tools methods used in various email processing flows.
Unicode tests are also added.
In future commits we will try to make email usage a bit more defensive to
try to lessen issues with that kind of use cases.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@fc8442f133
Part-of: odoo/odoo#134934
Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.
In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1e6d50a141
Part-of: odoo/odoo#134934
The breakpoint() builtin was added in [Python 3.7] ([PEP 553]). It is
conveniently everything-agnostic, can be configured (including
disabled) via an envvar (`PYTHONBREAKPOINT`) and
code (`sys.breakpointhook`), and defaults to pdb (`pdb.set_trace`).
This is more flexible as it allows using arbitrary callables without
special casing, which mostly allows using less common
debuggers (e.g. IDE debug servers / hooks).
As using an empty string for the debugger name was not allowed
previously, co-opt that to invoke `breakpoint`. And deprecate the old
style.
[Python 3.7]: https://docs.python.org/3/whatsnew/3.7.html#pep-553-built-in-breakpoint
[PEP 553]: https://peps.python.org/pep-0553/closesodoo/odoo#134842
Related: odoo/documentation#5800
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Rationale:
- allow mass changing languages (in case you want to remove one lang)
- allow quick company re-assign
Other fields are marked as readonly to avoid messes.
Task-3494874
closesodoo/odoo#134786
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Purpose
=======
Allow to group records by their property values,
like we can do with normal fields.
Technical
=========
Because there's no foreign key, when we group by a relational property
we need to check the existence of the ids in the query (and same for
selection and tags, because we might have value of a deleted
option / tag in database).
Task-3032464
Part-of: odoo/odoo#103510
Purpose
=======
Currently, it is possible to use some bad characters in a property name
by writing directly on the parent (not via the child).
It's possible only with RPC call and it wasn't an issue because we
recheck the name anyway before using it in SQL query (but it should be
cleaned).
We also restrict the maximum length (there's nor reason to use
huge property names).
Task-3032464
Part-of: odoo/odoo#103510
Purpose
=======
Allow to use `default_properties.xxxxx` as a context key, to set the
default value on a property. We need that because when we group by
a property in a Kanban view, we can create new record in a given
column, and this process will set this context key.
Task-3032464
Part-of: odoo/odoo#103510
Server actions that 'update the record' have a mechanism to allow users
to easily select a selection value if the field they want to update is a
selection field (instead of having to type the technical value
directly).
Before this commit, this mechanism incorrectly stored the selection's
name instead of the value (e.g. 'Done' instead of '01_done'), making the
write crash when the action was run.
closesodoo/odoo#134625
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In this commit, the loadXML function has been removed. We use registry with
xml_templates to load XML templates for OWL Apps.
The goal of task is to remove loadXML and getBundle from assets to simplify
the understanding of assets api.
task-3266441
closesodoo/odoo#134520
Related: odoo/enterprise#47001
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
*: base, crm, digest, mail, mass_mailing, sms, test_base_automation,
website_forum, website_sale
This commit makes "Automated Actions" more discoverable and usable by:
- Adding a menu in the kanban header config dropdown to add/edit them.
- Creating a new custom kanban view for a clear understanding of each
automated action record and its associated actions.
- Introducing new "smart" triggers that appear in the form view based on the
chosen model:
- Updated Values category:
- "Stage is set to" when a `stage_id` field exists in the model,
allowing users to select a specific stage value.
- "State is set to" when a `state` field exists in the model,
allowing users to select a specific state value.
- "Priority is set to" (`priority`) where users can select a specific priority.
- "User is set" (`user_id`, `user_ids` fields)
- "Tag is added" (`tag_ids` field) where users can select a specific tag.
- "On Archive"
- "On Unarchive"
- Timing Conditions:
- "After creation"
- "After last update"
- Deprecating previously known triggers "On Creation" (`on_create`) and "On
Update" (`on_write`) to simplify the user experience. "On Creation & Update"
(`on_create_or_write`) is retained and renamed to "On save".
- Changing the `ir.actions.server` Many2one relationship to a One2many
relationship. Automated actions can now directly contain multiple actions,
eliminating the need for an "Execute several actions" action in automation
rules.
- Introducing a widget for the new `ir.actions.server` One2many field for a
clearer understanding of multiple actions.
This commit also enhances the usability of "Server Actions" (`ir.actions`) by:
- Removing the `ir.server.object.lines` model and the associated `fields_lines`
One2Many field. The attributes of the removed model are now merged into
`ir.actions`. An action can now write to only one field, and the create action
is now a name_create action.
- Adapting the form view when creating an "Update the record" action. The value
field shown adapts itself based on the field to update; this field can be a
`reference` field for a `one2many` `update_field_id`, a `one2many` field for a
selection `update_field_id`, or a `text` field otherwise.
- Refactoring the form view to display only relevant details and other
miscellaneous improvements.
Taskid: 3085360
Part-of: odoo/odoo#114352
Co-authored-by: Florent Dardenne <dafl@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
When we haven't provided a custom action, the tour step runs the default
action. In the final step of the tour, when there is no `run` or
`isCheck` provided, It shows warnings of 'ignoring action (auto) of last
step' as it can lead to a race condition.
This commit resolves the warnings: `ignoring action (auto) of last step`
task-3429500
closesodoo/odoo#129239
Related: odoo/enterprise#46683
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit, adds a new python method (`web_save`) to save a record, and
optionally read-it again in one rpc call. This optimizes the current
behavior that is to save a record in one rpc, and read-it in a second
rpc.
web_save, will receive the list of IDs of the records to save (if this
list is empty it will create the records, if not, it will write on the
existing records), the list of changed fields, and the unity
specification as optional argument to read the created/modified records
(if the specification is not set, the function will return a list of IDs
of the created/modified records).
closesodoo/odoo#133021
Task-id: 3453184
Related: odoo/enterprise#46559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When _create() is invoked, it inserts rows into the database, and sets
the cache of the corresponding records to the values that are inserted.
If a field is not passed to _create(), we assume that its database value
will be NULL (or falsy, at least) and put None in cache, in order to
avoid fetching that value. However, this only makes sense for stored
fields.
Part-of: odoo/odoo#133021
There are cases where the result of `check_company_domain_parent_of`
is used in in a loop, leading to the parent_of relation being
recomputed once or even multiple times per iteration during SQL
evaluation.
Computing the parent relationship turns out to be fairly expensive in
worst case scenarios (e.g. lots of companies), so while precomputing
doesn't save much for a 1:1 situation (though it does make the job of
the expressions compiler a bit simpler), the ability to compute it
just once instead of say 140 times does make a huge difference in
e.g. some report renderings.
Nota: apparently `_check_company_domain` can be called with a string
because lol, so there's a special case for that.
closesodoo/odoo#133530
X-original-commit: 2f9ae135c9dd7cb09fa83fda7a9b304993cb3edc
Related: odoo/enterprise#46518
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Changes in default can be bothersome, embed a full baseline
configuration for reliability.
closesodoo/odoo#27926
Signed-off-by: Pierre Masereel <pim@odoo.com>
before this commit, from list view users can install
module using the button in list view and from the
action button.
initially the Install button was not available in the
list view and only option to install multiple apps was
from the action button.
but with the introduction of the button in list header
there is no need for an another server action to
perform the same.
after this commit, the activate modules server action
will be removed from the code and its related test
and also newly added Install button will be renamed
to "Activate" to align with the button in kanban and
form.
closesodoo/odoo#133544
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).
What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.
Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).
Also same as non-utf8 descriptions, mark XML declarations as
deprecated (because it's a hack to make UTF8 descriptions work which
is not necessary anymore).
closesodoo/odoo#133968
Reported-by: @rezak400
X-original-commit: fd353d7d0104431208b91603431e41ef4a6e54bb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.
Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea4c) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.
Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).
Closes#127846closesodoo/odoo#133859
X-original-commit: 4dbc3b00e587f3d64cfd964a685f2bddd1b499ad
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
a translation issue that only appears on Odoo.sh. On the
other systems and locally, everything works fine.
The problem seems to have its source in odoo.tools.translate
Here is the problem:
On the basis of staging (brutus), in the LIMS application, menu Report / Test reports:
* take report 000022. The client is in French.
* click on the button "preview PDF"
-> the values of the "state" column are not translated.
Locally (same sources, same database), these values are well translated.
This field is defined as follows:
```py
state = fields.Selection('get_state_value', string='State', copy=True, required=True)
def get_state_value(self):
return [
('init', _('Init')), ('conform', _('Conform')), ('not_conform', _('Not Conform')),
('unconclusive', _('Inconclusive'))
]
```
Here's what happens:
When the '_' method is called, another method ("_get_translation") is called.
It tries to determine which module is used. To do so, it is based
on the path (path) and use the "get_resource_from_path" method:
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L474
This method iterates over all defined addon paths. On Odoo.sh, these are:
```
'/home/odoo/src/odoo/odoo/addons',
'/home/odoo/.local/share/Odoo/addons/16.0',
'/home/odoo/src/odoo/addons',
'/home/odoo/data/addons/16.0',
'/home/odoo/src/user',
'/home/odoo/src/user/Logicasoft/base',
'/home/odoo/src/user/Logicasoft/lims',
'/home/odoo/src/user/Logicasoft/mail',
'/home/odoo/src/user/Logicasoft/web',
'/home/odoo/src/enterprise',
'/home/odoo/src/themes',
```
The path variable is equivalent to "/home/odoo/src/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
As soon as the 'path' variable has a common prefix with one of the paths in the
mentioned list, Odoo considers that it has succeeded in finding the path that contains the module in question.
Locally, the path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
And the found path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/"
But on Odoo.sh, the path found is: "/home/odoo/src/user/"
because Odoo finds that there is a common prefix. This is the case, but another path also has a common prefix: "/home/odoo/src/user/Logicasoft/lims" and this one is the correct one.
The result is that the module found is not the correct one:
- module='Logicasoft' on Odoo.sh
- module = 'lims_base' on other systems
Since the module is not the correct one on odoo.sh, the translation is not found.
Solution
========
when we have a module present in parent and child path we want to take the child path,
which is the long one, so we sort the list of paths by length which ensures that children
have priority on parents.
opw-3374757
closesodoo/odoo#133862
X-original-commit: 6ef7e188963b65a31589f8f15107ce698cd3dc74
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Improves on #119813 (595aa24843): the
commit splits the ORM cache into several, and adds a log entry when
invalidating caches (both individual and all).
To keep tests isolated and coherent (and also make performance tests
usable), the test framework has to clear all caches between tests to
ensure they don't affect one another. This adds a line of log
to *every* test, pointing into the guts of the test framework.
Since the clearing is willful, unconditional, and not bypassable, the
log line has essentially no value, it just adds tremendous amounts of
noise to the logs.
Fix by muting the registry logger specifically when clearing the cache
in the test suite (there is currently no dedicated cache logger, if
there ever is mute that instead).
closesodoo/odoo#133811
X-original-commit: 52371bac7d4fadbeab139e4cd044cdc6b1005299
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When we changed the display of the form in v16, we forgot to adapt the
python framework default form view layout (used when the form view of
the model isn't defined). This provided a weird layout in these case on
Odoo 16.+.
To fix this bad behavior, we adapt the algorithm used to build the
default view form.
Steps to reproduce:
Create a model without a form view and edit it (like we do when you
follow the rd training).
closesodoo/odoo#133837
X-original-commit: 93e95274939abce5f3facde6c8cd29b922d15251
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
The inherited field of a custom field cannot be deleted
Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
for `x_studio`
Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency
Problem:
The inherited field was not marked as custom so it was impossible to
delete it
opw-3093581
closesodoo/odoo#133820
X-original-commit: 526f3407c7c5b4cd014a4d091ca01b9617e6e938
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Since 3c62ca1eb9, if the `_rec_name` value
is False, `name_search` and `name_create` will return a tuple of
(<id>, False). This is an invalid response for the web client,
which triggers a JS traceback.
Instead of using the old behavior (returning an empty string, resulting
in a partially invisible row in the Many2one selection),
use the same fallback as when the `_rec_name` doesn't exist.
Since `display_name` should never be Falsy anymore, remove part of the
test_mail_message_values_fromto_long_name that covers the
Falsy `display_name` case.
task-3424154
closesodoo/odoo#133691
X-original-commit: 0cb9e66edd9b7142a6e56bc6ee6491e6d6047e51
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Chong Wang (cwg)