Just like in the Zimfarm, we need to track the history of CMS objects configuration. While events are convenient to store what happens to an object in terms of processing, they do not maintain a history of configuration, they do not record who did configuration changes, and they do not allow to compare configurations.
We need that capability to store and view history for book, title, collection. This means APIs and screens, just like for the Zimfarm.
Events and history are expected to continue to live side-by-side since they are quite different (unless we identify an elegant way to merge them).
It means once this issue is implemented, all configuration changes must be done through the API (and not the DB anymore) so that we properly track revision history. I don't know if we already have maintenance script to update regarding this (I don't think so).
@elfkuzco I think this is ready to be implement, let me know if you have questions / suggestions.
Just like in the Zimfarm, we need to track the history of CMS objects configuration. While events are convenient to store what happens to an object in terms of processing, they do not maintain a history of configuration, they do not record who did configuration changes, and they do not allow to compare configurations.
We need that capability to store and view history for book, title, collection. This means APIs and screens, just like for the Zimfarm.
Events and history are expected to continue to live side-by-side since they are quite different (unless we identify an elegant way to merge them).
It means once this issue is implemented, all configuration changes must be done through the API (and not the DB anymore) so that we properly track revision history. I don't know if we already have maintenance script to update regarding this (I don't think so).
@elfkuzco I think this is ready to be implement, let me know if you have questions / suggestions.