0

I'm trying to accomplish the following scenario :

  • I have a content type named MyContentType
  • It contains a column named MyColumn.
  • MyContentType is hosted on a content types syndication hub ( /sites/hub )
  • several other sites (/sites/a, /sites/b, /sites/c...) have subscribed to it through the Managed Metadata Service

Now here is what I'm trying to achieve : I want MyColumn to offer a choice of values to the end-user, either by being a Choice column or a Managed Metadata column (whatever works).

I'm facing issues in both cases:

- Option 1 : When I make MyColumn a Choice column, then the first publication propagates the choices fine, but later on if I add a choice to that column on the CT hub, then the choice does not appear on the subscriber sites. Even If I check "republish" and run the two required jobs ("Content Type Hub" and "Content Type Subscriber")

- Option 2 : In order to make MyColumn a Managed Metadata column, I proceed as follows :

  • I created a /sites/shared site collection where I create a local term store containing the terms that will be used as values by MyColumn. I do not want to create that term store at Web App level, but strictly at site collection level (I have thousands of SharePoint sites to manage and I don't want to create term stores all over the place).
  • I've added the URLs of /sites/hub, /sites/a, /sites/b... to the "site collections access" field of the term store group of /sites/Shared, so that they can all access the values
  • But then when I try to publish the column, SharePoint shows me a message telling me that its values are stored on a site collection to which not all subscribers have access (SP therefore refuses to publish).

I feel like I'm in a dead end. What's the correct practice to propagate choice values to several site collections, but let me change them in only one location?

Improve this question
1
  • I'm still not sure why the values don't propagate though. Granted SharePoint creates child content types when you create a library, shouldn't they get the choice values from their parent? (and if the parent is repblished then it should work)
    – jeancallisti
    Commented Jun 3, 2018 at 17:23

3 Answers 3

Reset to default
0

Since you are using the content type hub to distribute the content type I think it only makes sense to use the term store at the tenant /web app level. That approach seems to bypass this issue. Do you have a test setup where you can verify this?

Improve this answer
2
  • I'm pretty sure that would work. But from a production perspective that doesn't make sense : I have 5 "sibling" sites that make use of shared values hosted on a 6th "master" site, but I don't want their data (term store) to be mixed up with the data of the 2000 other sites of my platform. When some migration occurs in the future, that would create a mess.
    – jeancallisti
    Commented Jun 3, 2018 at 10:22
  • I've marked this answer as the correct answer.
    – jeancallisti
    Commented Jun 5, 2018 at 10:59
0

Since you know the sites this change should apply to you could update the site column in each site using powershell. Is that an acceptable approach?

Improve this answer
2
  • Well the point was that I would let the owners of the sites feeding on the values acess the term store group, so that they would update their values themselves through the interface of their site -- no need for them to access the Central Admin, no need to get access to execute powerhsell, or for me to maintain some powerhsell script. Thanks for your answers though, I'll acceot the first one as the answer, since it's a limitation of SharePoint.
    – jeancallisti
    Commented Jun 3, 2018 at 17:22
  • In that case a look up field might do the trick?
    – Kasper Bo Larsen
    Commented Jun 5, 2018 at 10:39
0

Kasper suggested that the solution would be to add a Term Set group at web app level. Indeed it's the practical solution, but before I mark his answer as the correct one, I want to explain why SharePoint does not offer a real solution to this use case :

  • the managed metadata values are stored at site collection level or web app level. I have n sites that need to share those values but I also have 2,000 other sites that should not know these values. Therefore I chose to host the data of my n sites onto an n+1th site, and I've shared its term store group to the n sites.

  • The CT hub is stored at "service" level. I mean that you may define exactly one CT hub per managed metadata Service. No more. When you try to publish the CTs (containing metadata columns), SharePoint does not check to which sites you have opened the term set group that these columns feed on. Therefore it simply refuses to publish the CT.

That's a pity. Both features should work with the same scope, or at least SharePoint should check the access permissions of the site collections.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.