kbt180024

Issue

When trying to deploy a package containing K2 views, forms and SmartObjects, you get a conflict with existing item error for views, forms and SmartObjects and it is not possible to select the create new version option to resolve this conflict.

When clicking on the Configure button it is possible to see a "Conflicts: System Name" error message and notice that GUIDs are different for packaged and existing artifacts. At the same time you expect these GUIDs to be the same as you are deploying back to source from the target environment. This prevents you from deploying your changes.

Symptoms

The "Create New Version" option for SmartObjects was intentionally removed at the time of K2 4.6.11 when the system name OR the GUID is not the same. This change was made to prevent a bug that was caused by using the "Create New Version" option on SmartObjects and the decision was made to not allow manual CreateNewVersion on SmartObjects which are in conflict state, because there are scenarios where this can break your solution.

Below you can find reproduction steps which may help you to better understand this scenario (using the same test environment as target and source for simplification):

1. Create a SharePoint List called TestList and appify it selecting Data, Forms and Workflow options.

2. Then create a category called Test in the Root category and create a SmartBox (or any non SharePoint) SmartObject in it and generate Views (Item & List) and Forms.

3. Create a package and select the TestList and the Test category (so it will package all the new artifacts).

4. Modify SmartObject you created on step 2 adding new property into it and create new package including only test category.

5. Delete content of the Test category and deploy the package created on step 3. You will see the Map Service Instances dialog as soon as you start deployment which indicates that package contains SharePoint artifacts and Package and Deployment treats this as a solution. Sample screenshot illustrating Map Service Instances dialog:

Package and Deployment Map Service Instances Dialog

You will be able to deploy this package recreating deleted artifacts under the Test category but their GUIDs will be refactored as Package and Deployment which identified them as a part of SharePoint related solution.

6. Once the package on step 5 was deployed try to deploy the package created on step 4. You won't be able to deploy artifacts from the Test category due to GUID conflicts. Package and Deployment will be reporting a conflict with an existing item and when switching to Configure mode you will see that the GUIDs do not match and the Create New object option is blocked with "Conflicts: System Name" error and you are only able to use existing artifacts. Sample screenshots illustrating this:

Conflict with existing item due to refactored GUID

Conflicts: System Name error due to refactored/not-matching GUID

Resolution

There are two ways to resolve this issue:

1. Do not include non SharePoint related items in a package with SharePoint artifacts to prevent their GUIDs refactoring. But if you already run into errors/symptoms described above that means you already did this and need to rely on the second solution.

2. Include some SharePoint SmartObject(s) along with non SharePoint ones to ensure GUID refactoring and proper matching; thus making sure that you do not include them By Reference. If you do that then when you deploy, it will show you the Map Service Instance screen and it will refactor the GUIDs as it did with the first deployment was performed. That will ensure that the system name and GUIDs of the SmartObjects will match and will not be in conflict.

This behavior is related with the fact that Package and Deployment sees a package with SharePoint artifact(s) as a solution and refactors GUIDs of all artifacts included in such package. In this case you need to keep including SharePoint SmartObjects in the future packages to maintain GUID consistency.

If you deployed some non-SharePoint K2 SmartObjects for the first time including some SharePoint SmartObjects then in the future you always have to include SharePoint SmartObjects into the package with those SmartObjects even if they are not needed/have not been changed. This is required to ensure GUIDs refactoring. SharePoint SmartObjects need to be fully included in the package, while all the other dependent views and forms that have no changes, can be included by reference.