Kentico staging module - how can I prevent role synchronisation removing users from roles at target

Jeffrey Martel asked on September 29, 2021 07:09

I have already raised this question with Kentico devnet and Kentico support and haven't yet received a solution. I'm hoping the wider SO community will come up with something.

For reference, here is the devnet thread: http://devnet.kentico.com/questions/content-staging-how-can-i-stage-role-changes-but-ignore-user-changes

To summarise, I'm building a large multi-site web platform using Kentico. The staging module is configured to deploy Kentico object changes through a linear chain of environments from dev to UAT and on to production. Each of these environments naturally has a different set of users. Therefore I've excluded users and user-role relationships from the staging process as follows:

public class KingspanUserEvents : CMSLoaderAttribute { public override void Init() { UserInfo.TYPEINFO.LogSynchronization = CMS.DataEngine.SynchronizationTypeEnum.None; UserRoleInfo.TYPEINFO.LogSynchronization = CMS.DataEngine.SynchronizationTypeEnum.None; } } However, I'm finding that when changed roles are logged as staging tasks, part of the serialised role data is its user associations. Remember these users will be users which only exist in the source environment.

This has the effect that when the environments are synced, the role is updated at the target and all users are removed from the role.

Kentico support say "We are already aware of this and it is on the list of future improvements.". However, to me it's a fundamental flaw in a CMS which has enterprise aspirations. A failure to maintain a separation between the application architecture (roles) and live data (users) means that I cannot create reliable deployments for a core part of my application.

So my question is, has anyone found a work-around for this issue? I wonder if it might be possible to hook into the StagingEvents.ProcessTask.Before event handler to somehow prevent users being removed.

Recent Answers


Dmitry Bastron answered on September 29, 2021 08:58

Hi Jeffrey,

Unfortunately, I don't think there is any workaround for that, as this is embedded into CMS code, i.e. UserRoleInfo class doesn't have SynchronizationSettings defined, meaning it's using IncludeToSynchronizationParentDataSet property set to Complete. This behaviour cannot be overridden in any events I'm afraid.

If you desperately need this, I think you can purchase CMS license with the source code and change it as you need it to work.

The reality however is, how many times do you release functionality that requires Roles to be changed? Typically, Roles are quite static, although could be different between the environments. And keeping this area out of the automation pipelines normally is ok.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on September 29, 2021 11:31

I would recommend e.g. not logging the tasks for the user and role objects to keep them "different" across the environments. Or, you can try changing the staging configurations. Note, this was not fully tested and it is just a proof of concept!

Be very aware of all changes you make to TYPEINFO as it may completely break your whole site. Register a custom module and change the staging configuration e.g. to IncludeToParentEnum.Incremental. The data of parent objects includes all existing child objects of the given type. Import/staging adds new child objects or updates existing ones. Does not delete child objects that exist on the target instance, but are missing in the data of the updated parent.

    protected override void OnPreInit()
    {
        // change the configuration of TYPEINFO
        // DO NOT change any other properties of the TYPEINFO objects and be very careful with all changes you make
        UserRoleInfo.TYPEINFO.SynchronizationSettings = new SynchronizationSettings()
        {
            IncludeToSynchronizationParentDataSet = IncludeToParentEnum.Incremental,
            LogSynchronization = SynchronizationTypeEnum.LogSynchronization
        };

    }
}
1 votesVote for this answer Mark as a Correct answer

Dmitry Bastron answered on September 29, 2021 12:18

Hi Juraj,

That's interesting, I didn't know you can amend TYPEINFO after the init, really good to know it's doable.

Jeffrey, try out setting it to IncludeToParentEnum.Incremental or IncludeToParentEnum.None and see if any of these solves your issue.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on September 29, 2021 12:21

@Dmitry - the last time I tested it was with Kentico 8 or 9. It should still work but this is really a nasty hack. I would try avoiding it if possible and use it as a last resort only. It can also happen that we will decide to remove this in the future as it is not an official feature/setting and it is definitely not recommended. The recommended setup in staging is to have near to 100% identical instances.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.