The SharePoint Freshman

As I mentioned before, I am working to become more familiar in the development piece of SharePoint. Such is that I am currently studying to take the Microsoft Exam - 70-541 - WSS 3.0 Application Development! We'll see how that turns out. I still need to sign up for the exam.

Check out the new tool Microsoft developed that compares your custom code to the best practices: http://blogs.msdn.com/sharepoint/archive/2008/11/12/announcing-spdisposecheck-tool-for-sharepoint-developers.aspx. There is also a few useful links in the blog you should check out if you're new to development.  The tool is planned to be released sometime this winter.

• Web Application Policy
• If you deny NT AUTHENTICATION\authenticated users the permission of "Manage Web Site" workflow's will not continue to get the "Operation in progress" screen.
• Be very careful with the User Permissions for Web Application link in the Central Administration -> Application Management -> Application Security.  Here you can define what permissions are available for consumption in the web application. In a controlled environment this is useful because you are then able to limit what permissions site collection administrators and site owners can use and grant to other users. However, be warned that Service Accounts are considered "users."  Thus, if you uncheck "Manage Web Site" you will get the error described above.
• The most restrictive Web Application Policy will override others
• Example:
• Jane is in the Active Directory security group myDomain\MOSS_Admin
• Jane is also in the Active Directory group myDomain\MOSS_Auditors
• At the web application policy level we created a new permission level called AuditorsReadOnly
• AuditorsReadOnly grants "read" permissions but denies administrative type permissions (i.e. Manage Web Site)
• myDomain\MOSS_Admin is given Full Control through a web application policy
• myDomain\MOSS_Auditors is given AuditorsReadOnly as a policy on the same web application
• Jane's highest permissions will be those granted in by the AuditorsReadOnly group. Even though she has Full Control, she will not be able to do the administrative functions because of the overriding "deny" rights applied to the auditors policy.
• Site Permissions
• If you need to customize permission levels, copy the existing permission level to create a new one.
• Do NOT delete the default permission levels created out of the box.
• Example: if you delete the "Design" group and then try to enable the Publishing Infrastructure feature, you will get an error. Recreating the group does not work. You have to rebuild the site.
• Check out the matrix created by Mark Arend - very cool
  

More to come later!

Happy SharePointing!

• Example - If you deny NT AUTHORITY\authenticated users Deny Write, all users will have no write access regardless of their local security policy (Site Collection Administrators, Site Owners, Contributors, etc).

• For administrators that don't have direct access to the Central Administration, document the settings. Why? Well, these permissions are not visible outside of the Central Administration. If you break the inheritance model at a web/list/item level, the users defined in the policy will still have access even though they do not show up in the Site Permissions (site settings -> advanced permissions -> site permissions).
• Use NT AUTHORITY\authenticated users carefully for obvious reasons. Plus, don't forget that will include your service accounts.
• Do not remove any access that is automatically given!
  • NT AUTHORITY\Local Service
  • Search Crawling Accounts
    
• Create your own permission levels. Just as in a site collection, you can create your own permission levels specific to your requirements. 
  • Central Administration -> Application Management -> Policy for Web Application -> Manage Permission Policy Levels -> Add Permission Policy Level
  • Before using the Deny Rights too much, get educated on what those permissions control. Unfortunately I have only found that I get educated through trial and error. But I will post my observations as I learn them.

Happy SharePointing!

Do you ever have those lists where you just don't want a "single line of text"? I wish there was a way to tie the "edit item" settings to some other column in a list, but alas, I have found nothing. It’s actually not recommended to change the title field because of features being tied to it in web parts and various views. However, I do have a couple workarounds for those that don't have a use for the "Title" field:

• Option 1 - Set the default value to “Edit Link.” When “Title” is included on a view, users can use this field to edit their list items.
  1. Settings -> List Settings -> under the Columns heading select the column name Title
     
  2. Type Edit Link in the Default Value text box and click OK
     
  3. Now, users have the nice menu available for that list item without having to enter data in the form!
     
• Option 2 – hide the column
  1. Settings -> List Settings -> select Advanced Settings from the General Settings section
     
  2. Select Yes for Allowing for Management of Content Types
      
  3. Under the Content Types section, click on the name (i.e. Item or Task).
  4. Under the Columns section, click on the column Title
  5. Update the status from Required (must contain information) to Hidden (Will not appear in forms)
• Option 3 - Rename the Column
  1. Settings -> List Settings -> under the Columns heading select the column name Title
  2. Update the Name to something more useful in your form
     • Example: For a request list or a task list I rename the Title field to Short Description. This way all the benefits of using the Title field are still linked to the renamed column.
     • NOTE: There are known limitations for renaming the Title column - including not being able to name it back to Title.

Happy SharePointing!