Pnpjs: Content type id ignored when using sp.web.contenttypes.add

Created on 15 Jan 2019  路  7Comments  路  Source: pnp/pnpjs

Category

  • [ ] Enhancement
  • [x] Bug
  • [ ] Question
  • [ ] Documentation gap/issue

Version

Please specify what version of the library you are using: [1.27]

Please specify what version(s) of SharePoint you are targeting: [Sharepoint Online]

Expected / Desired Behavior / Question

When using sp.web.contenttypes.add, I excepted the created content type to have the same StringId that was specified in the request.

Observed Behavior

When using sp.web.contenttypes.add, the created content type gets a random StringId/ContentTypeID.

Steps to Reproduce

Try the following function call:

web.contentTypes.add("0x01003376E0D552D746EBBB008B9E999064E1 ", "pnpjs content type", "", "Custom Content Type")

Check if the content type id of the created content type pnpjs content type is 0x01003376E0D552D746EBBB008B9E999064E1.

code blocked enhancement

All 7 comments

Is there a "limitation" in the SharePoint APIs @patrick-rodgers?

@olemp, as far as I could recall, content type ID is ignored with the REST API add method by itself. In other words, something which can't be fixed within the library but an external bug of the API.

@koltyakov Yes, seems like that's the case.

Did a little more digging here and the object you are supposed to pass to the create method (post to the contenttype collection) is SPContentTypeEntityData and does have a ParentContentTypeId property - BUT you can't actually use this class as it doesn't resolve. So this is actually a double bug in content type creation IMO as you can't specify the Id directly, and you can't use this entity data type to specify the parent id either. Long story short content types are very broken in REST API. I hate to say it, but for now working with content types is better supported in CSOM.

```C#
[ClientNS.ClientCallableType(
Name="ContentTypeEntityData",
ServerTypeId="30e94405-dfd3-472e-b5d7-637ce8e9586c",
ValueObject=true,
ClientLibraryTargets=ClientNS.ClientLibraryTargets.IntrinsicRESTful
)]
internal class SPContentTypeEntityData
{
[ClientNS.ClientCallableAttribute]
public string ParentContentTypeId { get; set; }

[ClientNS.ClientCallableAttribute]
[ClientNS.ClientCallableConstraint(Type = ClientNS.ClientCallableConstraintType.NotNull)]
public string Name { get; set; }

[ClientNS.ClientCallableAttribute]
[ClientNS.ClientCallableConstraint(Type = ClientNS.ClientCallableConstraintType.MinLength, Value =1)]
[ClientNS.ClientCallableConstraint(Type = ClientNS.ClientCallableConstraintType.MaxLength, Value =SPContentType.MaxGroupLength)]
public string Group { get; set; }

[ClientNS.ClientCallableAttribute]
public string Description { get; set; }

}
```

Thanks for digging deep on this @patrick-rodgers. Much appreciated. I guess CSOM is the way to go for content types.

Closing this as there are currently no plans to update the SP api to support this. Content Type management may be coming to the graph and we will have a look at adding that support after the release of v2. Thanks!

Was this page helpful?
0 / 5 - 0 ratings