Option to use the order of nodes in which it is defined on model

[sergeisnitko]

Option to use the order of nodes in which it is defined on model

SPMeta2 CSOM Standard 1.2.120

Maybe it could be a great option somehow to let the developers not to use the default order of model nodes (DefaultModelWeigh class) and to use the order defined by the developers directly in the model. Now the provision uses the DefaultModelWeigh.Weighs to order the types of model nodes in model and to change the order, we need to:

1. Clear it (DefaultModelWeigh.Weighs = new List<ModelWeigh>();) and the provision will not use the order of the model types. But it will deploy the model with packs of definition types. For example, if the first node in model is FeatureDefinition, it will find all the FeatureDefinitions and deploy them. And so on. Some features (like features with event receivers on lists) needs to be activated after the list was provisioned on the web. It is not an option to make a new model for this case if there are lots of such subwebs in model. The clearing of DefaultModelWeigh.Weighs helps if we put all feature definitions at the end of the modelnode
2. Copy the all weight or the part of the model to change the order or update it. Like this:

DefaultModelWeigh.Weighs = new List<ModelWeigh>()
{
    new ModelWeigh(
    typeof(ListDefinition),
    new[]
    {
        typeof (BreakRoleInheritanceDefinition),
        typeof (ResetRoleInheritanceDefinition),
        typeof (SecurityRoleLinkDefinition),

        typeof (PropertyDefinition),

        typeof (ContentTypeDefinition),
        typeof (ContentTypeLinkDefinition),
        
        typeof (RemoveContentTypeLinksDefinition),
        typeof (HideContentTypeLinksDefinition),
        typeof (UniqueContentTypeOrderDefinition),

        typeof (FieldDefinition),
        typeof (LookupFieldDefinition),
        typeof (DependentLookupFieldDefinition),
        typeof (CalculatedFieldDefinition),

        typeof (ListFieldLinkDefinition),

        typeof (SP2013WorkflowSubscriptionDefinition),

        typeof (FolderDefinition),

        typeof (ListViewDefinition),
        typeof (ModuleFileDefinition),

        typeof (ListItemDefinition),
        typeof (ListItemFieldValueDefinition),
    })
};

We made this to define the provision the calculated fields after all other fields. We need to copy all parts to let it work fine

3. Calculate another model for some operations. We have a big model (more than 100 webs in structure with lists, fields and other) and have problems with lookups. We have no options to make several models to define the lookups (it would be very hard to maintain the structure and behavior in several models) and disabling the order (and packing the provision by definition types) could help us to deploy the lists like containers, then lookups and the lists with content types, fields, views and others.

Now we wrote a function to clear up the built model and leave only webs and lists like containers

public static ModelNode GetContainersModel(this ModelNode model)
{
    var kModel = model.ChildModels.Where(ch => (ch.Value.GetType() == typeof(ListDefinition)|| ch.Value.GetType() == typeof(WebDefinition))).ToList();

    kModel.ForEach(InModel=>
    {
        InModel = InModel.GetContainersModel();
    });

    var InCollection = new Collection<ModelNode>(kModel);
    
    model.ChildModels = InCollection;
    return model;   
}

and use it

var xWebModel = ModelsInfo.xWebModel();
var xContainers = (WebModelNode)ModelsInfo.xWebModel().GetContainersModel();

xContainers.SetIncrementalProvisionModelId("xContainers");
xWebModel.SetIncrementalProvisionModelId("xWebModel");

Ctx.DeployModel(xContainers, Incremental);
Ctx.DeployModel(xWebModel, Incremental);

Maybe I missed something. It's not a critical option, we got overhooks for it, but it would be best if we could set the order of the nodes directly in model... like this:

var model1 = SPMeta2Model.NewWebModel(rootWeb =>
{
    rootWeb
            .AddMasterPageSettings(SpfPages.MasterPage())

            .AddWebFeature(Core.SpfFeatures.DisableMinimalDownloadStrategy)
            .AddWebFeature(Core.SpfFeatures.SharePointServerPublishing)

            .AddList(SpfLists.Events())

            .AddEventsFields()
            .AddSectionCT()
            .AddEventCT()
            .AddMPBCTs()

            .AddList(SpfLists.Events(), List =>
            {
                List
                    .AddRemoveStandardContentTypes()
                    .AddContentTypeLink(SpfContentTypes.Section())
                    .AddContentTypeLink(SpfContentTypes.Event())
                    .AddListView(SpfViews.EventsView())

                    .AddDemoEvents()
                    ;
            })
            
            .AddWebFeature(SpfFeatures.MediabankServerSide)
            ;
});

and to activate features, then deploy a list like a container, fields with lookups, content types, list with mappings and at the end the feature

[digital88]

I have same problem, have to deploy some model in two parts. SecurityRoles and SecurityGroups are provisioned in wrong order by SPMeta2.

[SubPointSupport]

@digital88, could you please describe the issue? We'd like to understand what exactly is wrong with the provisioning order for security groups and roles. It might be a separate issue which we can easily fix.

As for the whole ticket, indeed, SPMeta2 has an opinion on the order of the provisioned artifacts. While provisioning, SPMeta2 tries to group and sort all the artifacts in the models to guarantee the right sequence (fields before content types and so on) of the provisioning process. All comes back to DefaultModelWeigh.Weighs class property, that's default behavior.

Having said that, sometimes we might have either bugs or additional complexity on which it might be challenging to make a decision on the provisioning order. Here what we can do:

• Abstract the grouping/sorting order into a separate service (which you can implement and override)
• Add flag and promote it to the syntax to enable/disable out of the box sorting so that YOU would be responsible for taking care of the provisioning order - the model would be deploy as it is

We think that would completely solve this challenge of the provisioning order.

Now, there is a darker side of such changes. As you gain more control over provisioning sequence, we might struggle with support and issue troubleshooting. In that case, with more freedom, we also introduce more complexity over troubleshooting and support process.

So far, all good and we can implement mentioned early features. Let us know if that something what suits you.

[sergeisnitko]

@digital88 It is not exactly the same. If you have problems with order, you can clear DefaultModelWeigh.Weighs. I am talking mostly about the grouping of nodes by node type.

@SubPointSupport, yes, you are right and I understand why did you do this.

Add flag and promote it to the syntax to enable/disable out of the box sorting so that YOU would be responsible for taking care of the provisioning order - the model would be deploy as it is

Yes, I think that is the best solution for us. Thanks!

[SubPointSupport]

Sweet, we'll see what can be done.

Meanwhile, still waiting @digital88 on more details related to security group / roles issue.

[SubPointSupport]

@sergeisnitko, what's the timeframe? When do you need it?

[sergeisnitko]

@SubPointSupport, it is not very critical. You can plan it according to your own free time. Thank you very much!

[SubPointSupport]

Sweet! We'll postpone and give some thought to it. Definitely coming, we need to think about implementation.

[digital88]

Hello again. Regarding provision model order:

Here is simple model:

When I provision it:

It starts provisioning Security Groups, which fails because Security Roles should be provisioned first..

[SubPointSupport]

Clearly bug, this should not be a case. Getting one more ticket for this one, @digital88

[SubPointSupport]

Relates to Remove list fields sorting by type while provisioning #1078 @HeToC FYI