Issue

	- Install "Contacts" & 'base_address_extended' modules
	- Go to contacts and create a contact with value:
	  - street name : Chaussee de Namur
	  - House : 40
	- Save and edit again
	- Set country to 'Netherlands' then save.

	Address not splited well (wrong values for street name and house).
	The issue is not present in UI but is in tests.
	(Issue in UI from odoo 14.0+)

Cause

	There is 2 '_split_street_with_params'
	(inverse function that set street fields):
	- partner_autocomplete_address_extended (removed in 14.0)
	- base_address_extended

	The 'spliting' logic is not the same in both function.

	In UI, looks like it does not call '_split_street_with_params'
	from 'base_address_extended' since no super(Partner, self)...

	However in testing, it does call it from module
	'base_address_extended' and therefore trigger the issue.

Solution

	Adapt _split_street_with_params function
	(in 'base_address_extended' module):
	If previous field (from 'street_format') to parse
	in 'street_raw' is 'street_name', then:
	- set `tmp` to: splitted (max 1 split) street_raw
	  with current field seperator
	- set `append_previous, sep, tmp[0]` to:
	  splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
	- add 'append_previous' to 'street_name' value
	- join 'tmp' values and set it to street
	  (should equal to what left from `rpartition(' ')` split
	  + seconf part of first normal split)
	- continue normal parsing flow

opw-2476096

closes odoo/odoo#70783

X-original-commit: d094d2646023965cb3254a31ee8f59aabaf7f2ea
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))

Old syntax is still compatible but starts the migration to the new
syntax that catches error.

Purpose is to make code follow guidelines so that we understand that
some methods are used for computed stored inverse fields.

Task ID 2158302
PR odoo/odoo#42678

Purpose is to reorganize code according to guidelines and split the main
badly named python file, to understand that 3 models are impacted: res.company,
res.country and res.partner.

Task ID 2158302
PR odoo/odoo#42678

Currently when writing on street field of company model, its sub-fields
(notably street_name, street_number and street_number2) are not correctly
computed again in cache.

Indeed address sub fields have no direct trigger as it depends on its
partner_id and its partner_id children (see ``res_partner.address_get()`` and
``res_company._compute_address()``).

When writing on address fields from the company record, we then invalidate
all address fields cache in order to force their computation.

This commit adds a new tool method giving the list of fields coming from the
address partner to copy upon the company.

Task ID 2158302
PR #42678

This commit reverts commit 44221cffacda47a39cdf5f66f15f3d79b732c71b called "[FIX] base_address_extended:
Fix cache miss bug" .

Indeed it fixes the cache miss bug but introduces another one which completely
breaks address encoding.

How to reproduce
  * create a company with address bits (street_name, street_number,
    street_number2);
  * update one of those fields, e.g. street_number2;
  * other fields are emptied once saved, e.g. street_name and street_number are
    False;
  * both company and its partner records are now incorrect;

This is probably due to the unique inverse method introduced by the reverted
patch that sends only the updated value to the inverse method, leading to
other values being reset.

Original task ID 2068145
PR odoo/odoo#42701

X-original-commit: 3f4862ee8c9193719abd8e6dd647e6584f232103
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>

Before this commit:
-The company have 3 street fields have separate inverse method this all method is update same partner fields
-Partner also has same 3 street fields but have the same inverse method for all street fields
-Now the problem is when user company street inverse call then partner inverse also call at that time partner inverse try to access other street fields that not available in a cache so an error occurred.

After this commit:
-Company 3 street fields have the same inverse method so no cache problem when accessing all street fields in partner inverse method

task-2068145
Closes #36568

Signed-off-by: Josse Colpaert <jco@openerp.com>

This branch is the combination of several optimizations in the ORM:

* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;

* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;

* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);

* make method `modified` take advantage of inverse fields to inverse
dependencies;

* filter records by evaluating a domain on records in Python;

* a computed field with `readonly=False` behaves like a normal field
with an onchange method;

* computed fields are computed in superuser mode by default.

Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.

closes odoo/odoo#35659

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.

Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`

In 6c2b54ff there was an optimization that removed extended addresses
fields syncing on parent_id, or concerning field update or creation.

But the list of fields was also used partly for formatting address which
had been supporting extended addresses fields and now does not.

With this changeset, we have the extended fields back but only for
formatting in a new "_formatting_address_fields".

opw-1984608
closes #33144

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>