[RFC] Reading yml file or directly from DB

[elicoidal]

Hi,
Currently the workflow content is read from a yml file. I was wondering what was the reason of such a technical choice?
I would have expected something similar to v8 workflow structure: store and read the data in a model in the database.
Was there a constraint from the project or is there any reason we should consider?

Our project requires to have dynamic workflow management similar to v8 behavior (modify the workflow in Odoo and use it without restarting the instance).
We are willing to develop a module (to be technically agreed upon) to achieve this (store and read the workflow content from the DB): do you think it is a good idea and would you accept the contribution?
cc @joycehuan

[sbidoul]

Hi @elicoidal,

I initially stored the statechart in database: it proved very tricky to get completely right. Allowing workflow modifications without server restart is even harder.

Branches 9.0-alpha and 10.0-alpha still contain this code. They work, but not are not as robust. They probably do strange things if you change the statechart at runtime.

So since this was half baked and finishing that path properly would have been very time consuming I decided for a simpler, more basic solution (with the downside it requires a server restart).

Things that were hard in my memory:

• loading the statechart from database soon enough to be able to properly do _sc_patch (in short, when _sc_patch needed to be applied, the registry was not ready enough to load the statechart)
• injecting sc_XXX_allowed fields
• unpatching methods when the statechart changes

Also pay attention to statechart changes: if you remove states or otherwise do significant changes to the statechart you need to migrate existing records to be compatible with the new statechart. That was true with the old workflow engine too BTW. So IMO not something you put in the hands of end users.

[elicoidal]

@sbidoul
Thanks for the feedback.

In summary, it is "possible" to retrieve the code in v10 to store in the DB (with some drawbacks) but anyway would require that the server is restarted after modifications.

We will discuss internally if it is worth the effort!
Thanks again for this great modules

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.