Conversation View and Categories
From time to time, folks ask me what they need to do in their message store provider to support Outlook 2010’s conversation view. I tell them they need to support restrictions on message store tables as discussed in the MAPI documentation. If Outlook hands them a restriction, they can’t return MAPI_E_TOO_COMPLEX and expect the conversation view to work. I also tell them their table needs to support categorization with multivalued columns and MV_INSTANCE. Because they support categorization, they also need to return STORE_CATEGORIZE_OK in PR_STORE_SUPPORT_MASK. Basically, when you turn on a conversation view, Outlook is going to exercise more of the MAPI spec than it has before. If your provider can’t handle it, then the view won’t work.
This is all true, but as usual, there’s more to the story. The more comes about when you decide your store isn’t going to be able to handle conversations. We usually find that categorization is the feature most people have trouble getting to work. So they decide “Ok – we just won’t support conversations” and they don’t return STORE_CATEGORIZE_OK. Their store works fine in Outlook, until a user tries to configure a conversation view. Then the user gets the error “Cannot display information. There is a problem connecting to the server or an error occurred. Try starting Microsoft Outlook again.” They continue to get this error until they change to a different view.
What’s going on? When we implemented the conversation view, we took a dependency on the categorization feature working in order to get the view working quick enough to be acceptable to the user. We also implemented a fallback path in case categories weren’t implemented, but since all of our built in providers did implement categories, this path did not get well tested. In fact, there’s a logic bug in it that causes the error the user sees. We investigated this a while back and even attempted a fix. However, when we did this, we realized why having categories was so important. Without categories, the performance of the conversation view is, to be blunt, horrible, Categories, it turns out, were what allowed us to implement the conversation threads without incurring a high level of post processing on the table.
We decided we couldn’t fix that code path (or we technically, we could, but no one would want the fix), and we looked at alternatives for delivering a better experience. The obvious choice here is to disable the conversation view UI when the store doesn’t support categories. However, this presents a challenge – we didn’t consider in our original design how to handle multiple stores where some stores (like the PST) support the view but others don’t. So while we agreed this would be a good design change, it was deemed too expensive to consider in a hotfix or service pack.
One customer found that, through heavy customization of the ribbon, they could hide the UI themselves when the user was looking at one of their folders, but leave the UI enabled when someone else’s folder was selected. However, it was still possible to set a conversation view to one of their folders. This could happen because of a prompt we display when the user checks “Show as Conversations”:
If the user picks “All folders” here, the conversation view gets applied to the store that couldn’t support it. Fortunately, there’s a way to suppress this dialog. We have a policy, UpgradeToConversations, which controls conversion to/from the conversation view. 0 converts conversation views to date sorts, 1 converts them the other way, and 2 says leave them all alone. If this policy is set to any value, we don’t display the prompt. For the customer that customized the ribbon, setting the policy to 2 allowed their users to have conversation views in the PST and Exchange stores, but not get them set in their store.
The moral of this story is if you have a custom store provider, you really need to support categories if you want your users to have a good experience.