[14.0][MIG] base_location: Migration to 14.0 #1003
Conversation
… when company country is filled.
…ssues with module partner_address_street3
…some views. Added two columns in respective tree views.
…ooks * Added Icon. * Improve module description and extracted to README.rst. * Pass country instead of country_id for advance comparisons. * Allow to transform city name. * Some code style. * Do not remove all entries of a country, but only not found. * Include hooks for transforming some things. * Include spanish translation.
Brussels Belgium city
…y, state and country in order to allow search using '%' from the m2o widget
* Headers shortened * Move cities management to settings
* [IMP] base_location: Add lat & long to `better.zip` * Add latitude and longitude columns to `better.zip` * [IMP] base_location_geonames_import: Add lat/long * Add support for latitude & longitude to genomes importer
Incredibly not included in Odoo core.
Currently translated at 66.7% (24 of 36 strings) Translation: partner-contact-11.0/partner-contact-11.0-base_location Translate-URL: https://translation.odoo-community.org/projects/partner-contact-11-0/partner-contact-11-0-base_location/es/
Currently translated at 100,0% (36 of 36 strings) Translation: partner-contact-11.0/partner-contact-11.0-base_location Translate-URL: https://translation.odoo-community.org/projects/partner-contact-11-0/partner-contact-11-0-base_location/de/
This module has now been refactored to be more consistent with what base_address_city offers to the location management. Added dependency to contacts so that I could change the menu location for cities / zip management. Now, every res.city record has a relation One2many to res.city.zip (old res.better.zip). This way, every zip has a realted city too. Zips can be searched through city code, zip or city name (same as before). Modified tests and deleted not needed tests. Added sql contraints so that zips and cities are unique within it's country / state / city.
Steps: - Open company form - Set 'city completion' field Get 'The state of the partner My Company differs from that in location X' Disabling _check_zip while writing 'zip' fields from company, as incompatible with the sequence of write operations. Automatic test is added too.
Currently translated at 57.6% (19 of 33 strings) Translation: partner-contact-12.0/partner-contact-12.0-base_location Translate-URL: https://translation.odoo-community.org/projects/partner-contact-12-0/partner-contact-12-0-base_location/es/
* Don't need cities for migrating Previous script required to have cities populated for working, but that's not usual thing, as people in v11 may choose to not import them, and for older databases they even weren't that option. With this improve script, now we populate city table for ZIP entries without city, so the rest of the queries are properly executed in any case. * Cover case of res_better_zip w/o country_id * Avoid error on null zip numbers
* Standard procedure * Change v13 specifics * Adapt tests + correct some practices
|
Correct functionality test |
|
Sorry if my question is stupid... I haven't followed the development of base_location since v12. Why do we need the res.city.zip object ? I really don't understand the role of this object: res.city is enough, isn't it ? |
|
Another question: res.city object has a zipcode field (cf https://github.com/odoo/odoo/blob/14.0/addons/base_address_city/models/res_city.py#L13), and that field existed since the beginning of base_address_city, but its value is not set by base_location_geonames_import, cf https://github.com/OCA/partner-contact/blob/13.0/base_location_geonames_import/wizard/geonames_import.py#L98 |
|
FYI, as geonames.org is down (https://download.geonames.org/export/zip/ is empty), I can't test easily the base_location + base_location_geonames_import modules... which makes things more difficult. |
|
@alexis-via Geonames is up again. About the data model, it was the same in v12. The idea of the refactoring of this module was to have a normalized data model, where there's an specific model that represents a city, not a city + zip. Your colleague @rvalyi claimed for it sometime ago in v7/v8. Then, we have a cardinality of 1..N from city to zips linked to that city. There's an ongoing conversation in #1020 for relaxing current constraint for having a hybrid data model. I'm finishing the conversion to computed writable for having it as example for things like OCA/odoo-community.org#50. I will write back when finished. |
|
I'll study it more in depth and talk with @rvalyi about it. Now that geonames is back up and running, I will be easier for me to test. I'll see if I arrive to the conclusion that res.city.zip is needed or if it should be dropped. |
|
Just to facilitate the debate:
|
|
I have adapted the code to new computed writable fields for depicting the possibilities. Please take a look to this new "style", and if you give your blessings, I finally merge this. |
* Adapt code to this style * Adapt tests and use Form for mimicking UI behavior
pedrobaeza
force-pushed
the
14.0-mig-base_location
branch
from
32befed
to
4a71fae
Compare
|
This PR has the |
|
|
||
| This module introduces a zip model that allows you to manage locations in a better way. | ||
|
|
||
| The zips will allow the users to complete automatically all address-related fields by just filling the zip. |
There was a problem hiding this comment.
Actually not all address related fields. You will not be able to fill in house_number and door_number from the zip. In most countries also not the street. Maybe replace 'all' with 'many'?
There was a problem hiding this comment.
AFAIK, that fields are added through extension modules, so it's OK to say that with current dependency set.
There was a problem hiding this comment.
It is only a minor point anyway. Very glad with the module as is. But street is also not filled automatically, and this is definitely also address related.
There was a problem hiding this comment.
Yeah, I get your point about the street, although it's impossible to fill a not known data derived from the ZIP. If I read the text, I understand that the "address-related" text refers exactly to this: the address fields that are linked with the ZIP, not the non related ones, and street (and the others) is not related, as a ZIP code contains a lot of streets.
|
Can I merge? |
👍 |
|
I talked with @rvalyi about res.city.zip object, and he told me that we doesn't use base_location in Bazil, so he's not concerned about the issue. |
|
OK, I still see valuable this structure as base instead of the base_address_city one. You can propose if you want the other module to OCA for having both options. Merging this one: /ocabot merge nobump |
|
What a great day to merge this nice PR. Let's do it! |
|
Congratulations, your PR was merged at f3238eb. Thanks a lot for contributing to OCA. ❤️ |
|
Unless if somebody explicitly says in this thread that he's interested in removing the res.city.zip object and in the associated simplification of the code, I think I'll publish my module base_address_city_geonames_import for v14 under akretion/odoo-usability (I'll do that probably tomorrow). The extra work needed for publishing in OCA is not worth it if I'm the only person interested. |
|
I just published my new module base_address_city_geonames_import in a dedicated Github project: As a consequence, I'll stop maintaining l10n_fr_base_location_geonames_import in OCA/l10n-france (I'll move the equivalent code elsewhere). |
|
@alexis-via I interessed to have this module in OCA. |
invisible>attrsin view@Tecnativa TT26286