Saving a Managed Metadata (Taxonomy) Field Value to Office 365 using REST

In this post I want to demonstrate how to save a Managed Metadata (Taxonomy) field value (single or multiple terms) to a Managed Metadata (Taxonomy) Field in Office 365 via the REST API.

The Hidden Managed Metadata Field

The trick to being able to save a taxonomy field value via REST, is knowing the name of the hidden text field that gets created when you create a Managed Metadata field.

When you make a REST call to update the Managed Metadata field, you need to pass a string representation of the managed metadata terms that you're saving into this hidden field.

The string representation of the terms is in the format of "termName|termId;".

In the screen shot below, you can see the field value of a hidden Managed Metadata field (the hidden field name is pa28754972f84ff7a6bf3e4762f23e23).

Finding the Name of the Hidden Field

Finding the name of the hidden text field of a Managed Metadata field is easy. The fastest way to do it, is by using the REST API via a browser.

1. Open Internet Explorer
2. In the address bar, enter the URL for your Office 365, followed by the REST API endpoint for to list the fields in your list.

https://matthewyarlett.sharepoint.com/sites/appcenter/_api/web/lists/getbytitle('srShipRegister')/fields

3. Use the browsers find function (Ctrl+F) to locate your field name in the xml

4. Look at the TextField property, and copy the copy
5. Use the browsers find function (Ctrl+F) to locate your field name in the xml, by searching for the guid
6. Make note of the hidden fields static name

Formatting a taxonomy field value

Now that you know the name of the hdden Taxonomy text field, you need to format the term values you want to save.

The terms should be formatted in the format of "termName|termId;".

An example model for updating the list in the above screens could look like this:

Loading ....

... and this is what the JSON looks like when you post it back to Office 365

Drag'n'drop Error within a DocumentSet

I came across a strange bug yesterday. I couldn't drag files into the Documents webpart within a DocumentSet.

When I tried dragging documents onto the page, the normal "Drop here..." dialog wasn't shown, and dropping the document wouldn't upload the file to SharePoint.

After a little experimenting (on both Office 365 and SharePoint 2013 on prem) it seems to be a bug in the SharePoint CSS.

The bug is manifested only when you change the webpart chrome from Default to Title Only or Title and Border for the documents webpart.

(Why would you do that anyway? I had a requirement to display the documents webpart title, showing the label "Supporting Documents".)

To workaround this bug, add some CSS to a Content Editor webpart, that re-positions the "Drop here..." div. If you only want that CSS, skip to bottom.

So here is how you work around it... mostly in pictures!

1. Drag'n'drop in a normal Document Set - works fine

2. Change the Webpart chrome to display the Webpart Title

3. Try the drag'n'drop again... Ahhgg! It doesn't work anymore!

4. If you zoom the page out, you'll notice that the Drag'n'drop box is further down the page and off to the right... what the?

5. With a little element inspection, we can see that Drag'n'drop div has some values set for the Top and Left properties.

These values are causing the div the be misplaced when the parent div (for the webpart) contains another child div, which appears in the HTML layout flow before the Webparts contents div (where the Drag'n'drop div lives).

In this case, that child div is the Webpart title container.

6. To fix this issue, all we need to do is:

a). Change the position CSS property for the Webparts "contents" div to Relative. This is requred because the Drag'n'drop div has a position value of absolute - an absolute position element is positioned relative to the first parent element that has a position other than static. See http://www.w3schools.com/css/css_positioning.asp for more info.

b). Override the Left and Top CSS properties on the Drag'n'drop div, with new values.

We can achieve this through a couple of CSS selectors that target these two div's. All we need to do is add the CSS to the page.

7. Add the CSS the page by adding a new Content Editor webpart, editing the source, and adding the new CSS styles.

Don't forget to hide the webparts title, by changing the Chrome property to None

8. Save the changes

9. Presto... problem fixed!

The CSS: