3

There is a Sitecore 10.2 instance with serializations delivered via Sitecore.CLI v4. Item changes delivered via package and installed using the following command:

dotnet sitecore ser pkg install -f "$(System.ArtifactsDirectory)\serialization.itempackage" --client-id "$(sitecoreClientId)" --client-secret "$(accSitecoreClientSecret)" --cm "$(accSitecoreContentManagementHost)" --auth "$(accSitecoreIdentityHost)" --publish

The package contains custom security roles that inherit standard Sitecore ones (like Author etc.). When the roles were included into package for the first time, they were successfully delivered to CM. After few deployemts (not the next one), package installation kills them:

[role] [D] Role ***\MyProj Content Editor is removed successfully
[role] [D] Role ***\MyProj Limited Content Editor is removed successfully

The roles are still in the package under <module-name>/items/_roles/sitecore directory. The serialization files look the same as in the initial package. What may cause such a behavior?

Improve this question

1 Answer 1

Reset to default
4

We encountered a problem very similar to your question. We started experiencing the issue once upgrading to 10.3 and CLI 5.1.25. In our case, the problem was caused by using a relative file path in defaultModuleRelativeSerializationPath like ../../serialization in the project's sitecore.json file.

When using ser pkg create this causes the package to construct a corrupted file path for serialized roles within the package (zip) file. Thus the roles are interpreted as empty by ser pkg install, dropping all the roles afterward.

Package file opened with WINRAR to see file contents

Package file opened with WINRAR to see file contents

The solution for us was not very straight forward since:

  • The construction with pkg create and install ran apparently stable for a long time.
  • You can override file path serialization on the module level, however, you cannot do that for roles.
  • Changing it in the root sitecore.json will cause issues for all modules.

We ended up adding a new sitecore.json config file to the project. In there correcting the defaultModuleRelativeSerializationPath to just "serialization" and moving the serialized roles into the folder where the actual module is located. Afterwards calling ser pkg create with the extra --config parameter referencing the duplicated sitecore.json file for creating an itempackage just for roles.

Improve this answer
2
  • I've also documented similar behavior when the defaultModuleRelativeSerializationPath is set to something like "items". When I created the item package, all of the standard content ended up in a folder named serialization regardless of the sitecore.json configuration. The roles, however, respected this configuration and were put into a folder named items. When I changed the the defaultModuleRelativeSerializationPath to "serialization", this allowed the roles to be installed within the content package.
    – Chet Cheeto
    Commented Nov 16, 2023 at 22:04
  • Additional note: as @ChetCheeto mentioned, when a package is generated, SCS packages the items in the serialization folder. However, SCS leaves roles in the path specified in defaultModuleRelativeSerializationPath . When you install the package, SCS only uploads from the serialization folder and therefore ignores the roles, but since they are defined in the module.json file(s), it deletes them from Sitecore. The takeaway is that you should use the default path settings if you want to serialize roles.
    – Marcel Gruber
    Commented Nov 17 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.