[RFC] brand, the path forward

[sbidoul]

Hi,

We currently have two independent approaches for brands in OCA:

• partner_brand, account_brand, sale_brand which basically mark some contacts as being brands and replace company information in report headers/footers with brand information is available
• product_brand which assign products to brand and adds that in some pivot tables

We have more requirements for brand (such as defining receivable/payable accounts by brand, or adding multi-company support on brands) for which neither approach is totally adequate. For that we need a separate brand object, since extending res.partner will be confusing and will not work in the long run.

So the first step we propose is as follow:

• update partner_brand to create a brand object with delegation inheritance on res.partner, with migration scripts
• update sale_brand and account_brand, with migration scripts
• add a dedicated menu for brands next to Companies in settings, with dedicated views

This is not perfect, but it's a first step to evolve what is merged today. Further down the road we can consider making product_brand depend on this new brand model, and possibly replace the delegation inheritance by something else.

@max3903 @pedrobaeza any opinion on this approach?

cc/ @sbejaoui

[sbejaoui]

New model res.brand: #766

[sbejaoui]

Update for sale_brand #920

[sbejaoui]

Update for account_brand #577

[pedrobaeza]

Should we create a new repo OCA/brand? And about the model name, why res.brand?

[sbejaoui]

I thought that brands can be seen as system resources and in the same registry like users, companies, partners, .. Le ven. 16 août 2019 à 22:28, Pedro M. Baeza <notifications@github.com> a écrit :

…

Should we create a new repo OCA/brand? And about the model name, why res.brand? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#765?email_source=notifications&email_token=ADAUEQMXRUSGFLS6LOUCWA3QE4EXPA5CNFSM4IMGHXUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT5MI#issuecomment-522141361>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADAUEQMVSUCSIMBH4HWW47TQE4EXPANCNFSM4IMGHXUA> .

[max3903]

Looks like we are doing the same as Odoo: We discuss a topic publicly but internally the decision seems to be already made and the job already done... :)

Anyway, I don't have any strong opinion about where and how the repo/module/object is named/developed. What matters is to maintain the same scope for our current customer.

If @acsone takes the leadership of maintaining the repo/modules, you can do as you wish. What I would like to know is whether you will take:

• a passive role where we create issues with requirements and designs and submit pull requests that you review
• an active role where we create issues with requirements and we pay you to estimate, design and develop and we review/test.

Thank you.

[sbidoul]

job already done

Eh eh sometimes dev goes faster than I think. Nothing is done, no worries the PRs are up for discussion.

To clarify the context, I created this RFC following design comments that were made by myself and @pedrobaeza on #754. We have additional requirements that make it necessary to evolve the current data model. We think the requirements are generic enough to propose to OCA.

What matters is to maintain the same scope for our current customer

What we are proposing do indeed change the datamodel but keep functionality and come with full migration scripts, as well as a longer term roadmap described in this issue, to make it as easy as possible for your customer to migrate.

I'm mentioning you to get your input in the hope to find a robust design for everyone.

Regarding the passive/active role, and "doing as we wish" I don't understand what you want to say exactly.

[sbidoul]

res.brand

I tend to think the res prefix is reserved for Odoo core. Why not simply brand?

new repo OCA/brand

@pedrobaeza a new repo would make sense. Now or for v13? Should it be a new PSC too, or do you think an existing PSC could take it in charge?

[pedrobaeza]

If @max3903 agrees, we can do the repo now. As for PSC, I would detach it from other PSCs, as it's very transversal (product, invoicing, sales...).

[max3903]

+1 for the new repo

[NL66278]

I completely agree with the roadmap and the new repo. One of our customers had its own solution for brands (called sales.channel by them), based on partners with extra attributes. This caused lots of problems. Having a separate brand, or res.brand whatever, model makes much more sense.

[NL66278]

As the new repository has been created, and already has the proposed modules, I close this issue here.