document history/versioning in Core

[aruizramon]

A few open items for discussion:

• What interval do we want the comparison/sorting to be on?
• Do we want to keep the version trail if a document is deleted, or delete the history as well? The latter is already built.
• Opt-in for versioning...currently it's module-by-module in a doctype "Document Versioning Settings". We could just as easily add a check in DocType.
• The test is one long test covering both insert and update. It's hard to break it up since insertion can be tested in an update test anyways.

[rmehta]

Why call this temp?

[aruizramon]

It is, by definition, temporary.

Since actually figuring out which fields have changed shouldn't happen right when the user saves (can take too long), the old and new versions of the doc are dumped (as JSON) into the doc_history_temp entry. A worker queue processes these entries on whichever interval we decide on, makes the appropriate history entries, and then deletes the doc_history_temp record.

[rmehta]

But does the user expect the changes to be shown instantly? Also is there a UI compontent to this?

[aruizramon]

To your first point...I don't think so. Obviously, when testing this out, the user wants to see immediate feedback. But how many actual use cases are there when a user changes something, then immediately needs to see feedback for, as an example, pricing history? I think the short queue is plenty fast for real use as a tradeoff to avoid longer save times. Of course, if you feel otherwise, it's trivial to switch it to make the entry before save() is complete.

There is no UI component to this. There definitely could be reports built into the product in the future, but that's a whole new topic.

[rmehta]

Better make a "Single" type doctype instead of a page?

[aruizramon]

This is a single doctype - the html is just a display layer.

Due to the nature of users having modules in custom apps, and possibly needing to keep a history trail, getting all modules that exist and displaying them makes more sense. It's definitely crude, but it's an implementation with very little dependencies.

[rmehta]

@aruizramon can you add some screeshots, use cases on how the user will view, update history?

There is also a Version DocType I created a long time back that saves all versions (as JSON). Can we extend that?

[aruizramon]

@rmehta definitely.

I don't think users should be able to update the history at all - seems like each entry should only have delete permissions for the admin rather than edit.

The Version DocType looks like it's only creating entries for the Website module. I'll dig a bit deeper there and see if extending it makes sense.

[rmehta]

@aruizramon can you add some UI / screenshot on how the user can view the history / changes?