Inherited Folder Properties

I’ve now posted my inherited folder property bug for checkin, so I thought it would be a good time to describe this method.

There are often situations in the mailnews code where some attribute of a folder is set, and you have to decide whether this is a global, per-server, per-folder tree, or per-folder attribute. For me, the immediate need was to decide whether to apply soft tags to messages. In the initial release of TaQuilla, I simply used a global that was either on or off. But that is less than ideal for something that is fairly intrusive like automatic tagging. Also, as I extend bayes analysis to RSS and news, the problem gets even more complex. Asking a user to enable or disable it in every folder separately, which is the other extreme, is a large burden for someone with tens or even hundreds of folders.

Enter the inherited folder property. In the underlying code, when I want to test whether to apply soft tags on messages in a folder, I simply ask for the inherited property for the folder:

softTagsToApply = folder.getInheritedStringProperty("softTagsToApply");

Then I get a list of soft tags for the folder.

So far, this is just like a normal folder property. But the inherited property can be precisely applied at many different levels. It looks up the property to apply like this:

1. If the property value is defined on the folder, use that value
2. If not, then get the inherited property from the folder’s parent
3. At the root folder for a server, get the property value for the server object.
4. The server object in turn may be assigned a global value using the preference mail.server.default.(propertyName)

So with this scheme, simply by changing the basic call from getStringProperty to getInheritedStringProperty, you can precisely control in an extension whether the property is applied for a specific folder, for a folder and its descendents, for a server, or globally.

I think that this should be the standard way to get folder properties in the future, unless there is some overriding reason why it should not be allowed. Here’s some examples of where I think we should be using it:

• whether to apply gloda indexing to messages
• whether to apply filters to new messages in an IMAP folder
• retention policies
• columns to display in thread pane
• which folder to place Sent messages for replies

One issue though is that this value is tri-state (when we are talking about a boolean), or in the case of strings then there is an ambiguity between an empty string and a null string (which means inherit). So in cases where UI exists to set properties on a folder, then the UI will need to explictly support “inherit” as a separate option from (checked/unchecked) or (blank/not blank).