Pnpjs: Retrieve all *available* Content Types for subsite?

[thw0rted]

Category

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

Version

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

Please specify what version(s) of SharePoint you are targeting: [2016 on-prem]

Expected / Desired Behavior / Question

I would like to list all content types that could be applied to lists/libraries in a subsite. In the Content Types docs, all examples involve retrieving a single content type by ID and there are no examples of working with a collection of content types.

Observed Behavior

I tried making a Web pointing to a subsite, then retrieving web.contentTypes.get(), but this only gives the Content Types that belong directly to the Web (subsite) in question. This is exposed in the .NET Client as AvailableContentTypes but I don't see anything like that here. I thought about walking up from the subsite to the root site, looking for ContentTypes owned by each, but a) per #1311 I don't know how to tell when I'm at the root, and b) it seems like the kind of information that should be available with one API call rather than several.

[koltyakov]

Hope this will be helpful:

// from a web using fluent API
const webContentTypes = await sp.web.contentTypes.get();

// from a list using fluent API
const listContentTypes = await sp.web.lists.getByTitle('List')
  .contentTypes.get();

// or from a web as properties
const { AvailableContentTypes } = await sp.web
  .select('AvailableContentTypes')
  .expand('AvailableContentTypes').get();

availableContentTypes is not exposed as a dedicated method I believe, but it can be requested as corresponding web props.

[ncmadhan1989]

Is any possible to update list content type?? Means turn off retention policy in list content type

[koltyakov]

Is any possible to update list content type?? Means turn off retention policy in list content type

Is it possible via REST? I have concerns.

[thw0rted]

I should have made a clearer example:

ts const web = Web("https://mysite.com/site1/sub2/"); const types = await web.contentTypes.get(); console.log(types.length); // 0, Home => Site 1 => Sub 2 did not have any of its own content types

My point was that each IWeb will only load the contentTypes that it owns, not any parent / global content types that it also has access to. Is this not the expected behavior? If not, that's a bug. If so, then my question is how do I get all content types, both owned and inherited?

ETA: just saw your edit about web.select('AvailableContentTypes').expand('AvailableContentTypes').get();. I will try that tomorrow but it sounds like I'll have to parse the results for myself. Is there a reason that's not available as part of the fluent API?

[patrick-rodgers]

@thw0rted - to answer your question "Is there a reason that's not available as part of the fluent API?" which seems to be a theme of your comments. The library is used by many many people in their projects and we aim to provide solid functionality upon which folks can build to meet their specific requirements. We don't want to ever have a method/property for every possibility - it just doesn't make sense. Instead we built in extension capabilities allowing you to inline the methods you need for your project and requirements. This lets the core library remain as light as possible but allows for per-solution extensions to meet your needs. HTH

[thw0rted]

Thanks for clarifying -- I didn't want to sound like I was complaining, I just don't always know what to expect from this project.

I'm new to Sharepoint and I'm trying to build a mental model of the different primitives and their relationships in the product, and at the same time trying to figure out the REST API, and how this library represents those primitives and relationships, by interacting with the REST API. It's a lot coming at me at once.

I had the expectation that the library would model every aspect of the data on the server -- "here is the root web (site?); it has a collection of Site Columns, this is the method to get those; it has a collection of Child Sites, this is the method to get those" etc etc. I recognize that the complete model -- a diagram of every type of data and how they relate to each other -- is quite substantial and that providing a corresponding complete API wouldn't be a trivial task by any means.

The problem I've run into a number of times is, I don't really know where to look for help when I need to solve a problem. I can look at the MSDN docs that I linked to for the .NET Client, but the way they interact with SP is not quite the same so you can't guarantee that the same approach would be appropriate. I look at the docs for this project but if there's not an example of exactly what you intend to do, you might need to use an undocumented method -- for example, I spent some time picking over the docs just now and I can't see any way I could have arrived at your .select(...).expand(...) approach on my own, because there are no pages specific to how expand works (what fields am I selecting from? where are those documented?), and no examples of it on the page for sp/Webs. I feel like I could find my own way if there were a docs page for every interface, every factory, every mixin, but with this example-based approach I don't know what to do when my requirement isn't on the map.

[juliemturner]

I think the issue you're having is that this library is just a fluent API for the documented SharePoint REST endpoints. So, when you look at docs.microosft.com you really need to be searching for the REST endpoints (not .NET) that do these things and get complete documentation. We do not try and provide documentation for what is already documented for the most part. This is maybe a good place to start... https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/get-to-know-the-sharepoint-rest-service?tabs=http

[thw0rted]

That's very helpful, thanks! It looks like this section corresponds to .expand(..) in the fluent API, if I'm understanding correctly. Coupled with this section it explains how to find child resources under a parent.

What I still can't find, though, is a complete list of those resources. Compare these docs for the .NET Client Web interface with the pages under the docs you linked to. The former lists every property of the interface, with a type and often a text description. In the latter, there are pages that go into some detail about "lists and items" or "folders and files", but no comprehensive description and nothing about other types like Content Types and Site Columns. Am I missing something? Is the intent that I should just make the calls myself and see what comes back? That's certainly a possibility, but I prefer to search published docs if they're available.

[thw0rted]

Digging a bit more, it looks like I was wrong and select/expand corresponds to these OData operations, given that calling the functions just winds up setting the relevant operators on the REST URL that's requested on get().

I don't see a way to do server-side filtering on expanded fields, though. Right now, if I start with the name of a content type and I want to know what fields it has, I need to either retrieve all available content types and their fields using .select('AvailableContentTypes/Name,AvailableContentTypes/Fields') with an expand (which is over 700 KB of JSON!) then filter that myself, or I have to make multiple trips: one to find the Content Type ID, then at least one to fetch its fields. This step is further complicated since I can't just say myWeb.contentTypes.getById('found ID").fields.get(), because the type might be owned by a parent of myWeb. I think I'd have to somehow get the ID of the owning Web (maybe as part of the AvaiableContentTypes record?) then query that, but I don't see an obvious way to do that.

[juliemturner]

The SharePoint apis are not an implementation of the ODATA standard, it is its own special pink unicorn. Expand is used only for lookup columns. If you want a true ODATA implementation than you would need to use the Microsoft Graph to access SharePoint data but the entire API landscape is not available via that entry point, although it does allow you to traverse objects across all of the Microsoft 365 landscape. Further, to your comment about the .NET objects, those return types are very similar since the REST endpoints are built on top of the CSOM implementation. Basically, the REST api's are just another interface for the same thing. The documentation for SharePoint has grown organically over the years and some things aren't documented as well as anyone would like, and I believe for the most part the community does most of the dev documentation.

To your specific question about content types, unfortunately SharePoint is a complicated platform and it does take a lot of time to understand how it all fits together and the nuances. I’ve been at it for a long time now and still don’t know everything, never will know everything, and probably have forgot at least half of what I ever knew (granted that may be because I’m just getting old and senile). The REST APIs don’t work the way you are asking about. As a result, the library doesn’t work that way. This is more about SharePoint itself and not this library specifically and isn’t in scope for this library. That said, if you have specific suggestions on where we can improve our docs or add examples, we are open to that, please feel free to open an issue and suggest said focused improvements.

[thw0rted]

Thanks, if I have a little time later on I will put together a couple of simple task examples that aren't currently in the docs ("Get a content type by name", "Get a field by content type", etc) as a docs-improvement issue. I need to go back over what I've written so far and see what I had to figure out on my own, and what still looks hacky to me.

[patrick-rodgers]

Going to close this as answered. If you still have questions please open a new issue, ref this one and provide any additional details possible. Thanks!