Extending Sitecore Approval Workflow

Why customize the default Sitecore workflow?

Sitecore is by default shipped with Simple Workflow covering simple draft – approval – publish scenario.

In this scenario, publish state of the workflow is set as final. This fact causes that when the content author needs to edit item fields, a new version of the item is created automatically, and changed content is subject to the approval process.

Some customers may need to extend this workflow by an additional state to control the moment when the item is published (and they don’t want to use time-based publishing) by adding the additional step between approval and published states.

The resulting workflow then looks like

draft – approving – approved – publish

with publish state as the only with final flag.

Everything looks fine, but…

… there is one unpleasant side effect. It allows content editors to change values of items in approved state without enforcing of creation of the new version.

How is the creation of new item versions handled?

If Sitecore needs to know if the new version of the item should be created, it asks the workflow implementation class to get the value indicating how to act during the checkout of the item.

The key method is IsApproved method on the workflow implementation. In standard Sitecore workflow implementation, it (a little bit simplified) checks if the current item’s state has IsFinal set to true. If IsFinal is set to true, the item is considered as published and the new version is created.

Unfortunately, this method is uses for two situations:

  • It is used for check if new item version should be created (called by item:checkout command)
  • Check if the item is eligible to be published (as part of publishing pipeline)

Which means

  • if “approved” state will not have IsFinal flag
    • item will not be published (this is OK)
    • if the content editor will check out this item, new version will not be created (this is not OK)
  • if “approved” state will have IsFinal flag
    • item will be published (this is not OK)
    • the new version will be created (this is OK)

So, overriding of this method is not enough for our expected behavior (we want to force users to create a new version, but not publish the item).

How to takeover item creation

To implement own logic for item version creation, we need to start at a different place – in item:checkout event handler. It is the place, where the logic if the new version will be created, resides.

One of the methods called from item:checkout event handler resides in the WorkflowContext, and is called StartEditing.

And here, the key point is IsApproved method – it calls workflow’s implementation method IsApproved (and checks the IsFinal flag).

For our purpose, we need to take over all of this mechanism, and customize it, because WorkflowContext class cannot be inherited or replaced by any suitable way.

Customizing Event handler

To achieve the desired functionality, we were forced to mix several methods for several places and create the following checkout command.

Check the function headers, it has the information from which this function was taken, and how it was modified.

The most important method here is RunClient, which was taken from the Run method from the original CheckOut implementation. It assures that if the item is in approved state and the current user does not have an approval role, the new version is created, otherwise original behavior is executed.

Methods CreateNewVersionInApprovedState, IsItemInApprovedState and IsContentApprover are service methods for internal checks or for the creation of the new version of the item, and other methods are taken from original implementations in 1:1, because they were private, or there was not possible to call them directly.

We were not so happy with this way of implementation, but it was the only way we found to implement customers’ requirements.

If you have some other idea on how to solve this problem, we kindly ask to share it in the comments :).

Leave a Reply

Your email address will not be published. Required fields are marked *