8.0 add addresses mgmt

[gurneyalex]

Create 4 addons:

• stock_transport_multi_address
• sale_transport_multi_address
• purchase_transport_multi_address
• purchase_requisition_transport_multi_address

which work together to manage origin and delivery addresses, as well as consignees on company processes.

These modules unify and integrate what was previously available scattered in various more or less independent addons from differents OCA repositories:

• https://github.com/OCA/purchase-workflow/tree/8.0/purchase_delivery_address
• https://github.com/OCA/purchase-workflow/tree/8.0/purchase_origin_address
• https://github.com/OCA/purchase-workflow/tree/8.0/purchase_requisition_delivery_address
• https://github.com/OCA/vertical-ngo/tree/8.0/logistic_consignee

Needs merging together with:

• 8.0 purchase addresses purchase-workflow#110

[lepistone]

@gurneyalex I think the READMEs are a bit messed up: for example, the one for stock talk about sale.

[gurneyalex]

@lepistone: fixed, thanks

[bealdav]

Hi @gurneyalex, thanks for you module series but why they are in plural form ?
95% of the modules are in singular, why don't follow this convention easier to remember ?
Yes I know, these modules manages several addresses but sale module also manage several sales, at least I hope.
Technical folder name could be 'stock_address' and name display module could be 'Stock Addresses'.
Don't you think ? Thanks

[pedrobaeza]

I see better to put stock_multi_address to determine the plural meaning.

[bealdav]

@gurneyalex Have you considered to use this module
https://github.com/akretion/carrier-delivery-ak/blob/7.0/delivery_dropoff_site/__openerp__.py.
It seems the concept is near, consignee is like dropoff site
@guewen use it for so_colissimo

[gurneyalex]

@bealdav because we are dealing with multiple addresses (origin, delivery and consignee).
@pedrobaeza I don't find "stock-multi-address" more helpful or less generic.

Would you object to stock_transport_addresses? or stock_transport_address (but this sounds like the module only handle 1 address which it does not).

[gurneyalex]

@bealdav: regarding dropoff site

1. it's v7
2. it does not handle consignee or origin

[bealdav]

@gurneyalex thanks for your answer:

• delivery_dropoff_site: it handles consignee here https://github.com/akretion/carrier-delivery-ak/blob/7.0/delivery_dropoff_site/stock.py#L20 and delivery here
  https://github.com/akretion/carrier-delivery-ak/blob/7.0/delivery_dropoff_site/partner.py#L60. You're right my module is not really visible on ak repo, and some dependencies should be removed to join OCA.
• I don't know exactly what is the use case of your modules (example welcome). In the different addresses, is there different carrier providers. If yes, the module shouldn't be more generic if it supports to store in Odoo the specific carrier data (if any) with 'inherits' mechanism in these base modules ? I'm not sure of nothing because I don't know the use case, it's just an idea.
• about module name, your approach has its logic. But on my side, if I write a module called 'image' to manage images with a field image, I don't want change the name if I add a new field to manage other image types. I think (but maybe it's only me, and in this case, no problem) if i let the possibility to have plural, then I finish with less consistency (mrp_operations, res_groups for table). KISS could also applied to module folder name (you have summary to be more explicit and name in _openerp.py for plural and sound good). But if OCA says, we should use plural when it needs, Akretion should rename 98% of its modules. And then we'll do it.
  It just miss a convention here http://odoo-community.org/page/how-to to close my sterile debates as says @rvalyi ;-) [ EDIT: I just see convention is defined. I suppose 'prefer' will no close debates ;-( ]
  my 0.5 cts

[pedrobaeza]

I agree with @bealdav. At first, I fell in the same mistake naming my modules, but it is less consistency. You can call it stock_transport_multi_address if you want to specify a little more.

This is what I've done with product_images module, renamed to product_multi_image here: OCA/product-attribute#57

[sebastienbeau]

GREAT work Alex ! For the delivery_dropoff_site we can depend of your module without any problem. It's just that we need to take in account this change for so-colissimo (@guewen no sure that you need to do both colissimo and socolissimo).
For the module name I also prefered without "s". Even if there is many it's better (I think) to always use singular.

Thanks

[gurneyalex]

ok I'll update the names to xxx_transport_multi_address

[gurneyalex]

@bealdav I am about to create the 7.0 branch in this repository, and then I propose we work together on delivery_dropoff_site to get something which can be migrated to 8.0 to these modules (and if necessary amend the xxx_transport_multi_address modules to ease this migration) . Would this be ok with you?

[bealdav]

@gurneyalex Thank you alex, but on our side we will focus on the present and future -> v8. We only use this ddrop_off_site only for one client and it works in v7. When we'll migrate so_colissimo in v8 we'll add dependency on your module. Thank you for job with your full tested modules. It's also for that we want to depend from them.
cc @sebastienbeau

[nbessi]

two spaces

[yvaucher]

👍

[gurneyalex]

@yvaucher thanks for fixing the test

[nbessi]

👍 due to the high numbers of commit after first review pass, I think we should wait 5 days before merging

[yvaucher]

@nbessi In fact it was rebased so there are not that much commit in addition

@pedrobaeza @sebastienbeau issue due to naming of module was fixed is it ok for you?

[pedrobaeza]

Change this text to match new module names

[yvaucher]

@pedrobaeza Thanks, I fixed those README files

[pedrobaeza]

I think now it's ready for merging 👍