This flat structure makes caching easier if odoo adds shared caches for
example. In addition, the use of idempotent names makes it possible to
compare methods during development.
closesodoo/odoo#85110
Related: odoo/design-themes#554
Related: odoo/enterprise#24622
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Until now using a groupby on a view containing a reified field added
with studio was not possible.
Because `read_group` uses these pseudofields as simple fields when they
are not actually columns in the table.
With `read`, `write`, `create` and `fields_get` it was already
supported.
This commit solves this problem by ignoring reified fields in an
override of `read_group`
opw-2793148
closesodoo/odoo#87186
X-original-commit: a25e25aeab3ed6aa1af57fac13312346b723dbf8
Signed-off-by: Raphael Collet <rco@odoo.com>
We should also use the tzinfo to display only the time of a
datetime.
task-2458013
closesodoo/odoo#86967
X-original-commit: 49604185d04a3f9d7772d2a60771f0e777720eef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add the possibility for portal users to manage API keys
in the frontend portal interface.
- Allow for portal users to manage their API keys if the system parameter
`portal.allow_api_keys` is set.
A settting in `res.config.settings` is added in order
to enable or disable the feature (to add/remove the system parameter)
through a compute field,
to avoid adding a new database column in standard
(as this revision targets stable 15.0).
The setting appear only in debug mode.
- Display the API keys in the portal in debug mode only
(as in the back-end for regular users, in their profile)
- The flow in the frontend is a mimic of the flow from the backend,
the wording and the look and feel is from the back-end.
closesodoo/odoo#86915
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Models can be defined by an SQL table, an SQL view or an SQL query (with
attribute _table_query). Counting records makes little sense when the
model does not correspond to a table, and actually fails when it is
defined by an SQL query.
We fix the compute method by counting records only for models where
_auto=True.
closesodoo/odoo#86913
X-original-commit: 956a0a1cc22f3f35fc128e32cb267e2baa793fb9
Signed-off-by: Raphael Collet <rco@odoo.com>
Deleting an orphan translation is mostly impossible, since it requires
'write' access on the corresponding records, and checking access rights
fails because the records no longer exist!
Simply enable operations on orphan translations by ignoring the
corresponding records that do not exist. And make sure that the patch
does not allow to create orphan translations.
closesodoo/odoo#86869
X-original-commit: 454aa2587dcda2582ae58650019669ff0e8baa2c
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
The duplication was used to have a cleaner html page source code by
aligning the <script t-foreach/> for example. However, this behavior
seems difficult to understand and use. Additionally the behavior can be
done with a <t> tag and placing the script inside.
From now on, the space "trick" is only done for <t> tags, so the
template fragment
<article t-foreach="[0, 1, 2]" t-as="value" t-esc="value"/>
<t t-foreach="[0, 1, 2]" t-as="value">
<article t-esc="value"/>
</t>
renders as
<article>0</article><article>1</article><article>2</article>
<article>0</article>
<article>1</article>
<article>2</article>
closesodoo/odoo#86695
X-original-commit: 8f817790d3f36455c66647e79df40b7173ac498a
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, any field requested to `_binary_record_content()`
when the model was `ir.attachment` would be considered as `raw`.
This assumption works at the moment but could lead to unexpected
behavior down the line.
see https://github.com/odoo/odoo/pull/86005#discussion_r824420219closesodoo/odoo#86524
X-original-commit: eeb93287f9a9027d0ce22f9fd3305a7ab081d69f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit: printing a product's label which has currency with
zero decimal places (like CFA franc) raised a traceback error.
To fix this issue, I added a condition that checks whether there is
a separator in the value to ensure that the currency has a decimal point.
opw-2711074
closesodoo/odoo#83358
X-original-commit: bc2ad6ac2312d8446e6d2a9909e957d5e18c3c0e
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
During the merge of qweb/ir.qweb at commit 9ce5bc8881,
the behavior of qweb was preserved instead of the one from ir.qweb.
Rendering inline templates should not be allowed as it is not needed and
include security risks.
Also, minimizing the number of possible types for template arguments
simplifies the API. An error message allows the developer to know how to
adapt his code.
closesodoo/odoo#86404
X-original-commit: 31f3152a1328ec8e2dd28f15433a2cc3ccc80f81
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit, since the refactor of some base64 decoding flows and
the addition of the raw field*, reading the content of a field that was
related to the `raw` field of `ir.attachment` was treated as reading a
base64 encoded content. This commit fixes this issue.
*https://github.com/odoo/enterprise/commit/680db8197731dae175027f81a705c38b0abf94da
task-2785146
closesodoo/odoo#86403
X-original-commit: 6aa984f072dde5667d07516888c6a4bf19aead8e
Related: odoo/enterprise#25272
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
- Render negative duration with the duration widget
Example V15:
- Create timesheet entry with negative duration (e.g. -00:30)
- Print the timesheet entry
Current Behaviour:
- Time is rendered as Time-1h (in e.g. -01:30)
Behaviour after PR:
- Time is correctly rendered (in e.g. -00:30)
opw-2731186
closesodoo/odoo#86360
X-original-commit: a45e2c03e26034f683a692d9c93e26925f7c2a21
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Assets bundle are wrongly regenerated on the following circumstance.
The use of multiples tag `t-call-assets` in some xml template(s) with:
- at least one `t-call-assets` with `t-js` or `t-css` to false
- at least one `t-call-assets` without `t-js` nor `t-css`
In mass_mailing, the buggy regeneration of assets happens at a critical moment
and break the url of a previously generated asset. That url was however saved
in a javascript cache and therefore the bundle is inaccessible. No css style is
therefore applied to the page.
Note 1: the bug for the previous specific case in mass_mailing only
appears if within all the files defined for the bundle
`web_editor.wysiwyg_assets`, the last modified file (mtime) was of
type javascript. No visible bug would appear if the last modified file
was of type stylesheet (css, scss, ...). However, the asset would be
regenerated at a time where the cache should be used (invisible for the user).
Note 2: in order to reproduce the bug systematically without this commit,
it is necessary to disable the browser cache. Otherwise, if the
browser has the broken url in cache, no http request will be made and the bug
will not appears.
The bundles are wrongly regenerated because of how the url is
generated. Part of the url is generated using the "version" of the
bundle. The version is defined using a checksum. The checksum uses
information about the *last modified* file of the bundle. And this is
where bug arises.
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be B
If the bundle was called without `t-js` nor `t-css` the list includes
all js and css files.
- The version for the `js` bundle **and** the `css` bundle will be A
if the last modified file type is javascript or B if it is a stylesheet.
This commit change the behavior to always consider all the files last
modification within bundles in order to derive the version.
Thus:
If the bundle was called with `t-js="false"` the list of file didn't
include js files.
- The version for the `css` bundle will be A
If the bundle was called with `t-css="false"` the list of file didn't
include css files.
- The version for the `js` bundle will be A
If the bundle was called without `t-js` nor `t-css` the list of file
includes.
- The version for the `js` bundle **and** the `css` bundle will be A.
Example:
assetsA has two files:
```
file1.css
file2.js
```
file1.css was last modified at time A
file2.js was last modified at time B
bundle A
```xml
<template name="template_a">
<t t-call-assets="assetsA" t-js="false"/>
</template>
<template name="template_b">
<t t-call-assets="assetsA" t-css="false"/>
</template>
<template name="template_c">
<t t-call-assets="assetsA"/>
</template>
```
In a javascript file:
```js
const ajax = require('web.ajax');
await ajax.loadAsset({assetLibs: ['template_a']});
await ajax.loadAsset({assetLibs: ['template_b']});
await ajax.loadAsset({assetLibs: ['template_c']});
await ajax.loadAsset({assetLibs: ['template_a']});
```
Whenever loading a assets of a template, the urls for the css and javascript
files are saved into a cache until the next browser reload.
In this example, without this commit:
- the first `ajax.loadAsset` `template_a` generate a css asset with version X
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the javascript
cache for `template_a`
- the `ajax.loadAsset` `template_b` generate a js asset with version Y
-> a js file is generated and the url of the js file is
`/web/assets/version_Y...js`
- the `ajax.loadAsset` `template_c` generate a css **and** js asset
with version Y if time A (a css file) is bigger than time B (a js
file):
-> a css file is generated and the url of the css file is
`/web/assets/version_X...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the js file is
`/web/assets/version_X...js`
if time B (a js file) is bigger than time a (a css file)
-> a css file is generated and the url of the css file
is`/web/assets/version_Y...min.css` and is saved in the
javascript cache for `template_c`
-> a js file is generated and the url of the css file is
`/web/assets/version_Y...js`
--> because the css file is re-generated (the version changed from
X to Y), the url in the javascript cache is no longer valid.
- the last `ajax.loadAsset` `template_a` use the url in its cache and
either the css url or the js url would no longer will be available
and a http error will trigger if the code tries to access it.
Task-2778413
closesodoo/odoo#86155
X-original-commit: 2267cfc947eff9fc4f00468610a82c8fbbca36ad
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Coming from odoo/odoo@a4597fe34f . This code is not necessary anymore since we better
handle From, SMTP-From, as well as allowing mail server filtering. We can
now use standard aliases and servers instead of relying on hardcoded value
"postmaster-odoo".
Task-2784996
closesodoo/odoo#85837
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The signature of the _load_module_terms was changed at ac63556e23 to
pass explicit parameters instead of values hidden in the context
The previous code used working on a copy of the context when modifing
the 'overwrite' key. This was no longer the case after ac63556e23.
In case multiple languages are updated at the same time (as when a
module is updated), the 'overwrite' value is set to True after the
first loop.
To reproduce:
1. Create empty db with language English and without demo data
2. Activate languages fr_FR, fr_BE and fr_CH
3. Install module "note"
4. Now change in the fr.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante FR"
and in the fr_BE.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante BE"
5. Now update the module note without overwriting translations
(--i18n-overwrite option not set)
Observed behaviour:
The translations are overriden
opw-2760359
closesodoo/odoo#85768
X-original-commit: 37b98d413debabcd966718b2834d34f349e3cfbc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When users have same groups, implied_ids can be done in batches,
reducing write operations considerably.
Testing done:
800 users groups_id (all have same groups_id in the end) updated using
old code: took ~10s to complete.
With this improvement, it takes ~1.5s
closesodoo/odoo#85712
X-original-commit: 81994ea628cb492fef4e62c496d4ea1ab55d9a7e
Signed-off-by: Raphael Collet <rco@odoo.com>
If an installed module is only present in the dependency graph through a new,
uninstalled dependency, it was not be selected for upgrade when updating the
`base` module (c.q. `--update all`)
closesodoo/odoo#85704
X-original-commit: 6c80e7cfeafaaa4fb7c0d93cbe94c66068fc3170
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
mode
Purpose:
Include the name of the partners so that:
- it can easily be updated
- it is easier for users to recognize who is who
To generalize this modification, a new attribute has been added to the model
field descriptor (odoo/fields.py): default_export_compatible.
Setting this value to True on a field of a model will force that field to be
included by default in the exportation when "import-compatible export" is
selected.
Specification:
If the user goes:
Contacts > List view > Select Records > Action Export
> I want to update data
The field name is selected by default
The fields selected by default for export are the columns of the list so that
what is exported by default is what the user sees on the screen.
The display name is one of the column but is not importable.
When the option "I want to update data" is selected, only field that are
compatible for importation are selected and then display name is no longer
selected.
With this modification, the name is selected instead.
Technical:
- a new attribute "default_export_compatible" has been added in odoo/fields
- the controller /web/export/get_fields that lists the fields available
for exportation has been modified to add a default_export attribute on each
returned field. This new attribute is set to True when import_compat is True
and default_export_compatible is True on a given field.
The client uses that information to force by default the field for exportation.
Task 2734222
closesodoo/odoo#83697
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to allow decimalized formatting of numbers when
rendering integer fields in qweb. This is done through an option and will
be used notably in elearning.
Task-2607416
Part-of: odoo/odoo#74171
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
This commit is the 12th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
The web module is twofold, on one side there are many controllers: /,
/web, /web/login, /web/database/selector, /web/dataset/call_kw, etc, on
the other side there is `session_info`: the method responsible to create
the web client's environ.
This module is kinda an exception as it is (with base) a server wide
module. In the case of the HTTP framework, it means that the controllers
of web are always accessible, i.e. going to / or /web/login will never
return a 404 Not Found even if the user is not connected to a database.
This is both a blessing and a curse. It is a blessing because the
controllers are always accessible it means that a new users can freely
access those routes. It is a curse because *any* user can access them,
even user who don't have a session yet thus who are not connected to a
database yet. From a developer standpoint, we have to put extra care to
correct serve users with and without a database. An example is the
/web/login route, the login/password pair is stored in a database,
without database it is impossible to validate a user login but users can
still access this route without db.
To solve this problem, there is the `ensure_db` function. This function
attempts to find a database using various sources (?db= query-string,
session db, mono db) and to save it on the user session. In case no db
is found, the user is redirected to the database selector. In a way,
this function grants a database to the user in a seamingly experience.
In a way, this function brings a welcome differentiation between
`auth='none'` with a database and `auth='none'` without a database. Such
differentiation only matters for the server wide modules as "regular"
module controllers are only accessible via the ir.http routing map, i.e.
it is not possible to declare a nodb controller outside of server wide
modules.
An important changement is the `session.authenticate` method, before it
was possible to call the method when the cursor was not yet initialized,
authenticate would open a cursor against the given database, setup a
registry and an environment and ultimately save everything on the
current request. Because the cursor is now greedily created, it is no
more possible to update the request environment when authenticating on
another database.
PR: odoo#78857
Task: 2571224
This commit is the 11th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals. See also [REF] core: HTTPocalypse (9) ORM initialization.
Where `request._serve_db` is reponsible for initializing the ORM,
`request._serve_ir_http` is responsible to do the match -> authenticate
-> pre dispatch -> dispatch -> post dispatch sequence. This sequence is
very much similar to `_serve_nodb` with the notable addition of the
authenticate step.
Where `_serve_nodb` was working in a db-free environment, calling the
methods of (Http|Json)Dispatcher right away, `_serve_ir_http` delegates
to the `ir.http` abstract model which in turn use the dispatchers.
The ir.http model is crucial for several modules, web, portal and
website on top. They override the various methods to add advenced
capabilities to the http framework.
An important changement to the ir.http model in this work is regarding
the `_dispatch` method. Before this work it was that method that was
responsible of doing the sequence match -> pre dispatch -> ... . It was
decided to move the responsibility to http.py in order to prevent
modules from taking over the entire framework. One such take-over was
done in the `http_routing` addon and resulted in arguably very poor and
fragile code.
All modules must now carefully override the correct method. You need to
do smart stuff on the URL prior to matching an endpoint? You should
override `_match`. You need to save a special option from the query-
strings to the session before calling the controller? Override
`_pre_dispatch`.
PR: odoo#78857
Task: 2571224
Currently, `Attachment.copy` has an *explicit* check for write access
on the underlying record.
This doesn't necessarily make sense e.g. a user copying an attachment
from a template to an email may not have write access to the template,
but that should not be an issue. And indeed if the copy is performed
"by hand" (read then create) things work fine[^1].
Since both `read` and `create` are checked, the explicit `copy` check
doesn't seem necessary. Drop it, and try to add some tests around
`copy`. Move `test_06_linked_record_permission` to its own `TestCase`
and split it for readability.
A secondary issue is that the `check` in `create` was performed in the
context of the `self` being copied, leading to the same issue as
`copy` being repeated (that is, `a.copy()` would call `a.create()`
which would call `a.check('write')`, even though we're semantically
creating a record from scratch). The behavior is really intended for
`write` where we want to check if we have `write` access to both the
"source" and the "destination" records.
Explicitly opt-out of having any source data in the `create` before
performing the `check` calls, this way we correctly and only check for
the writability of the destination, and only check for the readability
of the source.
issue 2746483
[^1] well not entirely true, see 4th paragraph
X-original-commit: 60723fb311ed7cc1cf901fe90e8745835cf4d54d
Part-of: odoo/odoo#85271
In some cases like `fetchmail.server` and `calendar.alarm`, modifying
the record can result in the corresponding cron job being enabled as a
side effect through `ir.cron.toggle`, even if it was archived before. In
`fetchmail.server`'s case on a neutralized database, this can result in
the cron job unintentionally affecting a production mailbox.
Since `ir.cron.toggle` is inherently risky on a neutralized database,
this PR disables it when an `ir.config_parameter` indicates we are on
one.
This parameter can be set both by the neutralization API introduced in
Odoo 15.2 and by legacy neutralization tools for older Odoo versions.
closesodoo/odoo#85258
X-original-commit: 4fba314faa1c8f67ac1dd93351ebf8ce39c5caf7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Raf Geens <raf@odoo.com>
In neutralized databases, modifying records like `fetchmail.server`
re-activates the related archived cron job as a side effect, which
could impact production mailboxes. The initial solution to this was to
comment out the server action code linked to the cron job as an extra
precaution.
The impact of that solution is too broad, and it also means users have
to be aware of the need to uncomment the code if they do want a cron job
to run on a neutralized copy. It's been replaced by disabling
`ir.cron.toggle` instead:
https://github.com/odoo/odoo/pull/85192closesodoo/odoo#85260
X-original-commit: 6c950959e1f4bed82d62796f0d89d82784e556b6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
before this commit, checking access rights took 2 queries: 1 for group specific rules
and one for generic rules.
after this commit, a single query checks both
This change is important especially for the loading of the menu done in /web,
where we check the security for each model that has a menu, we are saving 25% of the queries
closesodoo/odoo#84736
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Before this commit, when the current user is in the '/my/projects'
route and selects a project the route becomes '/my/project/<id of
project>'. There is no reason to change the route and then adding the id
of the project. In sales order route, we keep the route and we add the
id of the SO to see the portal form view of the SO selected.
This commit renames the route of project and task form view to keep the
same route and the same logic of SO and quotations routes for instance.
task-2648955
Closes#82379
Steps to reproduce the bug:
- Go to any Contact > Sales and Purchase tab
- Edit > Change the barcode, and click Save
- Then click Edit, and try to erase (empty) the barcode > save
Problem:
A validation error is triggered, the constraint will check if other partners do not have the same barcode
but as it is empty there will be several other partners
Solution:
When the barcode is empty, no need to check if other partners have the same
opw-2753291
closesodoo/odoo#84450
X-original-commit: 32754ebc6f5f1b3c739d0a39ef209822fa4ed3a1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Purpose
=======
On the res.config.settings model for example, calling execute without
having changed a single parameter will make several writes on
ir.default records.
However, even if the written and the current values are the same,
the cache will be invalidated several times.
Part-of: odoo/odoo#82999
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Gain of ~80% of the SQL queries & ~50% of execution time in a database
with test_main_flows & dependencies installed.
On a benchmark of 100 calls of (load_menus(True) + load_menus(False))
* 266 > 56 queries
* 0.38 > 0.21 sec of execution (mean)
Note that this only impacts the first request since this method is cached.
Unless user groups (or debug status) are different, the cached results
are returned.
closesodoo/odoo#83172
Signed-off-by: Raphael Collet <rco@odoo.com>
* batch module data prefetch in res.config.settings flows.
* manipulate ir.module.module records instead of a strange list of tuples
* Only keep the missing module names logic where useful (useless for the
res.config.settings scope, modules must exists to be referenced by
a settings field).
* drop the support of module fields of type selection, they are not used anymore,
it's not even sure they still work and this feature doesn't bring much added value anyway.
Part-of: odoo/odoo#83104
Before this commit the phone fields inside forms did start in a blank
state.
After this commit the empty phone fields are pre-filled with "+" and the
country phone code.
The country is determined based on the IP address with the GeoIP
database. The phone code is obtained from `res.country` where it is
kept in cache.
task-2463563
closesodoo/odoo#78068
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
When comparing existing translations to new source value
html tag would invalidate existing translations.
The html tags used for styling (coloring, italic, ...) should not
invalidate the translation as the meaning of the text as not changed.
Changed the logic to compare translations based on textual content only.
+ add some tests.
task-2667950
closesodoo/odoo#83895
X-original-commit: 1fe4b0cc1981382cc3d944ec44276f0aee90945d
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: xmo-odoo <xmo@odoo.com>
Gorash