Content Workflow Coming to Dnn 10

The upcoming DNN 10 will have another long awaited jewel: Content Approval Workflow. 

What is Content Workflow in DNN?

In enterprise content management a common feature is that someone can create or edit pages, but that someone else is responsible for the final review and release of the changes. Here's a simple example:

1. My secretary changes the history page - basically adding some modules, re-ordering the existing ones and doing a lot more. Once she thinks she's done, she'll submit it for review.
2. I'll get notified, review the page, make some final tweaks and then publish.

Or more complex - imagine a large company which is listed in the stock market:

1. A junior marketing clerk makes changes to a page about the ongoing year. Once he's ready, he'll submit it for review.
2. The legal department is notified and reviews it, to be sure that it doesn't contain anything which violates rules of the stock-market listing. Once that's been done, it's submitted to the management for final review.
3. The management is notified, reviews it, and publishes the changes.

These two examples show a 2-step and 3-step approval workflow. 

How Does the Content Approval Work in DNN?

Internally DNN manages a list of so called Content Items which can reference a page, a module or even some module content. The system is quite complex - here's the DB schema for it:

When Content Approval Workflows are enabled, changes to a page (such as adding / moving modules) or changes to a module will notify DNN to create a new version of the page. This is all hidden, so the editor feels like he's still modifying the original page. 

But in the background the system will continue serving the old version to the public, while showing the new version to editors. 

Once the changes are ready for publishing, the content can be published, and the old version is archived, while the new version is then served to the public. 

Can We Define Who is Allowed to Publish?

Absolutely. This ties in with the new CMS Editor permissions which @tvatavuk completed a few months ago. Basically we now have 4 predefined roles for this. Note that the publishing restrictions only apply, if the feature Content Approval Workflow is enabled. 

1. Content Editor - can make changes, but can only request review (not publish).
2. Content Manager - can make changes and publish them.
3. Administrator (older Role) can do everything a Content Manager does, but also admin site settings, user logins and more.

This is why the new permissions were essential to finish this workflow feature. 

How will the User Experience be?

Here are some screenshows of the process when a (restricted) content-editor is working. Pay special attention to the bottom of the screen, which shows different buttons depending on the user, role and state the page is in:

Some Context & History...

Before we explain more, it's important to understand some context. DNN had features for Content Workflow built in since ca. version 7.0, but these features were hidden. I believe that this was because DNN Corp wanted to reserve this to paying customers, so the UIs and APIs to configure or use workflow were not included. 

Because of this, nothing was documented, but technically almost everything was there. 

It must also be noted that every subsystem or Module which intends to support Content Approval Workflow must implement an interface IVersionable to work. But since nothing was documented, none of the modules on the market supported IVersionable as the open source version of DNN did not do anything with it.

As far as we know, 2sxc was the only module on the market which supported IVersionable and Content Approval Workflow, because Evoq customers sponsored the feature for 2sxc 9 ca. 2017. 

A few years ago DNN was given back to the community but this feature was forgotten, until Tonci and I revisited it in 2023. Since then, Tonci has been working on this feature to make it available to the community.

What Works Out-of-the-Box in DNN 10.0?

If everything goes according to plan, Content Approval Workflow will be released in DNN 10.00 - see github issue. Initially, the following management features will work:

1. Configure Workflow on the Site and Page Level
2. Configure 2-Step, 3-Step and Custom Workflows
3. Setup user roles for Content Editor and Content Manager
4. Review a page to see what state it is in
5. Find all pages which are draft / waiting for approval

Here are some screenshots for this:

Only content which "participates" in the Workflow and Versioning will

• Trigger a workflow change
• be part of the workflow - so will remain hidden till published, and appear once published

For content to participate in the workflow, it must be part of the system features (pages, modules) or the module must implement IVersionable. So at first, these parts will participate in workflows as expected:

1. Page changes - this includes create, delete, move or even a name change.
2. Page structure changes - such as changing the module order, adding modules or removing modules.
3. Module changes such as Title, Container, Permissions will be part of the workflow
4. Module Content: only 2sxc will support content-versioning for the workflow at the start

What about Modules Which Don't Yet Support IVersionable?

If a module does not upport IVersionable, the experience will be a bit mixed:

1. Newly added modules will participate in the workflow, since the previous version of the page doesn't show the module. 
2. Removed modules will participate in the workflow, since the removal won't show up on the published / previous version of the page.
3. Changes to the settings such as title, chrome, etc. will be part of the workflow.
4. Changes to module contents will not be part of the workflow, until the module supports IVersionable.

What About the Built-In HTML Module?

The built-in HTML module has a bit of it's own history. An attempt was made to add versioning to it before DNN had the real Content Workflow. So the HTML module has it's own versioning system, which is not really compatible to the current setup. 

Because of this, the core group will have to decide what best to do with this and how to proceed.  

How Can You Update Your Modules?

For the final experience to be seamless, all modules which wish to be part of the workflow need to implement IVersionable. Specifically, your module must:

1. Notify the system that changes have happened, so that the Workflow can create a new version of the page and start the process. This is done by giving the ITabChangeTracker a message such as the TrackModuleModification.
2. Keep track of your own changes in separate versions of the content.
3. Respond to system events on the IVersionable such as PublishVersion.

You can see this code in 2sxc, but it will be hard to use that as a template, since 2sxc is so complex. We'll try to get a bare-bones code sample out ASAP.

Shout-Out to Tonci

All this has only been made possible because Tonci invested countless hours to make this happen. If this will make your life better, please leave him some thanks, a beer or even drop some DNN or NopCommerce work his way to Sistemi in Croatia.

With Love,
iJungleboy