0

I am a bit confused about the relation between Parent and child content type.

Now I want to create a new content type that have the Issue as its parent content type. So how I should be managing the two content types (parent and child) in the following scenarios:-

  • If I want to add a new site column to the child content type, should I add it directly to the child content type or I should added to the parent content type?

  • If I want to change the “Column Settings” for a field such as if it is optional, required, hidden should I do it at the parent or at the child content type.

  • Let say I created 3 issue tracking lists based on the custom content type which i have created and which have the Issue as it parent content type. Where each issue tracking list will have different values for the Priority site column. So is it a bad practice to modify the Priority values at each list level , where the Priority will have different values at each of the list levels ? Or it is better to create a new Priority site columns for each list. in other word should I always create new site columns or it is better to modify the same site column at the list level ?

Can anyone advice ?

3

When working with parent/child content types, I do this: The parent has only the fields that will exist in all child content types. Then each child content type only has the fields in it that are needed and are not inherited from the parent. So if your children each have different priority values, then each one would have their own priority field that is unique to their content type.

Example: 2 Content types contain shared field, customer, and each child has a unique field.

Parent content type contains customer field. Child content type 1 is created from parent and a new column is added into that. Child content type 2 is created from parent and a new column is added into that.

  • so you mean after creating the new child content type, i will remove the parent columns from it ? but what if i want the parent column to have different setting or values on each of the child content type ? – john Gu May 13 '15 at 12:56
  • also you mentioned "So if your children each have different priority values, then each one would have their own priority field that is unique to their content type." so i need to create a new site column for each of the Priory columns ? or you mean to keep the parent Priority inside the child content type and modify it at the child level ? – john Gu May 13 '15 at 12:58
  • 1
    That is how I do it yes, create separate priority fields for each child if they contain different values otherwise I'd use the inherited field from the parent. – Eric Alexander May 13 '15 at 13:01
  • so as i general rule i should not have the parent content type and its child have different values or settings for the same column? also i should not have a site column that have different setting or values at the list level... so for example if i want a Priority field that have different values on each content type or on each list then i need to create a new site column instead of modifying the site column at the list level ? is this correct ? – john Gu May 13 '15 at 13:04
  • based on your edit i should not remove the shared field (the customer) from the child content type,, i though you mentioned that i need to remove any shared fields from the child content type... is this correct ? – john Gu May 13 '15 at 13:12
2

attempting to answer your questions specifically

  • when adding a new column, you'll want to add it to the parent if you want the parent and subsequent children to have the same column. If your parent is an OOTB SharePoint CT, then only add it to your child. I don't recommend modifying SharePoint content types, you never know what Microsoft might do, plus these content types are used across all lists and libraries, even ones you may not see. Inherit from it, and make that new child your new parent for all of your needs.
  • Same thing here, dont mess with the parent, make your own parent (inheriting from an OOTB CT) and do what you will
  • You can take this two ways: 1) edit the columns in the lists accordingly, no biggie there or 2) create your base CT inherit from issue, then create separate CTs for each use. Its more work but is more flexible, allowing you to reuse the CTs, and easily search and roll up those CTs specifically, if necessary.
  • for the third point you mean if i have 4 issue tracking lists and each tracking list need to have different values for the Priority column (different choices inside the srop down),, then what i can do is to create 4 site columns named PriorityA,PriorityB, C & D. then create 4 content types that have their parent as the "Issue" CT,, after that i will leave the build-in Priority as is in the Parent IssueCT. then on each of the child content types i will add the related Priority site columns ? is this what you are proposing ?? – john Gu May 13 '15 at 13:42
  • You can either use the same content type in each list, and just change the column values in the list settings OR Create 4 content types using the same site column, and change the values within the site content types No need to create separate columns – David Lozzi May 13 '15 at 13:53
  • then this leaves me in three options; create 4 new site columns OR edit the column at the list level OR edit the column at the child content type ? so i am not sure which approach i need to follow? now having 4 site columns means that i can avoid any problem if some one by mistake update the site column at the site collection level,, so in this case any customization at the list level ot at the content type level will get overridden.. ... – john Gu May 13 '15 at 13:58
  • 1
    I share your pain. This is a tough spot. If you're going to grant them that level of permission, you're right, you run the risk of them customizing even more, and then pushing changes down run a risk. If all you want them to do is change choice values, use a lookup list instead, one they can then easily manage the values. If it's a switch from required to hidden, then you need to see how your governance is best met. Should that be a support request? Do you want users having that permission level on a list? Maybe a custom script to handle it for you? – David Lozzi May 15 '15 at 15:22
  • 1
    Maybe we can take this "offline" via email, just to not load up this forum. The topic is swayed from your original ask and the moderators may chime in :):) Email me at david.lozzi at slalom.com and we can continue. – David Lozzi May 15 '15 at 16:27
2

The hierarchical relationship allows you to reuse the settings (fields) defined in one content type (parent) in other (child) content types. The hierarchy of content types can be extended to an infinite width and depth, but the best practice is to use 3-level parent-child hierarchy.

Site Content Type structure

You could read more best practices on how to manage content types and documents here >>

Hope it will make more sence for you to make a right decision in your situation.

Edited acording disscusion: You could create general columns in Site collection level and add to CT. Then create a fresh subsite, create other columns you need on this subsite level and add those to list with your site collection columns (CT). Then to save this site as template. And I suspect that all sites created from this site template will have two types of columns: Site collection columns, which you could manage from "backend" and apply modifications; and Site level columns. So subsite admins could modify subsite fields as they need. I think this option would work for your.

  • thanks for the link ,, so if i have a Priority drop-down column, but each list will have different values inside the drop-down,, so should i create separate site columns for the priory column ? and what about the Priorty field that is already defined inside the Issue parent content type ? – john Gu May 13 '15 at 13:19
  • Yes, if it is a choise column with different values, you need to create several columns like PriorityA, PriorityB, PriorityC. Every field inserted in parent CT are inherited in child content types. So if you need that field you already have, you could leave it, but if it mast be differet in every child CT, you need to remove it from parent and add to child dependint on content type (PriorityA or PriorityB) – martusha May 13 '15 at 13:25
  • 1
    also inside the subsites all the content types and site columns can not be modified at the sub site level, and they need to be modified from their source ,, which is the site collection. even the content types and site columns at the sub site level will not click-able ... but you can modify them at the sub sites' list level.. – john Gu May 14 '15 at 14:19
  • 1
    Also you could create general columns as I said in Site collection level and add to CT. Then create a fresh subsite, create other columns you need on this subsite level and add those to list with your site collection columns (CT). Then to save this site as template. And I suspect that all sites created from this site template will have sitecollection columns, which you could manage from "backend" and apply modifications and Site level columns. And subsite admins could modify subsite fields as they need. i think this option would work for your. – martusha May 18 '15 at 6:52
  • 1
    having the CTs & site columns at the site collection is a best approach. But as you said some fields could be modified by subsites admins (in subsite level or list level - it doesn't mutch in that case), so I just want to find the more easy to manage solution for you. If you need some field be updated globally, then you need them on site collection level. If you in future modify them without option to update inheritance, what's the point to modify them then? – martusha May 20 '15 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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