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.
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.
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)
This continues to more complex scenarios such as a component linked into RTF etc.
We currently hook into the
OnResetDefaultApprovalStatusevent 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)
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.
Removing the schema constraint - requires an ability to not have items flagged as unapproved
- Can we extend the
OnResetDefaultApprovalStatusto 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:
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**
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
undefinedwe could manually catch the publishing transaction and if we find any items with
undefinedwe 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.
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?