Hexya community

[soriyath]

Hello Nicolas,

First of all I would like to congratulate you on your effort and your approach on Hexya.
I couldn't agree more on the latter and your choices with regards to the licenses.

I was a bit taken aback you seem to be doing this alone. Kudos to you!

Would you consider letting the community help?
Should you want to do so, would you consider documenting the project or a wiki a bit more?
We'd probably need guidelines and a bit more in-depth guidance and a channel to discuss topics.

I personally have no experience in Go but do have a few years of enterprise programming in my backpack. Provided there are units of work that I could work on, I'm ready to commit a bit of code every once in a while.

Thank you for your time and good luck with this endeavour.

Soriyath

[npiganeau]

Hello Soriyath,

Thanks for your interest in Hexya.

Yes, any help would be very welcome. Yet I'm aware that, up to now, potential contributors have probably been reluctant because:

• I obsess about sticking to Odoo as much as possible until we have a fully working ERP before thinking about diverging features. This is because I want to be able to port Odoo's large business code as explained in the Design Doc
• Learning curve is very steep:
  • The framework itself makes massive use of reflection + code generation to be dynamic yet type safe.
  • A good knowledge of Odoo and its framework is almost necessary to understand where I'm going

If you are not afraid by the above disclaimer, welcome !

First part where I would need help is exactly what you mentioned: assist me in making this project more community friendly. All the doc I have written is in the /doc directory (synchronized to http://hexya.io/docs/). Which way should I go to add some more ?

Project roadmap in the coming weeks/months is to seriously port the first Odoo modules, by order of dependency :

• base, web and baseSetup are ported
• bus and mail are the following on my list
• from there we can start porting the main business modules account -> sale -> stock -> purchase -> mrp, ...

Porting modules is IMHO necessary to attract a community, because before that, it's just a framework with specific features, but lacks real interest. But when we have business modules ready, we will start having a usable product.

Unfortunately, porting modules is long and boring...
We have a tool in the OTH repo to scaffold modules from Odoo to Hexya that has been developed by a trainee. It works more or less, but is a good start. But the main work is to port all function bodies from python to Go, and port the tests too.

[blaggacao]

3.2. Static configuration

❤️ ❤️ ❤️

[npiganeau]

I've just opened a gitter at https://gitter.im/hexya-erp/community
I'll put the badge in README.

[asim-basraa]

this is a very brave and right initiative @npiganeau !! i really wish you best of luck.
On the point of attracting community, i think if you could make it possible to write UI in react/vue or any other famous frontend frameworks i think community will come.
And in order to do that what you could really do different from Odoo is
1- to offer a very stable rest API interface to Odoo core(Hexya i meant) written in Go.
2- provide a good support for component-rich rapid form/reports development libraries like react-admin (which can also be extended to meet Hexya requirements, if required). As for my case, i am running odoo for couple of clients but i am looking or more UX flexibility which Odoo doesn't provide.
3- provide a good support for a reporting/KPI frameworks.

And this wonderful project will attract more users. Your in depth knowledge about business processes will reflect in Hexya-core and its Rest API interfaces and Odoo's modules will be ported in no time if rest API is provided to community.
This is my humble 2 cents, i am by no means expert in any of above or in enterprise applications.

Last but not the least, i am interested in contributing to this excellent idea. how can we talk more about it?

[blaggacao]

1- to offer a very stable rest API interface to Odoo core(Hexya i meant) written in Go.

Graphql! - so "very stable" is for free without limiting evolution.

[asim-basraa]

Graphql! - so "very stable" is for free without limiting evolution.

Indeed Graphql is better choice, totally agree.

[sylnsr]

Since Odoo is moving to OWL which is sort of based on Vue, I hope that you will also move to a Vue based UI and get away from QWeb. Currently I am working on a project called Odoo-In-Vue with the end goal of making it a 100% Odoo compatible client app that is a 100% Vue project. It uses the JSON-RPC, because it can be found in earlier versions of Odoo that do not have GraphQL support.

I think its necessary to support the JSON-RPC API with Hexya so that it will be easier to eventually migrate people that are still on older versions of Odoo, to Hexya. Many clients still have RPC API scripts for ETL that will still need to work after they switch to Hexya, but it also means that my Vue project will also work with Hexya.

On a side note, if I can get financial support to complete Odoo-In-Vue so that its 100% Odoo compatible and Hexya compatible, I would be glad to set whatever license would be best, so that it can be freely distributed with Hexya.

Project site: https://www.odooinvue.org

[blaggacao]

For the (an evolution of the) expression language, you might have a look at https://github.com/google/cel-spec as replacement for https://github.com/hexya-erp/hexya/blob/master/src/models/conditions.go - just discovered it and thought of you.

[damendieta]

@npiganeau I know it's really hard to have this project by yourself, but I think there is enough interested people to have it on road.

If you are willing to continue with the project, I can commit myself to migrate the hole account module.

Can you give us any comment about the project and if you are willing to continue with it?