Orchardcore: Audit Trail module

[Piedone]

I just noticed it's not on the roadmap. What I'd imagine for an Audit Trail module is similar to what's in Orchard 1, but let's discuss what we'd like to see if not a re-implementation of that.

What I've seen with our clients is that the most requested feature, and what I'd imagine as a first implementation, is the ability to track content changes:

• See prior versions of content items (including deleted ones).
• Ability to restore previous content versions.
• Being able to see the diff between versions is nice to have.

What I'd imagine as needed eventually, but not necessarily right away:

• Detailed filtering, searching of events.
• Built-in providers for events not just related to content changes.

I'd imagine, just in O1, this would be designed in an extensible way that user modules can define and record their own events (and other but built-in modules would contribute their own events in the same way).

Related: https://github.com/OrchardCMS/OrchardCore/issues/506. What not do this time: https://github.com/OrchardCMS/OrchardCore/issues/178.

@sebastienros here you mentioned that "some company is already working on it". Can you tell more?

[sebastienros]

I don't know how the other company progressed on it.

First to ship wins.

[Piedone]

And if we don't do the same work twice everybody wins :D. If you could get in touch with them somehow that would be great.

[devlife]

Hi @piedone I'm hoping to get started on this late next week!

[Piedone]

Great then @devlife! Let me know if you'd like to exchange notes or something.

[Piedone]

@devlife Did you work on this in the end?

[devlife]

Hi @Piedone I have been super swamped at work and haven't even looked at this, unfortunately. I do have a client asking for it but am not sure when I'll have time.

[devlife]

@Piedone would you be willing to share your thoughts on this issue and how you might approach it? I might be able to wrangle some time at work over the next few weeks.

[Piedone]

@barthamark @domonkosgabor please chime in. It's for a client so we'll need to check what we can disclose.

[barthamark]

We've started working on this feature with @domonkosgabor . In the following days Gabor or I will write some software design ideas that we can discuss. All of your help will be appreciated.

[devlife]

That sounds great! I'd be super happy to help.

[domonkosgabor]

I am thinking about implementing the Audit Trail module based on the module that can be found in Orchard 1, but I found some interesting behavior when trying to add an implementation of the ContentHandlerBase, that will be responsible to log the different events when a content item has been published, created, etc.

Let's imagine a Page content type that has a FlowPart attached. And there is one widget added to the FlowPartof the Page. Now, let's publish this page. This will call the ContentHandlerBase three times:

1. UpdatedAsync: the context will be the widget to update.
2. UpdatedAsync: the context will be the page this time to update.
3. PublishedAsync: the context will be the page to publish.

This will record three different kinds of Audit Trail event, but if you get a closer look, you will see that there is no need to record the action in the first step, because every time when we update/publish/etc. the page, we have the FlowPart there and the widget(s) inside, so there is no need to record that the widget is updated because our goal is to log the history of the page.

I know that there are scenarios available to see the parent or the root element of a given content item. You can use the ContainedPart or @deanmarcussen has nice scenarios to do similar to the taxonomy and Autoroute routing. But in my case it's just a widget and the parent, the root element of this widget is a FlowPart that is attached to a Page content type. So, I think there is no simple way to find out that the context.contentItem is just a contained content item of a Page in this example.

However, there are different ways to find out that when we need to log the event or not:

1. The FlowMetaData is welded to content items inside FlowPart. In this case we can check that the content item has the FlowMetaData content part.
2. These widgets have no ContentItemIndex records, so, when using the _contentManager.GetAsync("contentItemId") method, we will get null.

My problem is that these are just different kinds of workarounds, maybe adding the stereotype to the JSON structure of the content item could be a solution, but I'm not sure about that either. What do you think about that? How can we filter what audit trail events should be recorded in terms of content items?

[sebastienros]

Let's try the VersionedAsync event.

[jeffolmstead]

I might have a need for this in an upcoming project. Does anyone have a repository where this is being worked on? I should be able to contribute code to the process.

[Piedone]

Not yet but we're working on it (again, since it's for a client, we can't just publish it right away).

[Piedone]

Still on it.

[Fermain]

@Piedone I am working on a client application that requires auditing as per Orchard 1

What is the status of this module, could we assist?

[Piedone]

Thanks, but not at the moment, this now is mostly an administrative issue that we're working through with the client of ours. We aim to have this ready in a few weeks.

What we have BTW is mostly a port of the O1 module, adapted and updated to Orchard Core concepts and features.

[devlife]

This is great news! Super excited to see it in action!

[sebastienros]

Someone should make a betteropen source version with a restriction for this customer to not be able to use it.

[Piedone]

They're a nice customer and they agreed to open it up :). In the meantime those issues were resolved and it's up to us to make it ready for public release. We're on it.

[jtkech]

Just to say that in #6054 i introduced a DraftSavedAsync event triggered when the content item has been validated and will be saved as a draft. This because UpdatedAsync (also VersionedAsync) doesn't mean that the content item has been validated, so the content item may not be persisted.

Normally PublishingAsync means that the content item has been validated, unless if e.g. a WF UpdateContentTask executed inline from this event does some other mutations that are not validated, that's why in #6054 i added more constraints in content activities to prevent this kind of scenario.

So PublishedAsync OR DraftSavedAsync will be the last event without any further mutations, and will mean that the content item has been validated and then will be persisted.