search

SharePoint / PnP-JS-Core

Code moved to https://github.com/pnp/pnpjs. This repository is archived.
Other
379 stars 231 forks source link

400 error when getting fields for Content Type that has a MMS field #799

Closed richardegleston closed 6 years ago

richardegleston commented 6 years ago

Category

[ ] Enhancement

[X] Bug

[ ] Question

Version

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

I believe this is the last release that supports typescript 2.2.2 This is a dependency for my project as it is an SPFx project targeted for SharePoint 2016 (On premise)

spfx@spfx:/usr/app/spfx$ npm view sp-pnp-js@2 devDependencies.typescript sp-pnp-js@2.0.0 '^2.1.0' sp-pnp-js@2.0.1 '^2.1.0' sp-pnp-js@2.0.2 '^2.2.1' sp-pnp-js@2.0.3 '^2.2.1' sp-pnp-js@2.0.4 '^2.2.1' sp-pnp-js@2.0.5 '^2.2.1' sp-pnp-js@2.0.6 '^2.3.4' sp-pnp-js@2.0.7 '^2.4.1' sp-pnp-js@2.0.8 '^2.4.2'

Expected / Desired Behavior / Question

When working in the workbench (using a SharePoint Online site), the call to get the fields works as expected, the fields are returned.

Observed Behavior

When taking the same code and running in SharePoint 2016, a 400 bad request error is returned. However I was able to determine this ONLY happens when the content type has a MMS field.

Steps to Reproduce

Here is my import statement: import pnp, { Web } from 'sp-pnp-js';

Here is my call: return new Web(webUrl).lists.getByTitle(listName).contentTypes.getById(contentTypeId).fields.get()

NOTE: The content type being requested MUST have an MMS field in it.

Thanks!

patrick-rodgers commented 6 years ago

Unfortunately this seems like a difference between online and 2016 and I am not sure there will be much we can do in the library. @koltyakov - do you have a 2016 environment handy to repro this?

Thank you for your interest in the sp-pnp-js library. We wanted to mention that this library is being deprecated in July, 2018 in favor of the new scoped pnpjs libraries. You should begin transitioning your existing projects when possible, or start new projects with the new libraries. Please see the transition guide for more details on migrating and be sure to let us know if you have any questions. Thanks!

koltyakov commented 6 years ago

@patrick-rodgers, I'm in a rush these days, might be able to check closer to Wednesday only. :(

patrick-rodgers commented 6 years ago

That's fine - no rush, this has pretty limited impact though we do want to take a look.

richardegleston commented 6 years ago

I appreciate you guys investigating this, thank you.

richardegleston commented 6 years ago

Is there any update for this issue?

Thanks!

richardegleston commented 6 years ago

@patrick-rodgers @koltyakov Anything? I'm trying the JSOM library now but that has even more issues.

richardegleston commented 6 years ago

https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/guidance/connect-to-sharepoint-using-jsom https://github.com/SharePoint/sp-dev-docs/issues/583

patrick-rodgers commented 6 years ago

Hi @richardegleston - sorry, haven't had time to get a 2016 environment setup for testing this issue. This might not be something we can fix within the library either, especially if the request you are making is as you list above - there isn't anything happening other than generating the URL and doing the GET. You could try selecting just one or two fields and see if you still get an issue.

richardegleston commented 6 years ago

My workaround was to get the content type directly (without asking for the fields). I then parsed the schemaXml property of the content type to get the fields. Pretty gross but effective.

Before that I tried loading JSOM, but man is that ever terrible! The scriptloading calls freeze the browser until they resolve (only occurs in IE). I would not recommend using JSOM for SPFx on-prem.

patrick-rodgers commented 6 years ago

Glad you are unblocked. Going to close this as resolved. Would still encourage you to migrate to the new libraries when you get a chance. Thanks!