[16.0][MIG] shopinvader_sale_profile

[qgroulard]

Partial migration of shopinvader_sale_profile.

Depends on https://github.com/shopinvader/odoo-shopinvader/pull/1441 for the extraction of _get_price().

Concept

The idea is to split shopinvaler_sale_profile into 3 modules:

• shopinvader_sale_profile: add shopinvader.sale.profile model and a function to compute the sale profile of a partner.
• shopinvader_search_engine_sale_profile: link sale profiles to se.backend and add a key "price" in product schema with prices per sale profile.
• shopinvader_api_sale_profile: Plug sale profiles to the address api to be able to expose the sale profile for a given partner.

Open questions

I don't know what to do with backend company_id field. shopinvader.backend used to be company dependent, up to now se.backend is not. Some features depended on the backend company. What should we do ? Drop those features ? Implement multi-company in shopinvader_search_engine ? Elsewhere ?

Remarks

• Previous implementation was designed to be compatible with "customer price". This should be reconsidered when (if ?) customer price is migrated.
• For simplification purposes, not possible anymore to configure some se.backend to work with sale profiles and some without. Should we reconsider this ? Then we need a common ground between shopinvader_search_engine_sale_profile and shopinvader_search_engine_product_price. -> 'Common ground' could simply be to name the 'price' keys in schema differently.
• Case of multi se.backend: To get a partner's sale profile for a specific se.backend through the API, the se.backend must be known and passed in the context when sale_profile_id is computed from the partner. Correct computation is then handled in shopinvader_search_engine_sale_profile. But up to now no mechanism is in place to be aware of which se.backend we want to work with from the API.

[qgroulard]

@sebastienbeau @lmignon I would be glad to have your opinion on this PR.