Enhance list-scoped content type operations

[vlad-ivanov-d]

Hello Sometimes there are situations, when we need to add content type field link directly in list content type (the same content type on web mustn't contain this field). And now, as you said, there are no any methods to do what. So, it would be great if we had this feature for work with list content types as with web content types.

[SubPointSupport]

@vladivanovrf what's your timeframe on this feature? Looking into this one.

Also, not sure how it should work. First of all, the field should already exist in the list before adding it to the list content type. Next, .AddContentTypeFieldLink() method, in this case, would refer to the list field only, right? We can't just hide all the complexity behind adding site field to a list and then adding list field to a content type. That should be done by the end user (adding a field to a list), so that .AddContentTypeFieldLink() on the content type withint the list would make sense.

What do you think of it?

[vlad-ivanov-d]

I don't have strong time limit for this feature. But this method can make model of our customers real simpler, because now we have to make some hacks. I think it should work in the same way as in SharePoint UI. There is a button "Add from existing site or list columns" in list content type scope. So, the field may not exist in the list, but must exist in site.

[SubPointSupport]

I think it should work in the same way as in SharePoint UI. There is a button "Add from existing site or list columns" in list content type scope. So, the field may not exist in the list, but must exist in site.

Right, that's exactly the "issue". These are two scenarios:

• Adding field from the site to list, and then to a content type
• Adding field from list to a content type

That would result in two different syntax constructions in SPMeta2 so that it would be possible in the model to express the exact action, such as this:

• .AddFieldFromExistingSiteColumns()
• .AddFieldFromListColumns()

Essentially, these are still content type field links but limited to a list with a highly specific behavior. More that happy to implement it.

Another thing is that .AddFieldFromExistingSiteColumns() would have a broader "scope" - it would have to reach site, lookup the field, update list and the content type. These are too much operations for a single .AddXXX() syntax. Internally, we try to simplify updates and all operations SPMeta2 does, that's why there was a suggestion to have only .AddFieldFromListColumns method (expecting that field has to be added early by the end user).

Nevertheless, this is a bit of work to be done. A few days of work plus full regression for both CSOM/SSOM and bunch of new regression tests to write. We'll be adding this functionality gracefully (to avoid breaking changes) but ETA would be around few weeks, alright?

[vlad-ivanov-d]

.AddFieldFromExistingSiteColumns() .AddFieldFromListColumns()

In my opinion, these methods should be combined in one as in UI, it will be closer to Microsoft concept. But I agree, in this case it will have rather many operations on the background.

Internally, we try to simplify updates and all operations SPMeta2 does, that's why there was a suggestion to have only .AddFieldFromListColumns method (expecting that field has to be added early by the end user).

I see. In this case list method ".AddField" should has an option not to add field to all existing list content types (this option exists in CSOM and SSOM, but I didn't find it in SPMeta2).

We'll be adding this functionality gracefully (to avoid breaking changes) but ETA would be around few weeks, alright?

Yeah, deal

[SubPointSupport]

I see. In this case list method ".AddField" should has an option not to add field to all existing list content types (this option exists in CSOM and SSOM, but I didn't find it in SPMeta2).

Field option, FieldDefinition.AddFieldOptions = BuiltInAddFieldOptions.DefaultValue or other value. Comes back to a BuiltInAddFieldOptions SharePoint object.

In my opinion, these methods should be combined in one as in UI, it will be closer to Microsoft concept. But I agree, in this case it will have rather many operations on the background.

Having two methods would help us to understand where to find the field, plus the model would be much be readable and understandble by other people. Othewise, you need to think, keep in mind additional knowledge and actually KNOW how SPMeta2 would work in that case - will it find field in list? won't it? would it try to look up field from site? will it add the field to a list? and so on.

We really try our best to add simplicity, that's why the model and syntax has some "overhead" but also has absolutely outstanding and clean syntax - people don't have to think and guess on the actual behavior. That's why two methods are suggested, besides you've got two options in the UI as well:

• .AddFieldFromExistingSiteColumns()
• .AddFieldFromListColumns()

The rest is fine, nice to see agreement here :)

[vlad-ivanov-d]

Field option, FieldDefinition.AddFieldOptions = BuiltInAddFieldOptions.DefaultValue or other value. Comes back to a BuiltInAddFieldOptions SharePoint object.

Oh, sorry. I missed such option in SPMeta2.

Anyway, it's ok for me, if it will be 2 separate methods in SPMeta2 for field links in list content type.