React Content Query WebPart - With Metadata Field

[marcelaopimenta]

Category

• [ ] Question
• [X] Bug
• [ ] Enhancement

Hi...

I have one Environment with Sharepoint 2016 On-premises with latest CU.

In my site, i have one library with metadata fields... and if use React Content Query, occur this error...

This error An error occured while loading fields : Bad Request is beacause request a API /es/_api/web/lists/GetByTitle('Páginas')/Fields?$select=InternalName,Title,TypeAsString&$orderby=Title fails.

1. This error, only occur if i have a Metadata Field in Library... If delete field works.
2. In post in Postman its the same the Content Query Webpart.
3. I believe that problem is post use application/json;odata.metadata=minimal

If anyone can help me.. :-D

Thanks !!!

[spplante]

@marcelaopimenta sorry for the delay I just saw this issue. What do you mean when you say that the error only occurs when there's a "metadata" field, you mean a "Managed Metada" field as in a "Taxonomy" field? There must be something else with your list because the WebPart does support Taxonomy fields.

It looks weird because as you pointed out, the only thing the WebPart does is a request to the specified URL (GET request not a POST) :

/es/_api/web/lists/GetByTitle('Páginas')/Fields?$select=InternalName,Title,TypeAsString&$orderby=Title

And that request should work no matter what kind of field you have in your list...What happens if you put the URL directly in the browser, does it work or you get the same error?

Also, can you try with the latest version available on this repository? Because I see that the version you have uses the "GetByTitle" in the request, which is problematic because if you change your list title the WebPart will be linked to the old list title and it won't find it anymore.

The WebPart has been updated to use the following now :

let endpoint = Text.format("{0}/_api/web/lists(guid'{1}')/Fields?$select={2}&$orderby={3}", webUrl, listId, selectProps, order);

This version uses the GUID of the list instead of the title, it's also less error prone with list that have special characters like yours. Please try the latest version and let me know if you still have the problem.

[marcelaopimenta]

Yes, is a Taxonomy field. I have one version older because some things customized.

But, one thing is certain, the problem is not from SPFX or the WebPart, the problem is from SharePoint 2016 OnPremises. I created the same environment in a SharePoint Online and it worked correctly.

[marcelaopimenta]

In Sharepoint 2016 On Premises dont work

/_api/web/lists(guid'{1}')/Fields /_api/web/GetByID(guid'{1}')/Fields /_api/web/GetByTitle('{1}')/Fields

if you have a Taxonomy Field and use the Accept application/json;odata.metadata=minimal

[spplante]

Yeah that's what I was scared of, because it is a simple REST request there is nothing fancy about it. Out of curiosity, could you use SharePoint Manager to extract the XML definition of the field and paste it here? I wonder if it's not a problem with the specific Taxonomy field that you added to the list, maybe in its name format or something like that.

Is it a field that you deployed or it's a regular field created by the UI?

[marcelaopimenta]

In my project is an deployed field. But I got to create a new publishing site without data, went into the page library and added a new metadata field in a new TermSet, also created via interface.

I also created sites in English and Spanish... Same faults.

[spplante]

Interesting, what kind of "display name" did you specify when creating the field from the UI? Because when creating fields via the UI, SharePoint builds the internal name of the column using the specified display name, replacing spaces by encodings like x0020x and stuff like that. Did you try creating the column with a regular name without any space or special character at all?

Otherwise it does look like a bug in SharePoint 2016, I have no SP2016 tenant to test on, but if you find a successfull way to execute a GET request with Postman to the problematic endpoint that works for both SP2016 and SPOnline, let me know, I will add the workaround in the project 👍

[marcelaopimenta]

Hi Simon!

The field calls Teste very simple name...

If i post with:

odata-version: 3.0 Accept: application/json;odata=verbose;charset=utf-8 Content-Type: application/json;odata=verbose;charset=utf-8

Works fine!

What changes is the return structure of json, does not use the json light format, because it is verbose now.

if you can create this workaround I will be grateful.

Thanks!

[spplante]

Can you make it work with a GET? Because there is no need to do a POST for getting information. Also, Im am not sure what is the difference between the actual code and the POST you just did, these should be the default settings used by SPFx

odata-version: 3.0 Accept: application/json;odata=verbose;charset=utf-8 Content-Type: application/json;odata=verbose;charset=utf-8

[marcelaopimenta]

I messed up, it's a GET and not a POST.

Sharepoint Framework have two configurations in sp-http

ODATA V3 Content-Type: application/json;odata=verbose;charset=utf-8 Accept: application/json

ODATA V4 Content-Type: application/json;charset=utf-8 Accept: application/json;odata.metadata=minimal

Today, your component using V4... but even if we use V3, it does not work, because only works if using application/json;odata=verbose;charset=utf-8

[spplante]

Oh I see, you can try specifying your own headers to the spHttpClient, since I don't have access to an SP2016 farm right now, let me know if you are able to specify the headers and make it work. If you do find a workaround with custom headers, I could test it for SPO and integrate it in the solution.

Thanks!

[marcelaopimenta]

Hi Simon! Thanks for help! Its Works now!!!!! :-D

In listservice.ts on method getListFields I have added the following code in getlistfields method. I check if Environment is Onpremises and added custom headers.

let options: ISPHttpClientOptions;
if (Environment.type == EnvironmentType.ClassicSharePoint) {
    options = { headers: { 'odata-version': '3.0', 'Content-Type': 'application/json;odata=verbose;charset=utf-8', 'Accept': 'application/json;odata=verbose;charset=utf-8' } };
      }

Change the spHttpClient.Get call for use options

this.spHttpClient.get(endpoint, SPHttpClient.configurations.v1, options).then((response: SPHttpClientResponse) => {
				if(response.ok) {
					resolve(response.json());
				}
				else {
					reject(response);
				}
			})
			.catch((error) => { reject(error); }); 
        });

In methods getFilterFields, getViewFieldsChecklistItems, i changed this point:

   let fields: any[];
              if (Environment.type == EnvironmentType.ClassicSharePoint) {
                fields = data.d.results;
              }
              else {
                fields = data.value;
              }

In Method getOrderByOptions i changed this point:

let sortableFields: any[];
 if (Environment.type == EnvironmentType.ClassicSharePoint) {
       sortableFields = data.d.results;
 }
 else {
       sortableFields = data.value;
 }
 sortableFields.filter((field) => { return field.Sortable == true; });

Thank you!!!!

[spplante]

Good job, I will make sure to implement this is the official version. Meanwhile, I strongly suggest you to append all your changes to the latest version because at least two problems have been fixed since then :

• Multiple filters losing their orders in IE thus messing the query results
• Some webs were not appearing when selecting a site based on tenant configurations

Thanks again!