As of 12.0 the superuser account (UID 1) is only meant to be used for
advanced debugging, and non-superuser admin accounts are used for
day-to-day administration.
Adapts the admin detection system to allow non-superuser admins to
select the report layout as well.
OPW 1891131
closes#27497
When creating a new bank account/partner address, the view displays the 'state 'field before the 'country_id' field, which naturally leads users to select the state before selecting the country.
But there was problem: in order to select a state, one had to first select a country, which was confusing.
Done:
- allow the user to select the state before the country (without restriction on country)
- remove the state from the form when the country changes, if the state (name) is not in the country
- automatically set the country when the state is set
- always display the country code in the name_get of res.country.state, to deal with the case where different countries have a state with the same name
In an HttpCase test, when the browser_js method is used, an optional
javascript code can be used to check that the page is ready to execute
the test.
When no 'ready' code is given it defaults to check the
'document.readyState' status.
In some rare cases (discovered by @Xavier-Do) this status is checked on
the 'about:blank' page. As the page seems ready, the test code is
evaluated and fails.
With this commit, when no specific ready code is provided, the test will
wait for a chrome devtools event that ensure the page is fully loaded
before starting the test.
closesodoo/odoo#30584
Description of the issue/feature this PR addresses:
Order of merged pdf reports when attachment_use = True
Current behaviour before PR:
When in a report the "Reload from Attachment" option was selected
(attachment_use = True), and multiple pdfs were printed, the singular pdfs
were stored in a dictionary and appended to a list and thus merged in a random order.
Desired behaviour after PR is merged:
By mapping the pdf with their source record, and sorting the list with the table _order of
the source records of the pdfs, we seek to have an ordered output pdf.
opw 1915685
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30402
When in a report the "Reload from Attachment" option was selected
(attachment_use = True), and multiple pdfs were printed, the singular pdfs
were stored in a dictionary and thus merged in a random order.
Now, we make a list before merging them and sort it with the table _order of
the source records of the pdfs to have an ordered output.
opw 1915685
Before this commit, the condition and the field on which it applied were wrong
That is, when both the user and the partner were inactive, the message saying that
the partner was still active displayed anyway
After this commit, we show the message only when the user is inactive but its
directly related partner is still active
OPW 1928247
closesodoo/odoo#30337
The content id of an attachement can contains a @, therefore
image contained in emails where sometimes escaped by html_sanitize
as if they were emails adresses.
Task: 1915251
closesodoo/odoo#30326
Create any module that inherit 'res.lang'.
Define any new field that is added with that inheritance.
Install that module. Then try to uninstall it. Traceback ensues.
When trying to write 'state': 'uninstalled' on the module,
the prefetching tries to read a column that has been deleted
by the _module_data_uninstall.
opw 1917369
closesodoo/odoo#30176
Currently, a partner is considered a portal
if he has no users
or
if at least one of his users is portal.
This causes problems if an employee has two users,
one portal, one employee
and gets notified in a thread (e.g. @ Marc demo):
The email sent won't contain the action buttons (e.g. view opportunity)
because the employee is considered as portal.
A partner of an employee can have multiple users
linked if at some point two partners were merged,
and the partners had each a user, one a portal
and the other an employee.
This revision changes this behavior,
to consider a user as not portal (employee)
if one of its users is not a portal (an employee).
This is uniform with to the behavior of the
`share` field of `res.users`,
which is `True` when the user is part of the group employee.
```
user.share = not user.has_group('base.group_user')
```
opw-1914103
closesodoo/odoo#30314
Define a field on a model as:
- o2m to res.partner
- the field's column, hence its name, has capital letters in it
(studio does that)
create two objects of that class, each one linked to a different partner with the new o2m
merge the partners
Before this commit, the object linked to the second partner, was deleted
This was because merge partner sql requests did not quote the column name
After this commit, the second object still exists
OPW 1925060
closesodoo/odoo#30300
Some views have the primary mode while having an inherit_id view
In such views, if the user wants to change the inherit_id,
the mode must remain primary.
The use case behind this is a user who want to change
the inherit_id view of the view
product.product.form (product.product_normal_form_view)
to another view.
This view is in primary mode while having an inherit_id
(product.product_template_form_view).
In such a case, the primary mode must remain,
otherwise the view will no longer be opened by default
when opening a product.
Indeed, when searching the default form view of a model,
it only searches for primary mode views for this model.
The `all` is there because this is an `api.multi` method.
We could consider adding a `self.ensure_one`,
but it breaks the API if someones calls this method with multiple records.
This is likely to happen, as this method is used
in `write` which is likely to be called with multiple records.
In my opinion, in master, this should be replaced by an
onchange so the user can see the change of mode
when he adds or remove an inherit_id for a view.
opw-1916324
closesodoo/odoo#30241
Previous to this commit, if one were to create an ir.model.field with a
poorly constructed domain (read: SyntaxError), the server would properly
send an error message stating that an Error occurred, however this would
be too late as the registry with the bad code would have already been
reloaded, this meant that the registry would be left in an unstable
state (read: crashed).
With this commit, a constraint on the domain is added so that we confirm
that the code in the domain field is properly constructed, thus no need
to reload the registry and therefore no crash.
closesodoo/odoo#30157
Since multi-website, we COW (copy on write) views when editing a view on a
website.
This is causing 2 issues related to module install/update:
1. During a module install, when creating an inherited view, it will create
that view as expected on the generic tree.
But that generic tree may not be used on website(s). Indeed, if the view
was edited, we are now using a copy of the view instead of the original
XML view (with an xml_id).
That copied view won't get the new inherited view in its view tree.
Now, we correctly copy the new view under every specific view tree (if
exists).
2. During a module update, when updating a view, it will only update the view
having the xml_id, so the generic one.
But most of the time, the generic view is not used as it was usually COW'd
and the specific view now replace the generic one.
Now, we also apply the update on the COW'd view. Note that only unmodified
field will be updated, this behavior basically mimic the noupdate behavior
on view's ir.model.data.
Step to reproduce for bug 1:
- Install website_sale module
- Go to a product page and then enter edit mode
- Make a modification to trigger COW, eg edit the information area under the
price "30-day money-back guarantee".
- Now install website_sale_comparison module
- The product page won't have the comparison button as the comparison view
inheriting the product view was created on the generic tree and not copied
on the specific tree (COW'd before the comparison module install).
Step to reproduce for bug 2:
- Repeat first 3 steps of bug 1
- Now make a modification in a view from the XML file in
website_sale_comparison module and update the module
- Only the view with the xml_id is updated, not it's COW'd views. This mean
that only the generic view is updated and not the specific one(s) really
used on the website.
task-1920487
closesodoo/odoo#29956
Create an automated action that creates a new record (of target crud_model_id).
Try using a link_field_id: nothing appears to be selectable, even if some fields
satisfy the intended conditions.
The issue is that the crud_model_name field was related to crud_model_id.name,
instead of the correct crud_model_id.model (note the apt naming).
Note that in the onchange the value of crud_model_name was correctly set to
crud_model_id.model, adding to the confusion.
opw 1910671
closesodoo/odoo#30145
Before this commit, changing the value of the HOST variable didn't work because
it wasn't correctly used everywhere.
Moreover, the `web.base.url` was not correctly set: it is set during
authenticate, but when calling it from the console instead of from a request,
which is the case for tests, it is not able to grab and set the URL as needed.
PR: #30000
The method `read()` may be very slow when reading relational fields and
computed fields, because the computed fields can be computed on a recordset
that is larger than expected.
The issue occurs on model 'res.partner' when reading fields 'child_ids' and
'purchase_order_count', for instance. Suppose we read those two fields on a
partner with 1000 contacts. First, the one2many field is read from the
database and stored to the cache; the latter adds the value ids to the
prefetching of 'res.partner'. Then, the fields are fetched from the cache.
When 'purchase_order_count' is accessed on the partner, the field is computed
on all its children as well...
closesodoo/odoo#29867
Instead of checking the size of text only node, let the xml_translate verify it.
The size verification using etree was introduced at 40efdccc3d but was
probably too simple.
Since 45352512a8, this becomes redundant with the nonspace method which can
be extended.
The re.sub is still relevant as some terms may contain only non-alphanumeric and
use push_translation (e.g. '>=' as a selection or xml terms extracted by babel
in static repository)
closesodoo/odoo#29432
Commit a07a076c45 restricts the prefetching to
`self` when accessing the fields to return. This is too restrictive, as it
cancels prefetching of secondary records in computed fields. In this commit we
limit the scope of the restriction to `self`'s model only; this fixes the
original issue without impacting other models.
closesodoo/odoo#30133