RFC Moving Obeesdoo and Easy My Coop to OCA

[robinkeunen]

Obeesdoo was mainly developed by the BEES coop volunteers and Coop IT Easy. Because of that, the implementation bears the BEES name and follows closely the processes at the BEES coop. Obeesdoo depends on Easy My Coop, also developed originally for the BEES coop. Both projects started in 2015.

Today, 11+ cooperative supermarket and grocery stores in Belgium, Spain, France, Germany and Switzerland are using Obeesdoo and 25+ cooperatives are using Easy My Coop. Additionally other IT cooperatives (coopdevs, cooperatic) are starting to use and contribute to the solution for their own customers.

At Coop IT Easy, we believe it's time to go further than just applying the AGPL license and to really make this project Open Source. By that we mean

• bring together a community around the code,
• make the code easier to contribute to
• moving under the OCA umbrella

Why do it ?

• Raise the code quality to the OCA standards.
• Release the project ownership ;
• Become the reference repository for Share Management and Cooperative Supermarket with Odoo ;
• Make contributions easier for people outside Coop IT Easy ;
• Grow the project visibility and attract new customers and contributors ;
• Give a better understanding of the roadmap ;

What do we need to do ?

Required

1. Rename repositories and modules to more generic names
   • cf Analysis - rename repositories and module #248
2. Remove all references to Obeesdoo and Easy My Coop
   • in python code
   • and xml data
   • cf Remove obeesdoo and easy_my_coop references #249 (archived)
3. Add demo data to demonstrate basic flows
   • cf Demo data and unit tests #250 (archived)
4. Cover main flows with unit tests
   • cf Demo data and unit tests #250 (archived)
5. Refactor code:
   • tasks already listed in Coop IT Easy's odoo
   • todo and fixme comments in the code

Improvements

Obeesdoo

1. Split modules by feature rather than by app
   • modules by feature can be expatriated to the other OCA repositories
   • modules by feature can be installed only for customer needing it
   • modules by feature are easier to maintain and migrate
2. centralize configurations : today configurations are set on the company, in res.settings, in module "configuration" menu and in other places. Gathering all configuration in one place would be more confortable and consistent for users (UX).

How

The migration will be done incrementally in the order given in the previous section. Each improvement will bring its migration script relying on the OCA Open Upgrade Library.

Following the OCA Repository Policy, the repositories and module will be proposed as

• Topic repository for Easy My Coop - Share Management
• Vertical Repository for Obeesdoo - Cooperative Supermarket

The repositories will be marked as Incubation Repositories. The modules will be marked with the beta maturity levels because, even though they're used in production, they will be heavily refactored.

As we split and improve the modules, some might be extracted to the relevant main OCA repositories (Sale, POS, ...).

In the long run, they should contain only the specific features needed. Features also relevant for other use cases, outside the vertical’s perimeter, should ideally be extracted and moved to the appropriate Main or Topic repository.

Financing

Coop IT Easy received a subsidy from the Bruxelles Region to foster intercooperation around the digital commons. This subsidy will cover three endeavours:

1. Bring together a community of users (cooperative supermarkets) to co-finance their ERP solution ;
2. Build a community of developers to collaborate on shared code ;
3. Make the Easy My Coop and Obeesdoo modules easier to collaborate to.

This RFC describes the work needed in the 3rd item. The subsidy will cover the costs of 80 days of development and tests by Coop IT Easy.

The subsidy runs from July 2021 to December 2022

Resources

OCA Repository Policy

PYSI project summary (french)

[houssine78]

Just one remark moving the configuration From company to res.config will be a downgrade in the sense that you won't be able to have a different configuration for two companies in a multi company context.

I'll propose to move what we think will be more or less always the same configuration in a multi company database

[robinkeunen]

Feature analysis of existing modules and proposed new module structure:

by *@remytms* @robinkeunen and @polchampion

[robinkeunen]

I did not display dependencies to standard modules because it added too much complexity but many are redundant.

We will also need to decouple the modules, most importantaly by removing the dependencies to beesdoo_base and beesdoo_product where possible.

[robinkeunen]

With odoo standard dependencies (messy)