I hope I do an admirable enough of a job in explaining a Site Content Type design approach I’ve been tasked with supporting and enhancing for a particular SharePoint site. I wasn’t involved in the design so I don’t have all of the background info as to why and how.
The SharePoint site in question was set up for the purposes of creating services support system for our corporate maintenance department. At a high level this system is allows users to submit requests to the maintenance department. Requests are written to a service request List and a notification is generated informing the maint. dept. of the request. From there the maint. dept. can action the service request, provide updates and details about the issue, plan and then perform the maintenance, then complete the request. After completion service request details are written to a service request archive (List). The system provides different views for the department’s management team including outstanding submitted service requests (and status), and completed and archived service requests, as well as the ability to report on service requests (from archival).
The Site Content Type design supporting this system seems is generally straightforward however it seems to stray a bit from what I understand about inheritance. Let me explain….
The Site Content Types configured for this site are as follows:
1) Service Request
2) Service Request Submitted
3) Service Request Completed
4) Service Request Archive
The inheritance set up between these content types are as follows:
1) Service Request [inherits] Item
– Picks up the default Title field, and includes it’s own site columns.
2) Service Request Submitted [inherits] Service Request
– Picks up site columns from Service Request and includes it’s own site columns
3) Service Request Completed [inherits] Service Request Submitted
– Picks up site columns from Service Request, Service Request Submitted and it’s own site columns
4) Service Request Archive [inherits] Service Request Completed
– Picks up site columns from Service Request, Service Request Submitted, Service Request Completed and adds
a couple of it’s own site columns.
So at the point, as you can imagine if I open up Service Request Archive I see all the columns from each of the 3 prior Site Content Types and that’s aweful lot of fields to have to deal with.
Now again I don’t know about the original analysis for this design and I will add the caveat that does work just fine, but when I think about it in terms of OO design principals my feeling would be that it could be more simplified to the following design.
Service Request (base content type) which itself inherits from Item by default
– this content type would contain all the common site columns
(child content types)
Service Request Submitted [inherits] Service Request
Service Request Completed [inherits] Service Request
Service Request Archive [inherits] Service Request
Therefore the three “variations” or child site content types would inherit all common fields from Service Request and each include their own unique site columns if needed.
I’ve even thought that more flattened model (design) could be used such that something as simple as adding a Status site column with the values (Submitted, Closed, In Progress and other potential statuses could be added) to Service Request and thus eliminating the need for separate Site Content Types for Completed and Submitted to name a few. Then the Service Request Archive could just inherit from Service Request and add it’s own unique fields as needed.
In closing I did get inspiration as well from an article here on the community about Site Content Types and Inheritance. I forgot to grab the url, but none the less the author in a nutshell basically started with creating just site columns then created two separate document content types and associated only the common columns then chose a columns unique to each.
I’d appreciate any input anyone can share. I realize I didn’t include a lot of detail but I didn’t want to write a novel.
Thanks
