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
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
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
Similar to what was done [here](https://github.com/odoo/odoo/commit/5d0111d079601c07c62717575cb22ead15c585d0) when the credit limit feature
was introduced, a `sudo()` is also necessary in
`_load_records_create()`.
This method is called when importing contacts from a CSV file.
So the access to the commercial fields is done when synching
fields from the commercial entity to its contact and should
not block the import.
Fixes#126567closesodoo/odoo#131225
X-original-commit: 266e22fc4ea5bb4343700f8d08f9ec2580fab365
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Let's assume that
* Company S is a sub company of it's parent company P
* Company S has access to all the accounts and taxes of company P
* Some taxes are archived, but used
Because of the needed access rules, there will be a `parent_of` on the
record rules of accounts and taxes.
If we consider that we should consider the context key `active_test` to
add a implicit `('active', '=', True)` clause in the domain when
evaluating `parent_of` and `child_of` clauses, an access error will be
raised instead of hiding the archived records, even when simply trying
to read an archived record.
The archive feature and the security rules should be independent; if a
security rules needs to depend on the fact that a record is archived, it
should be explicit in the domain and not rely on side effects of the
implementation of `parent_of`/`child_of`
Part-of: odoo/odoo#125642
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).
Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.
opw-3128771
closesodoo/odoo#122884
X-original-commit: 34e97b4c65b7392576d94b870e22e74df14f9dd2
Signed-off-by: Rémy Voet <ryv@odoo.com>
In https://github.com/odoo/odoo/commit/6371565e6933d6ede88fa85992f4acbc2cb5327b we expect required fields to throw ValidationError when not set,
we thus correct res_partner to raise that error when the email is implicitly
required, so after this commit if we can try to create a new partner from the
name directly then It will give a validation error and wizard will open for the
creation of a new partner.
Task-3297388
closesodoo/odoo#121127
X-original-commit: 98aca8f76f7509b143263100384a2f2ed644124b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit: if you add a custom one2many field to the
'res.partner', like x_related_commercial_partner_ids, that is related to the
`commercial_partner_id` in the`res.partner` model, it won't update the
display name of a contact in case of changing its parent_id name.
Here are the steps to reproduce the problem:
1. Create a new custom field with these values:
a. Field Type = one2many
b. Model = Contact
c. Related Model = res.partner
d. Relation Field = commercial_partner_id
2. Create a new Contact that is the "Company" (e.g. "My Company")
3. Create a new Contact that is the "Individual" (e.g. "My Name"), and
put the "My Company" as its parent_id.
4. Now the display_name is "My Company, My Name" which is correct
5. Change the company name to "My new Company"
-> display_name won't change, and is "My Company, My Name"
The solution is to add the 'commercial_company_name' to the
`display_name` depends.
opw-3202894
closesodoo/odoo#120908
X-original-commit: f242cad9a27fb0e58e1b9c726573b316534f6be8
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
before this commit, on duplicating a contact tag
will duplicate the assigned partners also.
suppose if we have a partner A with tag B assigned,
and then we duplicate tag B and create new tag C,
the newly created tag is automatically getting
assigned to partner A.
after this commit, the copy is set to False for
partner_ids field in tag and then the partners
wont be copied on duplicating a tag
closesodoo/odoo#118974
X-original-commit: 5dc9104403606b6421b9cde732cfa3d6bb5962aa
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce the bug:
Here are aliases for the used contacts:
- A: Azure Interior
- B: Gemini Furniture
- C: Gemini Furniture, Edwin Hansen
- D: (delivery address for Edwin Hansen)
1. Login on a runbot.
2. Set VAT of A and B to different values.
3. Open C, and create a delivery address: D
4. Check: VAT of D = VAT of B
5. Change the related company of C from B to A.
Bug:
The VAT of C = VAT of A, however VAT of D did not change.
When syncing the commercial fields of a partner, we also sync his childs.
PS: Due to function _compute_commercial_partner, the commercial partner is always updated for
all the childs.
So the condition child.commercial_partner_id != self.commercial_partner_id
is never satisfied in function _children_sync and the commercial fields were
never updated.
opw:3111493
closesodoo/odoo#115932
X-original-commit: df87448f2a39eead079cffea566cd760a8918542
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: kmagusiak <>
In order to ease the process of setting vats for some users, it was
decided to allow to use a vat number of a single character ('/' for
example) without checking it. This allows to differentiate between
partners for which we did not set VAT yet, and partners exempted from
VAT/without a number.
The VAT check was recently adapted to handle this use case, but the
"same vat" warning was forgotten in the process.
This additional change will disable the "same vat" warning that appears
when two partners share the same VAT number if that vat number is
only a single character, aligning the behavior of the warning to the
changes done in the vat check itself.
closesodoo/odoo#114640
X-original-commit: 4d80d30d0db6993a2fbbab59b935abe07080074b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
In the partner form, when you change the state of the partner address and the country remains the same, it still triggers an update on the country field.
This change makes sure that the country is only updated when it has actually changed.
task-3143841
closesodoo/odoo#111230
Related: odoo/enterprise#36386
Related: odoo/upgrade#4277
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Creating a new partner with no company selected should raise the
same VAT partner warning if there is any other partner **in any**
company with the same VAT.
closesodoo/odoo#113649
X-original-commit: 97bf59848e6e0dabda28db4b6fc1cc20844f0b97
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.
closesodoo/odoo#113039
Task: 2759019
X-original-commit: c3745be816b1bf9ecd38184307452f93326ef36f
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
How to reproduce
================
1. Create a user with lower privileges then admin
2. Add a new company and a new contact of that company in the contact
app at the sametime
3. Manually save
This will result in a write access denied
opw-3127591
closesodoo/odoo#112595
X-original-commit: 93a37df79fc30c2f9ac31d60dc897452851fd5bd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Improve the partner view by reorganising the city/state/zip row, making
the order of the fields dependant of the country address_format.
This is done to ease the use of these view for our users by displaying
a format they are already used to.
Task id #3138441
X-original-commit: c646f7bb80cb7f9af689082752608b554f1a648b
Part-of: odoo/odoo#111324
To that end, we will now do the VIES and regular VAT
check separately.
The VAT check stays as a constrains, while the VIES
check will now be done in an onchange and simply
display a warning if it fails.
We will also now allow VAT with a single character to
ignore the checks. This will allow users to better
distinguish partners for which they didn't enter VAT
against partners which are not subject to VAT by setting
the later's VAT to '/' or any other characters.
Task id #3138441
X-original-commit: eff3b140cc88dd48b77948a577f195f2e1910fd8
Part-of: odoo/odoo#111324
In this commit, we update the vat string based on the company country vat label.
TaskID - 47184
closesodoo/odoo#110373
X-original-commit: e5e29b7c40282a2e4ca2da841d9f8aebe6c17992
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
Purpose is to be able to create find or create partners in batch based on a
list of emails. When sending email in batch, notably using templates, doing
sequentially a search or create for each potential email to contact is not
efficient from computation point of view. This commit introduces a new batch
method for that purpose.
If no valid email is found for a given email, it is used as it to try to
find partners with same invalid email and/or keep the value in order to
allow updating it afterwards. Notably with notifications resend it is
possible to update emails, if only a typo prevents from having a real
email for example.
Falsy emails do not create partners as those have no real interest.
Task-3034875 (Mail: Speedup and batch partners find or create with templates)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Steps to reproduce:
- install "contacts" and "sale_management" module;
- create a company contact with a value for "Industry" (Sales & Purchase tab);
- create an employee who works in this company;
- create two orders (one with the company and one with the employee);
- go to sales reporting tab and select the pivot view;
- filter by "Customer Industry" and then by "Customer";
Issue:
The employee is not placed in the right category of industry. He should be in the same category as the company he works in.
Cause:
When creating a contact, the `industry_id` field is not passed from parent to children.
(Moreover, this field being invisible for an "individual" contact, it is not possible to give it a value without using the studio application.)
Solution:
Add `industry_id` to `_commercial_fields`.
opw-3085032
closesodoo/odoo#109313
X-original-commit: 60962062aefd34c911385f671c56b03836b3025a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
The same override of `_get_view` was done in `res.partner` and `crm.lead`
in order to call `_view_get_address`, to change the address format
of the partner and lead form.
The definition of `_view_get_address` was already shared between these
two models through the `format.address.mixin` mixin.
So, why not share the override of `_get_view` also in this mixin,
so only one override needs to be written, instead of two.
In addition to merge the code of the `_get_view` override
in `format.address.mixin`, also set the `_get_view_cache_key`,
so the partner and lead form are correctly cached by company,
in case multiple companies in a same db use different address views.
Before this revision, this wasn't the case for `crm.lead`,
which therefore leaded to a bug when two companies where
using different address view, and one company accessed the lead
form before the other, therefore caching its own view version
in the cache, re-used later by the second company when fetching
its own lead form.
This revision takes the opportunity to add a unit test for crm.lead,
to assert the expected form according to the company address.
There was already a test for res.partner, but not for crm.lead.
To avoid copy/pasting the unit for both models,
a common test class is created, re-used to test both res.partner
and crm.lead.
closesodoo/odoo#103438
X-original-commit: 7e4a8b77024af663c5555c6d56557e2c6136b24b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The master plan finally comes to an end.
Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
on back-end views.
The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.
The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...
Not including the groups in the cache key allows:
- to have less cached versions,
(otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
(with the current cache key,
there is nothing to fetch from the database to compute the key)
Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
- parsing arch from/to string with etree is fast,
- removing the `groups=` nodes using etree is fast,
- adding the `create="False"`, `write="False"`, `delete="False"` on the view
root node according to the access right of the user on the model is fast.
This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.
Timing tests are available on the pull request of this revision.
Part-of: odoo/odoo#99417
- Remove FEC from res.config.settings - everything is now linked in the import guide (in enterprise)
- Compute debit and credit from opening_balance
- Update import templates for account.account, account.move, res.partner
- Small UI changes in base_import: add an action title and improve the template button design
task-2888243
closesodoo/odoo#96291
Related: odoo/enterprise#29627
Related: odoo/upgrade#3794
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
In some case, users use custom `address_format` with keys that do not
exists. This lead to errors in odoo and upgrade process. Avoid
`KeyError` by using defaultdict with `str` value.
upg-361146
upg-361241
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 457, in load_modules
force, status, report, loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 349, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 227, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmp1bew9m7l/migrations/website/14.0.1.0/post-adapt-footer-data.py", line 69, in migrate
address = html_escape(partner._display_address(without_company=True))
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 950, in _display_address
return address_format % args
KeyError: 'town_name'
```
closesodoo/odoo#96703
X-original-commit: 81bf1d2101202a4a6cb832004500129905c2d3be
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit does below improvements:
1/ If salesperson and sales team are set on an individual partner, we propagate
those to parent company being created from m2o of the form view.
2/ If the existing parent company is manually linked to an individual partner
being created, and salesperson and sales team are not set on the individual,
we set those values from the linked parent (if set on the parent).
Task-2636290
closesodoo/odoo#78696
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
action act_window can have a "flags" field which contains tweaking parameter for the views.
A little inventory:
- ation_buttons: if true displays on List and Kanban the buttons that trigger action
in the control-panel bottom left area. It is true by default in JS.
- withControlPanel: whether to display the ControlPanel as a whole. True by default.
- search_view: not used or dealt with.
- mode ("readonly"|"edit") whether to initiate a form view in that mode.
(used and practical -- but will be outdated when the edit mode by default is implemented)
This commit removes the occurences of those flags keys that are useless
closesodoo/odoo#94078
Related: odoo/enterprise#28620
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit:
- moves the "Company Registry Number" from `res_company` to `res_partner` (which might be different from the VAT in some localizations). This must be unique among all partners of the same country.
- allows the search of partner by using their "VAT" or their "Company Registry Number"
Task-id: 2857253
Community PR: odoo#91938
Enterprise PR: odoo/enterprise#27605
Upgrade PR: odoo/upgrade#3570closesodoo/odoo#91938
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
If you send an email from CRM and the address you are trying to send the
email to is not linked to a partner, a new partner will be created and
it will use the default_ fields in the context which may not be valid
for the partner
Steps to reproduce:
1. Install CRM and open the app
2. Trigger the list view of the pipeline
3. Select any opportunity with the email 'ErikNFrench@armyspy.com' and
click on 'EMAIL' in the top left
4. Give a subject to the email and select the template 'Welcome Demo'
5. Send the email
6. An error is thrown
Solution:
In res.partner's `default_get`, remove the `default_type` from
the default values retreived from the context if it's not a valid type
of res.partner
Problem:
Trying to create a partner with default_type in the context will try to
give this type to the partner but 'opportunity' is not a valid partner
type
opw-2827177
closesodoo/odoo#93025
X-original-commit: 2b023500d1cc2322adbc51dffda4342aba5032ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Set `phone` and `mobile` fields on `res.partner` to unaccent=False since phone
numbers are unlikely to have any accent. This will also make it easier
to add indexes on these fields in the future.
Part of task-2832241
closesodoo/odoo#91788
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
Currently, when creating a partner, there could be a situation
in which a commerical field has some access restriction
due to `groups` being set on a the field declaration.
The `sudo()` makes sure it does not happen.
closesodoo/odoo#83205
Related: odoo/enterprise#25828
Signed-off-by: William André (wan) <wan@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
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>
Carmen Bianca BAKKER