Issue with forcing items (using schema flag) through workflow bundles and content porting

Question

Background

We have the flag on the schema selected to force an editor to have to push components through workflow; when this is checked, a new component will not attain a full version number (1.0) but only minor version number(s) until it's been through a completed workflow process.

This was set-up for a few reasons including

• remove the setting of components to unapproved which would cause publishing to fail and not just publish the last major version (to PRD)

• force editors to put items through workflow (primarily to remove the first issue)

This works well if we add new Component called faq to be checked

• it will appear as version 0.1
• it can't be added to another component (as the GUI won't display non-full version items)
• it can't be added as a CP (as the GUI won't display non-full version items)
• the user is prompted to add this to a workflow bundle every time they open it

Similarly, when we add a new container called faqs it works as expected.

In the manual process this works perfectly well, as noted before we will now bring Content Porter into the equation.

Scenario:

Now, in our scenario, we use Content Porter to port into an environment with workflow and, yes, the schemas are set to force items based on them into a workflow bundle.

1. Updating and new items

   1.1 We've got a new FAQ

   1.2 We've made an update to the container (adding the new FAQ)

2. This continues to more complex scenarios such as a component linked into RTF etc.

3. We currently hook into the OnResetDefaultApprovalStatus event to detect if a new item is created as 'undefined' and change this to 'unapproved', both of which are enumerated (system) values. This is done because leaving items as unapproved causes publishing to fail (hence forcing editors to push them into a workflow bundle process)

Challenge

• The result is that the Content Port isn't successful (or complete if errors are ignored) as the container does not see/contain the new (minor-version) item

• This makes sense as we can't manually add an item that doesn't really "exist" yet - but it's not what we want!

In a fully manual system, we'd simply ensure that the FAQ was created and passed through workflow and then it could be added to the FAQ Container - but we don't want to have to break Content Porter packages into the smallest size to manage dependencies like this.

Options Considering

Removing the schema constraint - requires an ability to not have items flagged as unapproved

• Can we extend the OnResetDefaultApprovalStatus to include (config controlled) enumerated values that match our own; This post suggests not but we're not sure if this is still the case (will revert when testing had been done - or someone in the know comments)

Force items through workflow

• Catching the creation of an item in this event and firing off a workflow process to simply give this item a full version number - and potentially an approval status of something less that staging

  • this would mean new content would have a version of 1.0 and therefore can be seen but:

    1. We would remove the schema flag to force through a workflow bundle as this is only executed after the item has been created so the implications are that we would have to import items extremely structured such that leaf nodes are first etc. which may not be manageable**

    2. If there's a Content Port of several hundred new items - this will likely have a very detrimental impact to CMS performance - even with a tiny workflow process!

Custom Resolver Extension

• Perhaps if we leave the approval status as undefined we could manually catch the publishing transaction and if we find any items with undefined we fail the publishing transaction for that specific target - in our case, PRD LIVE.

• Combined with a custom page to list all items with a workflow approval status of undefined we can then keep track of these before getting to the point of failing in PRD LIVE.

The Question

• What other options could we consider?

• Are my assumption/fears above sound

• Does this NEED to be this complex or are we just missing something!

  • the OOTB solution works brilliantly for us - the core problem is the conflict in content porting and the referential integrity based on versions less than one! Is there some config value to allow minor versions to be linked in porting etc. that we've missed?

Answer 1

Taking into consideration some more research and also points made in this post, the end solution will be:

• (use code to) switch off the workflow enforcement on relevant schemas whilst a content port is in progress
• perform the import
• (use code to) switch the enforcement back on after the content port

We've had to introduce processes/checks to ensure that no-one sneaks in and adds/updates content whilst a content port is in progress and the enforcement is not being enacted - and we're still looking at the best combination here.

We did try, during the import, to intercept the various processes and prior to Save > Initiate > Finsh but it seems that the check against enfrocement in the schema is undertaken and enacted on before anything we can hook into in Content Porter.

Answer 2

Going by the scenario that you have shared, there are two options that I would consider:

1. While publishing, determine that component has not pass through workflow and fail publishing however it is not very intuitive approach as you will know about the result after publishing. (You have already described this approach of using custom resolver)
2. Other approach that can be considered is leveraging coreservice to port the content. The steps to be followed here is, use core service to read the component from source environment and then save the component on the destination environment. While saving there is an option to keep component checked out, which will create minor version for you to process through workflow.

Hope this helps.