One client had a problem with profile and membership synchronization, and the “My SharePoint Sites” links would not appear for anyone. This also affected the “SharePoint Sites” and “Membership” web parts on users’ MySites – no SharePoint related links would show up in these parts.

We verified that users were explicitly added into the “Members” group of SharePoint sites, we performed full crawls and ran all the timer jobs. Still no dice.

Eventually, a support ticket with MS revealed that having the Content Database set to Offline prevented that functionality from working.

Tags: SharePoint

After wrapping up a project that used content types extensively, I decided to write a series of posts detailing the headaches encountered so far.

This is part 2.

List Column Settings and STP Template Files

When you create a site content type, add that content type to a list, and then wrap that site up as an STP site template, none of your list content type column settings are carried over to sites based on the template. This means that if you’ve overridden the Hidden, Required, or Optional settings on the columns in your list content type from the base settings in the site content type, when a new site is provisioned from the site template, all the column overrides will be lost.

It appears that when the STP is packaged up, it only contains pointers to the parent content types, and ignores any list-level overrides to the content types.

Figure 1: List Content Type before STP (Notice the TestNonHiddenColumn is overridden here to be Hidden)

Figure 2: List Content Type after provisioning with STP (Notice the TestNonHiddenColumn is set back to Optional, like it is in the base content type)

Note that this is the same behavior experienced with creating List and Document Library templates as well, which must use a similar approach to templating that STP files use for site templates.

Tags: SharePoint

After wrapping up a project that used content types extensively, I decided to write a series of posts detailing the headaches encountered so far.

This is part 1.

Hidden Fields and Inherited Content Types

If you create a site content type through the UI and set a column to hidden, then create another site content type that inherits from the first one, and finally add that content type to a list, the column that was hidden will not be available anywhere in the UI on the list. Note that if you just use the base content type directly in the list, the hidden column WILL be visible in the list UI, and can be used in Views and toggled back to Optional or Required. 

Figure 1: Base Content Type

Figure 2: Child Content Type (notice hidden column is visible)

Figure 3: Child Content Type in List (notice missing column)It appears that Microsoft is assuming that a hidden column in a parent content type should not be able to be overridden once used in a grandchild content type. Whereas, some people might want to use the Hidden option to simply set a default for child content types, which may need to be overridden in particular lists or grandchildren.

The major pain with this is that you cannot regain the visibility of the column through the UI, even if you go back to the parent content type and set the column to Optional or Required. At that point, the column on the list is set to hidden, and has the CanToggleHidden attribute set to false. You have to either delete the content type from the list and re-add it (which will not work if you have list items already using that content type), or you have to resort to reflection to programmatically fix the column.

Ideally, content types created through the UI should have all of the granularity that is present in XML content type definitions. You should be able to specify ShowInEditForm, ShowInViewForm, CanToggleHidden, etc.

Tags: SharePoint