Jun 27 2017 10:43 AM
When editing a site column on a document library or sub-site (by adding an additional choice for example) the change does not seem to get reflected up to the parent site column settings.
Is there a way to force the changes up to the parent?
If not, is there a way to limit editing of site columns to only on the top level?
Jun 27 2017 11:33 AM - edited Jun 27 2017 12:54 PM
To my knowledge, changes made to a site column at a sub-site or application level are not intended to be passed upstream so as to preserve the integrity of SharePoint's administrative structure.
As for limiting the editing of site columns to only top site/source level, I do not believe there to be a configuration item in SharePoint Online to restrict the editing of site columns downstream; SharePoint treats site columns brought downstream more as templates that can be changed, although it does allow for configuration changes made at the site column's source to be passed downstream to any site or application using that column.
Jun 27 2017 02:18 PM
Jun 28 2017 05:13 AM
This is very disappointing.
I am worried about sub-site admins modifying site columns by adding or modifying "choices" to the list at a sub-site level. The system will quickly break down if every sub-site admin starts managing the company wide site columns at their sub-site levels.
The result will be every sub-site/document library having different choices on what are supposed to be company wide standard terms.
Jun 28 2017 05:29 AM
If you are concerned specifically about Choice columns, you might consider using a site column of type Lookup, instead. Place the lookup target list of choices at the top level and don't allow sub-site admins write access to it.
Jun 28 2017 05:34 AM
@Richard Sharp Thanks!
That is a great idea..... I'll have to redo a bunch of my columns but this is probably the best solution.
In other news I found out why Microsoft is probably not implementing a solution for this. This blog from 2012 claims that column level permissions would be a major drain on performance of the database.
Jun 28 2017 08:12 AM
@Richard Sharp So I have set up several columns this way but I'm noticing one serious missing problem. When you place the lookup site column on the document libraries you can't set the default value. I think the default value has to be set on the top site collection level.
Is there a way around this? Maybe a work flow? ..... would probably be too hardcore to set up for every doc library....
Jun 28 2017 08:26 AM
This has always been an issue in SP, the fact the site columns created at the top of the collection are indistinguisable from those created at lower levels makes it very confusing. One thing you can do is create Content Types at the top level to bundle site columns together (or in the Content Type hub) and then train the subsite admins to use the CTs.
Jun 28 2017 08:31 AM
First: if you're not using content types already, do so--that'll make your deployment of site columns a lot faster and easier to control from the top-site/source level.
Second: thinking about why lookup columns can't have a default value, I think Microsoft is anticipating that consequences could arise from allowing that. If you had a default value in place from your lookup list, then that value changed, your default value in the list/doc library using that list now has an invalid default value.
Jun 28 2017 08:32 AM
@Dean Gross yeah I keep running into the concept of Content Types everywhere I turn. I have read a lot about them but am struggling to figure out how to actually implement them in my situation. Do you know of any good tutorials?
I probably just need to try poking at it until I fumble my way to some sort of understanding - like I am with Site Columns. I think I have remade some of these columns 4 times now..... which means any views I made or metadata I applied is all worthless.
Jun 28 2017 08:34 AM
Think of content types as a set/package of site columns that you can apply to a list or document library all in one go. While the columns can be changed downstream, any changes made at the top-site/source level can be passed down to anything using the content type. In that way, they're very similar to site columns. This saves a lot of time when changing column configurations.
Jun 28 2017 08:40 AM
Take a look at https://support.office.com/en-us/article/Introduction-to-content-types-and-content-type-publishing-E... and https://collab365.community/understanding-content-type-hub-cth-in-sharepoint-2013/. The 2nd article shows how to set up a Content Type hub in SP 2013, but that is done for you in SPOnline so you can just focus on the first few sections of the article.
My strong recommendation is to start with something simple. Just create one CT and play around with it, it is very easy to get too elaborate too soon and this can cause a lot of pain and rework.
Jun 29 2017 08:08 AM
@Dean Gross just dipping my toes into content types. I've watched several tutorials and read several articles but haven't come across one thing in particular.
Is there a way to set default lookup metadata on a specific content type?
Jun 29 2017 08:57 AM
I think that you may need to make the group of Content Types the Default Content Type Group for the List you're looking at
Jun 29 2017 09:04 AM
Jun 29 2017 09:41 AM
@Dean Gross let me try to understand:
For example:
I have a list of all the models of widget my company makes and add site-columns to that list that are themselves looking up in other lists for the choice of project number and market code for example.
If I select the project number and market code in this list, does that mean the model number (title) is always associated with that project number and market code whenever that model number is selected as the metadata to apply to a file?
This would seem to be a way to force a default on specific metadata.....
Jun 30 2017 10:52 AM
The above proposed solution does not work.... how do other companies deal with default metadata? Surely there must be a way to force metadata on a file? Do I need to learn how to use work flows?