Complex List Structure Options and Permissions

Question

A customer has asked me to build a new commitment tracking system for them in Sharepoint. They have created a need for 3 types of commitments that we can just call TypeA, TypeB, and TypeC. There is also several different departments that need to be able to create these 3 types of commitments. There are 2 departments that can create the TypeB and TypeC commitment for any other department and only they can create TypeB annd TypeC. The TypeB and TypeC commitments can only be seen by the departments that they apply to and the 2 departments that created them. TypeA can be created by any department but only exists for that department.

I had several ideas but wondered which one would be the best.

1. Create the 3 Types as 3 seperate content types derived from the task content type. Create a single list attaching these types to the list and then create folders for each department. Use groups to control the permissions.

2. Create a list that derives from the task list or make a custom list. Create permission sets or groups that have the correct permissions and then use an event receiver on the list that uses the metadata of the item being added to check which department is assigned to and apply the permissions at the item level.

3. Create a separate list for each department and add the content types to each list. This seems rather crude as reporting would be more difficult.

Does anyone have a better suggestion or idea??

UPDATE 6-11-2011 This is an older post, but this project had fallen in priority and is now back on. I have written a blog post that I hope details it better here

Answer 1

This is what I have done to make this sort of work. I created a wsp site definition solution in VS 2008 and created the 3 content types. I added these content types to a custom list definition. I also created views for each department. I then used code to check the user information list to see what department they are in and send them to the page for that view. The 2 departments that have more 'power' get sent to a different view. On the other views I am using jQuery to remove the dropdown arrow for the content types so they only get the first content type. I am also using jQuery to hide the viewselectormenu until I find a better way of limiting what shows up in the dropdown. The users will be added to the correct groups and that seems to solve most of the problems. The default.aspx page has the code to check the user information list and it will send the user to a custom form to fill out their data if it has not yet been filled out. I made the form a custom webpart that I use to draw the controls on the screen, but I send the data back to the list using Marc Anderson's jQuery SPServices library.

Answer 2

I think those are good options, but it's difficult to really choose between them without knowing more. Here are some things which I would consider:

• Exactly what are your reporting requirements? Presumably someone somewhere does need an aggregated view across all commitments, but do they need (for example) to create their own views? Or will a 'developed' report with no 'report builder' functionality suffice? It would be easy to aggregate the data across 3 lists with SPSiteDataQuery (for option 3), but this would be 'developed' functionality - the view infrastructure is obviously tied to a single list only so that's out for option 3.
• What are your scale requirements? How many commitments are expected to be in the list(s) at any one time? If it's a 'high' number (somewhat difficult to define without knowing hardware/concurrent users etc.) then option 2 would be less preferable as item-level security does not scale well.

With the information you've provided, I'd already be inclined to avoid option 2 - you would have permissions applied to many objects, when containers such as lists are folders are designed to act as permission scopes.

Still, my thought would be that more information is needed to make a decision. Sorry to come over all politician-like ;)