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
When an access error bubbles through a related field (aka the user
doesn't have access to the delegate or the delegate's field), append
the "intermediate step" so that it's easier to understand e.g. that
the access error to a partner really comes from accessing a user or
somesuch.
In debug mode, if an access fails due to access rules, try to provide
a clearer error message & include a list of the rules which fail for
the record-set.
Note: for read() operations it'll be a bit misleading as failed
records will get a list of all the rules failing for the recordset,
only some of which might apply to that specific record.
In the overrides of _name_search we should avoid creating domains with
huge lists of ids as it is inefficient.
We can also make sure that we optimize the empty search as in this case
the custom domain doesn't make sense, we can simply search on an empty
domain and, thanks to the limit argument, still keep a fast query.
Linked to task 1918906
Thanks to @odony and @nseinlet
closesodoo/odoo#30155
Purpose
=======
It only makes sense to display 'Save' and 'Discard' if the user actually
changed something in the settings.
So after this commit, the 'Save' and 'Discard' buttons of statusbar in
general settings will only appear when you make any changes.
Also when there are changes, there will be a message shown that will tell
the user that he/she has unsaved changes.
The commit is related to Task ID: 1917637
Co-authored-by: Mohammed Shekha <msh@openerp.com>
closesodoo/odoo#29726
Same logic as for the mail.message or ir.attachment, when a record is deleted,
drop the ir.translations linked to it as well.
Fixesodoo/odoo#25105
Co-authored-by: Raphael Collet <rco@odoo.com>
closesodoo/odoo#30721
When printing multiple reports with the "Reload from Attachment" option
selected, the order of the rendered pdfs was not respected. Using an
ordered dictionary instead of a randomized one solves the problem.
opw 1915685
closesodoo/odoo#30690
Because Python only runs signal handlers on the main thread, native
calls (IO or accept(2)) can delay these handlers running. This is
especially problematic when one such call is completely stuck and
we're trying to dump the stack to diagnose the issue.
By running the actual worker's processing in a sub-thread and leaving
the main thread sleeping, worker processes should always be able to
handle signals.
closesodoo/odoo#30688
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
Denis Ledoux