When the module "base_address_extended" was installed, the contact addresses
of a company were not updated when the company address was updated.
opw:1879968
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Let's install base_vat_autocomplete and base_address_extended
When creating a contact with a VAT number, the street was not
formated by the autocomplete in a correct way because the function checkVat all the time
returns the street with the following format: '%(street_name)s, %(street_number)s/%(street_number2)s'
and this function doesn't take the street format of the country into account.
So the function _split_street tried to split the street into street_name, street_number, street_number2 with the
street_format of the partner but the street was not well formated by checkVat.
opw:1867491
Steps to reproduce the bug:
1. Create a Vendor with these address settings
- Name: Vendor123
- Streer" Street:
- Housnumber: 123
>> DO NOT ADD A COUNTRY => by default street_format = street_number street_number2 street_name
2. Create a purchase order for Vendor123
3. print the RFQ
>> ADDRESS FORMAT "123 Street" => OK
4. Go to vendor123 and set "Netherlands" as a country
5. Print RFQ again
Bug:
>> The address was still in format "123 Street" => NOT OK
When changing the country on a partner, the field street must be recomputed
because the street_format depends on the country.
opw:1865677
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
for computed street fields.
Qweb reports delete the node if the value is Null but won't if the value is an empty string. And then, l10n_mx_edi module has errors because there are nodes with empty string and the minimum value is one char.
Courtesy of Vauxoo. Was PR #17169
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
This module adds some extra fields to the partner model, in order to be able
to manage extended addresses. However, those extra fields were not present
into the company model, thus making partner's addresses and company's
addresses displaying somewhat inconsistent.
This change takes those fields that were already present into the partner
model, and adds corresponding fields into the company model and view, so
addresses from both models are now shown the same way.
Closes#16547
*street fields should be editable only if we modify the main partner address
*creating a res.city through the m2o should has default country and a domain
Odoo Translation Bot