currently in the kanban view of the apps, the install button is renamed to activate from https://github.com/odoo/odoo/commit/c70984f4031612d64872fcc12e89c35f03e7d2b2 , but still in the form and action(in tree), button is still labelled as Install, so unifying the label of button to Activate in tree, form and action.
closesodoo/odoo#107907
X-original-commit: 26935d67e62649c10ed907e4a730b8f5ab1f127f
Signed-off-by: Julien Castiaux <juc@odoo.com>
Start a server without a -d and with a --dbfilter that allows for
multiple database. Make sure one of the database has the
`base_import_module` addon installed. Create an empty module using
scaffold and deploy it to the server, make sure to provide the `--db`
argument to the deploy command.
It zips the file and attempt to upload it but it fails for a 404 page
not found error.
The problem is that the controllers of base_import_module are only
accessible when the client is connected to a database. It must first
connect to a database (to have a db in his session) and then access the
controller.
The /web/login route is an example of a rather cheap route to get that
is both accessible without being connected to a database and that takes
a `?db=` argument to connect to one. Using that route, we can ensure
that we are connected to a database prior to uploading a module.
Closes#104589closesodoo/odoo#107906
X-original-commit: 8feb5f366255c8cb7927842acea3ec76bbe11df2
Signed-off-by: Julien Castiaux <juc@odoo.com>
No view is available for the mobile form of change.password.wizard. The
default behavior of the framework is to generate one using the backend
model. This result on showing some hidden fields to the user, some of
them (like in this case `Wizard Id`) is impossible to fill in.
opw-3027797
closesodoo/odoo#107911
X-original-commit: 0860ba8538793c081358105238946ebc0d2015e5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This revision is related to odoo/enterprise#33088
The needs is the same:
While using Studio,
instead of removing the node from the view
when the user is not part of the group,
set the node as invisible.
This is so the xpath expressions computed by Studio
takes into account nodes which are removed from the view
when the user is not part of the group required by the node.
e.g.
```xml
<form>
<group>
<field name="name"/>
<field name="currency_id" groups="base.group_multi_currency"/>
<field name="foo"/>
</group>
</form>
```
With the above view, if you want to add a new field after
`<field name="foo"`/>
and the `currency_id` field node is removed from the view
during the post-processing of the view
because the user doesn't have the group,
Studio computed the xpath expression with `field[2]`,
and then the new field was mis-placed,
it was before the `foo` field instead of after.
The strategy is to let the nodes, as invisible,
for which the user doesn't have the groups
so the xpath expression is correctly computed
for the view as it is stored in the database/
before the post-processing step removing the nodes.
The above revision applies this strategy for
nodes other than `<field/>` and `<t/>`.
The `<field>` were not included because it was,
at that time, believed it wasn't necessary.
Even though the index was wrong as demonstrated
in the above example, it was then converted
with the expression `field[@name="foo"]`
instead of `field[2]`, and therefore it was
fine not to include the `field` nodes
in the strategy.
Also, fields were not included in the strategy
because for them, if the `groups` is set
in the Python model
e.g.
```py
currency_id = fields.Many2one(..., groups='base.group_multi_currency')
```
Attempting to read them while you don't have the group
will lead to an AccessError exception.
And there was no way to display the field as invisible in the view
without the web client to try to read its content.
Unfortunately, it isn't the case,
as demonstrated by the tours included in this revision,
field nodes must be included in the views, as invisible,
so Studio can compute correctly the xpath expression.
This revision therefore aims to apply the same strategy
for `field` nodes, make them invisible instead of removing
them from the view when the user is not part of the groups.
The revision takes care to override the web client so it doesn't
try to read the value of group-protected fields when the user
doesn't have the group.
So the field, with the label and everything,
is included in the view, but its content/value is left empty,
as the user cannot read the content.
Technically, there won't be many cases, because
users editing views using Studio are admins,
and in most-cases admins have access to these group-protected fields.
Having a field group-protected to which the admins do not belong
doesn't happen that often.
closesodoo/odoo#107877
X-original-commit: 91f213e202ca29c4ef0bb190663fc48f169a64a6
Related: odoo/enterprise#34940
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Co-authored-by: kebeclibre <lpe@odoo.com>
Before this commit, it was possible to define a <widget/> in the arch of
an x2many in list mode. But this was not supported in normal list views.
So in order to unify the api, we decided to support in the list
view as well.
In a future commit, we plan to improve the widget api to receive only
the necessary props.
closesodoo/odoo#107811
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before:
In the kanban card of Bank/Cash journals
- Clicking the title of the journal opened recon widget (kanban) now it opens BSL list
- Clicking on operations opened recon widget (kanban) now it opens BSL list
- Journal Items view was opening recon widget (kanban) now it opens Journal Items
In bank transactions tree view:
- `Match` button was always visible, now it is visible if line is not matched, otherwise it renames to `View`
Closes PR #105704
X-original-commit: 178991eafdadfd955a7aa68bdecf94a39ec8e2fe
Part-of: odoo/odoo#107668
There are three rationales behind this change to set USD as default
currency and to enable it in the demo data, from the beginning.
With a demo database, before this revision:
1. On runbot, with all modules installed, it's already USD the default
company currency. It's only when you install a module not depending
on account that it's EUR the company currency by default (e.g. CRM)
2. in the base demo data,
the company is set in the United States but with the currency EUR,
3. before installing account, the company currency is EUR,
after installing account, the company currency is USD,
this is due to the fact as the company is in the United States,
the US Chart Of Account is installed, switching the company currency
to USD.
4. when you install a demo database with a module not depending on
account, you are left with a database without any active currency,
and the monetary fields therefore do not show any currency.
For instance, install only CRM with demo,
you have no currency symbol before or after the expected revenue,
which is not the best user friendly experience.
On runbot you do not feel it because all modules are installed,
therefore with account installed, which activated the USD currency.
Additional weird thing with point 2.:
- Unit tests in modules not dependent on account with the
post-install tag had to handle this sudden change of currency change
before and after installing account.
For instance, when running their unit tests with only their module,
but not account, the company currency is EUR,
but when executing the same unit test with all modules installed,
the company currency is USD.
The unit tests had to handle this sudden change within the unit test,
for instance by setting a 1.0 rate for their own company currency,
which shouldn't be the case: the rate of your own currency should
always be 1.0.
closesodoo/odoo#107113
Related: odoo/enterprise#34613
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When a record is `forcecreate=0` and a reference of one of its fields is missing, the update of the corresponding module fails. In this case, we can skip the creation of this record.
An example of this issue is this [record](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L17) in `documents_account` module (enterprise) when the reference of this [field](https://github.com/odoo/enterprise/blob/6411ae071ace980834befeb8040c94b1a05c8034/documents_account/data/data.xml#L20) is missing.
This can be reproduced as follows:
1. Create a DB with `documents_account` module
2. Uninstall `documents_account` module
3. Remove `documents.documents_finance_status`
4. Reinstall `documents_account`
```
Traceback (most recent call last):
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 680, in _tag_root
f(rec)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 567, in _tag_record
f_val = self.id_get(f_ref)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 663, in id_get
res = self.model_id_get(id_str, raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/tools/convert.py", line 669, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1943, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)[1:3]
File "<decorator-gen-35>", line 2, in _xmlid_lookup
File "/home/ayman/src/odoo/15.0/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/home/ayman/src/odoo/15.0/odoo/addons/base/models/ir_model.py", line 1936, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: documents.documents_finance_status
```
closesodoo/odoo#107766
X-original-commit: 2e4f0667397d2d6670df50b9088fa9c23f1f9f5a
Signed-off-by: Christophe Simonis <chs@odoo.com>
Commit [1] introduced the creation of a website in the tests, but
wrongly set `user_id` to the current environment user.
It doesn't make any sense as this field is supposed to hold the website
public user, which is not a real user and is supposed to be a public
user, as the field name hints..
On top of that, the current environment user (the demo user for tests,
which is wrongly set as the website public user) is then used to login
into the website, which is then making things even more weird/wrong: you
are not supposed to login with the public user (which is not really a
public user here but still marked as the public user from the website).
It was preventing the fix from this same PR (see previous commit) to be
working, as it was making this tour crash.
Not setting the `user_id` property will simply let the system create one
for you (a real public user..).
[1]: https://github.com/odoo/odoo/commit/3611aaf0983b3d25822022ebeddd781f6d082bf7closesodoo/odoo#107759
X-original-commit: 68fc99cf944090a37ee2d392990f39adb4899076
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
One can very well select a "auth=user route" as homepage for his
website, like /my.
There would then be an issue with such an URL being set as homepage:
- As the user landed in the homepage controller which is auth=public,
the system will add the public user as env user (see
`_auth_method_public()`).
```
@http.route('/', type='http', auth="public", website=True, sitemap=True)
def index(self, **kw):
```
- Then, that controller will reroute to the homepage url (/my). The
request.httprequest.path will now be /my
- Then, that controller will recall the dispatcher stack:
`request._serve_ir_http()`
- From there, this call won't fail as it should because the user is
considered as logged in as it went already through the
`_auth_method_public()`, adding the public user as env.user.
`_auth_method_user()` won't raise its error.
- The /my page will be rendered despite not being logged in.
Once the user land on that page, the system will actually detect him as
logged out on a page supposed to be accessed when logged in.
It will then:
1. Show a toaster to inform the user
2. Auto reload the page
As the current URL is still `/` (due to the reroute and not a redirect),
the same flow will happen again, and again, looping forever.
--------
Note that accessing /my directly won't be an issue, as it won't go
through the homepage controller (which is auth=public), so there won't
be a user_id set on the env (the public user), meaning that the dispatch
layer will reject the access and raise an access error (through
`_auth_method_user()`.
Also note that the same behavior will occur when going through the first
menu fallback mechanism:
- if the user didn't setup any homepage_url
- and deleted his / website.page
- and his first website menu is /my
In that case, it will go through the first menu redirect fallback, which
will be working fine (as it's a redirect and not a reroute).
With both those 2 flows (going through redirect), the user will
correctly land on the login page (which will redirect to /my once logged
in).
------
Finally, the other solution would be to prevent such a configuration
(/my as homepage_url) but it was not easily doable (if doable at all),
see https://github.com/odoo/odoo/pull/99100#discussion_r963055251
------
A test is also added and over the more complexe case (which should cover
everything):
- With /my as homepage_url
- With the / website.page deleted
- With /my as first menu URL
-> Accessing / as public user should:
1. Reroute to /my (because of the homepage_url set to it) which
should fail now thanks to this commit
2. Since the reroute / re-serve failed, it should reach the
"first menu fallback" mechanism, which is also /my
3. That fallback should be a redirect, not a reroute, so the user
should actually land on the login page
4. Once logged in on that page, it should properly redirect to /my
opw-3077339
X-original-commit: 4f5899f769266edc27a0b2d812df092b95f43c71
Part-of: odoo/odoo#107759
The icons of the enterprise applications in the community apps list are
not updated with the new icons.
This commit update the old icons with the new ones from the enterprise
version.
Note: some of the app in the apps list should be deleted as they're
not in the enterprise version anymore:
- Android & Iphone (using same icon as CRM)
- MRP II
- Website Version
- Website Form
task-3062514
[FIX] web: updating community icons
closesodoo/odoo#106587
Signed-off-by: Julien Castiaux <juc@odoo.com>
When website resolves its menu to the backend, it calls
`load_menus_root`. Unlike `load_menus`, that does not nicely handle
missing menuitems, so *if* one of the root menus was created manually
(hence doesn't have a xid) the website will crash either immediately
or when trying to open the backend menu (depending on version).
Fix by adding a similar fallback to that of `load_menus`.
closesodoo/odoo#107580
X-original-commit: 3a682650cfc96bae0ce4f44a041713a8174a02fc
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`if isinstance(node, SKIPPED_ELEMENT_TYPES):`
---------------------------------------------
It has been added in
https://github.com/odoo/odoo/commit/31b9bee00676e179c124f3d42539103305cf7423
It's hard to tell why it has been added. Though it seems not useful:
- Has we iter the nodes using the tag of the specification,
`arch.iter(spec.tag)`,
this is normally impossible to iter on a node type from that
SKIPPED_ELEMENT_TYPES node type list
(`etree._Comment, etree._ProcessingInstruction, etree.CommentBase, etree.PIBase, etree._Entity`),
as those node types do not have a tag (`spec.tag`).
In addition, in the place calling `locate_node`,
we already do this same check on the specification node:
https://github.com/odoo/odoo/blob/48109c15d319ae69a8fcdd4a6c3b19172a2de6d9/odoo/tools/template_inheritance.py#L144-L150
Version spec should match parent's root element's version
---------------------------------------------------------
It has also been added in the same revision:
https://github.com/odoo/odoo/commit/31b9bee00676e179c124f3d42539103305cf7423
This has been added in 7.0 to handle `version="7.0"` in xml views.
However, these `version="7.0"` have been removed in 8.0, in revision
odoo/odoo@faa09da325
After the above revision, there were still some leftovers,
but which have all been removed in 11.0 in revision
odoo/odoo@70942e4cfb
during an improvement of the RNG validator.
This is therefore enough evidence to say this code
checking for the `version` attribute in `locate_node`
is no longer useful since a quite long time now.
It can therefore be removed.
closesodoo/odoo#107340
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently the `not like` and `not ilike` operators are available for the Odoo domain in Python but not in JS.
This commit adds these two operators in the JS Odoo domain too for better code clarity. For instance:
`[('fiscal_country_codes', 'not like', 'AR')]`
instead of
`['|', ('fiscal_country_codes', 'like', 'AR')]`
Part-of: odoo/odoo#106221
The model terms translations assume the number of terms in each language of a
model_term translated field should be the same.
However, sometimes the assumption cannot be promised for sake of bad
translations
This commit
1. drops illegal model term translations while translating
2. drops mismatched terms at run-time in case the database has been contaminated
closesodoo/odoo#107373
X-original-commit: f9ab5ca3e99b2883ada18a8f6deb12d45608b43f
Signed-off-by: Raphael Collet <rco@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Enable the test for payment modules, as we want to test their install/uninstall.
But disable the test for the deprecated payment modules, which can only be installed
through command line since 16.0.
closesodoo/odoo#107349
X-original-commit: ae559ee083723ff16ec78d93ec781202686553e6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
this commit improves the performance of importing translations by
1. groupup udpating data for different languages and different modules
2. read model_terms translations data directly with xmlid to get rid of fetching
data from ir_model_data
for modules:sale_management, point_of_sale, industry_fsm, helpdesk, mrp, mrp_plm
(62 installed modules)
time for test_language_install is 45.14% less
for all modules:
time for test_language_install is 68.03% less
closesodoo/odoo#107332
X-original-commit: 727ef9e0a2ca93089b472eb1313117fee8dc876d
Signed-off-by: Raphael Collet <rco@odoo.com>
While upgrade of a customer database, A P-type image
was being converted to JPEG image. It didn't allow to save
as direct conversion from P-type(palette) to JPEG. So, fix
covers conversion of such corner cases to first convert it
to RGB and then RGB can convert it to desired output format
opw-3043418
closesodoo/odoo#107300
X-original-commit: d0db7a14dec7ee6a983ede3bf7b968675f83979d
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The routing-map is a mapping that maps HTTP verbs and paths to python
controller methods (endpoints), e.g. it maps `GET /web/health/` to
`/web:Home.health`. The `_generate_routing_map` function is the function
responsible to generating the werkzeug routing-map in regard to the
controller inheritance mechanism. The mechanism makes it possible to
override an endpoint is various odoo modules to enrich it with new
features, e.g. `/web/login` is overriden in website to change the visual
of the page.
Implementation-wise, the informations from each `@route` decorator must
be merged with the other `@route` info for each endpoint override. When
a method is not overriden in a controller, there is not new info and
that controller should be skipped for that method.
The previous implementation attempted to skip such method using the
following idiom:
if not hasattr(controller, method_name):
continue
That idiom doesn't work as `hasattr` will perform a lookup on the full
controller's MRO instead of a lookup only on controller's own methods
and attributes. The controller's own methods and attributes are
actually found in `controller.__dict__`.
closesodoo/odoo#107064
X-original-commit: 42f52d26b6a81a68f1fe28e28971f0e7f4c97d11
Signed-off-by: Julien Castiaux <juc@odoo.com>
Define the following controller:
@route('/get-context', auth='public', type='json', website=True):
return request.env.context
Access that route via JSON-RPC providing a context:
this._rpc({
route: '/get-context',
params: {
context: {"a": 1}
}
})
Since httpocalypse, it replaces the context entirely instead of updating
it. i.e. before you would get along those lines:
{"a": 1, "lang": "en_US", "tz": "Europe/Brussels", "uid": 2}
but since you get instead (and that's wrong):
{"a": 1}
Note that after this commit, this merging-context behavior will be the
same whether or not website=True is defined (while it was only there for
website=True before).
Discovered via opw-2885948
X-original-commit: 7887cfc3f177d9e64f008aabb8bd710f54024dea
Part-of: odoo/odoo#107179
In a view, in the case of a field node combining
- a `groups` attribute on the field node in the view architecture
- a `groups` attribute on the field in the Python model
e.g.
```py
name = fields.Char(groups='base.group_system')
```
```xml
<field name="name" groups="base.group_multi_company"/>
```
The view post-processing adds a temporary `<t groups` block.
e.g.
```xml
<t groups="base.group_system">
<field name="base.group_multi_company"/>
</t>
```
This is to make an `AND` connection with the two groups:
the user is required to have both groups in order to see the field.
Currently, there is no way to make that `AND` combination on the same
node. The below:
```xml
<field name="name" groups="base.group_system,base.group_multi_company"/>
```
would be an `OR` connection, not an `AND.`
Hence this temporary added `<t groups=""`.
Before this revision, in such a case,
the stack post-processing was interrupted by an unexpected side-effect:
The field node changes of parent (the parent becomes that `t` block),
and a condition attempting to check that the node wasn't deleted from
the view actually checked that the parent changed, to decide to
interrupt the rest of the stack post-processing, including the modifiers
post-processing for that node.
This revision changes this behavior,
to check the field node no longer has a parent,
instead of a change of parent,
to decide that the node is indeed no longer in the view,
and to interrupt the stack post-processing or not.
This allow the field modifiers (e.g. `attrs=""`) to be post-processed
as expected.
opw-3072910
closesodoo/odoo#107173
X-original-commit: c163cbb6a9b3679067606868e325d9842ea66aa8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Pregenerate doesn't work for rtl languages. It shouldn't be a problem
but it was discovered that pregenerate run during upgrades leading to
errors
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1314, in preload_registries
env['ir.qweb']._pregenerate_assets_bundles()
File "/home/odoo/src/odoo/16.0/addons/website/models/ir_qweb.py", line 180, in _pregenerate_assets_bundles
_, _, _, id_unique, name = bundle_url.split('/')
ValueError: too many values to unpack (expected 5)tore the set of known environments as it was at setUp
```
This is because the rtl is an extra in the url breaking the logic.
Pregenerate is mainly usefull for tests on runbot
(or running tests locally), to speedup httpcases
avoiding generation at each page load.
IntegrityCases are postinstall but don't requires generating assets, or
at least no so often meaning that we can avoid the pregeneration in this
case. It should also avoid losing some time on pregeneration since it
is not useful.
This new logic only pregenerate if we have at least one HTTPCase in the
test suite. This should also speedup local testing when starting
non http post_install tests.
closesodoo/odoo#107107
X-original-commit: 43a5c17088707eec134d54ccf9341e86859f88c7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Simple refactor in order to make changes to these line trigger the CI/Security
closesodoo/odoo#107032
X-original-commit: 3c215581aa1f8f74f2d9daf1e15f30ee750ec3df
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
- Settings > manage languages > english > Set time format to `%H:%M:%S %p`
> Save
- Install Planning app > go to list view > Try modifying a time manually
(without using the widget which pops up).
Issue:
When trying to save the new time, an error pops up: `Can't include meridiem
when specifying 24-hour format`.
While parsing the new date, the `luxon` library throws this error to
prevent wrong hour values, such as `17 AM`.
Fix:
Prevent the user from inputting both `%H` and `%p` in the same time format
and display a warning notification.
opw-3038797
closesodoo/odoo#106926
X-original-commit: c2b8faa1c89dc16094c1ebec397e935a3b46fac4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Since odoo/odoo@69c3d5aa25
the readonly and required modifiers were no longer passed
for non-editable views. Which means:
- kanban: never passed,
- tree: passed only when `editable="1"` or `multi_edit="1"`,
- form: always passed.
The rationale behind that is that a view which is considered
as readonly doesn't need to know if its field are readonly or required,
as by definition, if the view is readonly, the user shouldn't
be able to modify anything in the view.
This was to make the views sent to the web client more light-weight,
not sending unused information, and save KB of transfers.
However, some widgets, used in the kanban and non-editable tree,
allow to modify fields, even in readonly considered views,
and therefore need to know these readonly/required modifiers
from the field definition in the Python model.
e.g. the `widget="color"`, odoo/odoo#103478
Ideally, these readonly/required modifiers should be transferred
only when the widget requires it, to avoid transferring the
readonly/required modifiers
when they are not useful in kanban/tree views
(which is 99% of the time).
However, this would require a bigger refactoring,
which is considered too risky compared to the added value
for a stable release.
task-3013110
closesodoo/odoo#106838
X-original-commit: 5a68d254949f1d0ff545023cfd14890efff10f5f
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This reverts commit 3ebe1185a4.
The code ECC200DataMatrix already exist in reportlab (that is already a dependance).
Some differences:
- ECC200DataMatrix only supports a Type 12 (44x44) C40 encoded data matrix.
(214 alphanumeric characters and 14 to 27% of error correcting rate)
- pylibdmtx support more type and add a default to 24x24. So it means a
(52 characters and 20 to 35% error correcting rate). It's also smaller
to display.
We consider the gain too small compare to maintain an extra lib.
It also fix blured datamatrix in stock report if they contains too much
data.
*If you want to test 001234560000000018 is a valid sscc for package
closesodoo/odoo#106620
X-original-commit: 54ef19f41ffc4a6f715474b65a4183a7fa75feea
Related: odoo/enterprise#34422
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
As of 16.1, the ecmascript version accepted in odoo is 2022.
This basically makes escheck almost irrelevant.
Escheck being only able to check up to the version 2021, it can be
removed safely.
closesodoo/odoo#106052
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Do like other enterprise modules in Odoo and display missing main applications
from enterprise in community: social and knowledge.
SPECIFICATIONS
Create `ir.module.module` records for knowledge, social and appointment apps
in Odoo Community, so that users searching for those apps can see them in the
correct category with the correct icon. They can then be redirected to Odoo
website for more information about the module or an upgrade plan to use the
enterprise version.
Knowledge
* create the record
* use the module_category_productivity category
Appointment
* update the record to use the new icon
* use the module_category_marketing category (instead of sales)
Social
* create the record
* use the module_category_marketing category
Task-3054412
closesodoo/odoo#106580
X-original-commit: 9ada5587552d50ba4731a2401d4c18589f1d59a5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The new get_views API inlines every subview into the main view in an effort to
optimize client/server communication.
In the situation:
```
<form>
<field name="my_one_to_many" />
</form>
```
The server algorithm will fetch kanban or list views to display that x2many and inline them
in the final arch that is sent to the client.
This commit aims at factorizing the code which does just that in order for studio (or other modules)
to be able to detect whether the subview it receives is "real" or inlined
closesodoo/odoo#106504
X-original-commit: fcf71e51e80b54d709ffbfc5639cc913746ac684
Related: odoo/enterprise#34376
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The res.users model functions a bit uniquely since it should allow a user to
modify their own parameters but turns off model edition priviledges by default.
See "SELF_WRITEABLE_FIELDS".
This implies that ir_ui_view#_postprocess_access_rights method will by default
turn off record edition, by automatically adding a 'edit="false"' attribute on
the form node when the frontend calls 'get_views'.
This will in turn prevent the user from modifying its preferences as it will
set the form view in readonly mode.
(It was apparently ignored pre-OWL, hence why we only have this issue now).
To fix the issue, we force the edition by manually setting 'edit="1"' on our
"view_users_form_simple_modif" form.
Allowing the end-user to modify their own settings again.
A tour was added to ensure this behavior.
Note that tour steps need to be adapted in the 'hr' module, as this module
changes the flow of modifying user preferences.
Task-3067001
closesodoo/odoo#106440
X-original-commit: 490d480458590c205962c3f9b95a63790a59f4d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Version: only V16.0 (will be improve in future versions)
Steps to reproduce:
- install the "contacts" module;
- go to a contact;
- go to the "Set Defaults" tab (in the debug menu).
Issue:
There is no field that allows you to select the condition.
Cause:
The function `getConditions` needs the `change_default` attribute of the field.
Solution:
Add the `change_default` attribute to the list which is returned by the `_get_view_field_attributes` function.
opw-3079328
closesodoo/odoo#106410
X-original-commit: 07315bee24f69e2b9a1004d33eab842a8929709d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
On database with 5 million attachaments, the index of checksum is 250 Mo, but this field is never used to search.
closesodoo/odoo#106253
Signed-off-by: Raphael Collet <rco@odoo.com>
Sometimes a constraint is too complex to be expressed in the general
`_sql_contraint`.
This allows to hook on a constraint if it matches the name in order to
display a user friendly error message.
X-original-commit: e1f06479a526c703ccabc441b1e194646206b966
Part-of: odoo/odoo#106325
When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.
OPW-2955202
closesodoo/odoo#106283
X-original-commit: 28196693b50b9d424887391ad13db69c5f5dfe4f
Related: odoo/enterprise#34265
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
niyasraphy